Re: [PATCH] ramfs: pretend dirent sizes

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Wed, 20 July 2005 11:11:01 -0700, Chris Wedgwood wrote:
> On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
> 
> > To my understanding, you can lseek to any "proper" offset inside a
> > directory.  Proper means that the offset marks the beginning of a
> > new dirent (or end of file) in the interpretation of the filesystem.
> 
> But you can never tell where these are in general.

Correct.  Any filesystem can have any definition of proper.

> > Userspace doesn't have any means to figure out, which addresses are
> > proper and which aren't.  Except that getdents(2) moves the fd
> > offset to a proper address, which likely will remain proper until
> > the fd is closed.
> 
> I don't see why or how this can be true in general (it might be, but I
> don't see how myself).  If we are half way through scanning a
> directory and people start messing with it we could end up somewhere
> bogus (in which case f_op->readdir I guess is expected to try and do
> something sane here?)

If you read a large directory, it will take you quite a while to go
through the thousands of getdents() invocations.  Someone messing with
the directory meanwhile should be expected and shouldn't cause
userspace to get complete garbage.  If userspace doesn't learn about
all new dirents, that's fine.  If it receives old ones, that were
since deleted, that's fine.  But under no circumstances should you
hand out garbage.

Ext2, iirc, solves this problem by never shrinking directories.  Old
dirents can be invalid and won't get passed to userspace anymore.  But
they don't move around.  Hence, a linear read of the directory gives
you exactly above properties.

> > Reopening the same directory may result in a formerly proper offset
> > isn't anymore.
> 
> For that to be the case where is the state kept to ensure your current
> offset is valid?

Depends on the fs.  Ext2, as seen above, only needs file->offset as
state.  But image a questionable optimization for an uncommon case.
Whenever the last reader or an ext2 directory closes the fd, it is
safe to shuffle things around.  At this time, a "directory
defragmenter" takes the directory and squeezes all holes out of it.
The new, repacked directory consumes less space, which is nice.

Alternatively, the directory defragmenter could create a new
directory, copy all valid contents of the old one over, and new open()
on the directory will get the new copy, while old file descriptors
still point to the old one.

In both cases, what used to be a proper offset in one fd can be
complete bogus for another one.

And no, I don't want to add directory defragmenters to ext2.  It was
just a stupid example of what is possible.

Jörn

-- 
Linux [...] existed just for discussion between people who wanted
to show off how geeky they were.
-- Rob Enderle