Re: getdents64 problem in 2.6.23

[Jamie Lokier <jamie@shareable.org>]

Jörn Engel wrote:
> > We probably need to implement a release() operation in the
> > jffs2_dir_operations (top of dir.c), which will remove the fake
> > 'deletion' dirents if !atomic_read(&inode->i_count). Or something like
> > that.
> 
> I hate to spoil the fun, but this can cause problems with nfs.
> 
> It is legal for nfs to call telldir, close the directory, wait for half
> a year, then open the directory, call seekdir and expect sane results.
> Not pretty at all for filesystem implementors.
> 
> So either these deletion dirents need to stay around or you have to
> convert the i_pos "cookie" to a hash of the filename or so or at least
> explicitly document that you have broken nfs under some circumstances.
> 
> Of course any other program could do the telldir/seekdir stunt as well.
> Nfs just appears to be the only one doing this madness in practice.

Indeed.

However, I think it's fine to _overwrite_ the deletion dirents with
new ones.  getdentds() allows new names created during a directory
read to appear or not in the lsit.

Also, I think it's fine to _coalesce_ deletion dirents into one, as
long as the number of entries they represent is retained as a count.

If to, the number of deletion dirent structures could be bounded to be
no more than the number of active dirents.

In which case, perhaps the storage on flash needed for them could
simply be (at most) one integer per active dirent?  If that's
possible, it would provide the correct semantics for telldir/readdir
even across unmounts/reboots, without using much storage even in
pathological cases.

-- Jamie