Re: getdents64 problem in 2.6.23

[David Woodhouse <dwmw2@infradead.org>]

On Sun, 2007-10-28 at 01:18 +0200, Jörn Engel wrote:
> On Fri, 26 October 2007 19:17:40 -0400, David Woodhouse 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.

Well, the f->dents list is _already_ ordered by the hash of the
filename. The only reason we _don't_ use the hash as the i_pos 'cookie'
is because of the potential for hash collisions.

If we could deal with that, we could use trees for it instead of a
linked list.

-- 
dwmw2