On Sat, Aug 02, 2008 at 09:42:32PM +0100, David Woodhouse wrote: > On Sat, 2008-08-02 at 14:26 -0400, J. Bruce Fields wrote: > > Could you add a readdirplus vfs operation which took a flag indicating > > how much extra information you're going to need? > > Actually, if we're screwing with readdir then xfs would like to know how > much it's going to be asked to read, rather than just have the filldir > callback return zero when it's done. OK. > > The three cases where readdir can be called are: > > - ordinary readdir, for which the existing filldir_t provides > > all the information needed. > > - nfsv3 readdirplus, where the only additional information > > needed is whether there's a mountpoint. > > It also wants a file handle. Oops, right. > For which I think it just needs > i_generation in addition to the information it already has. Typically, right, though the filesystem's allowed some choice about what exactly it wants to use in the filehandle. I don't know how the various filesystems are actually using that in practice. > > - nfsv4 readdir, where we may need all the stat info, acls, > > etc., etc. > > We _might_, but most of the time we won't. It might be OK to fall back > to the existing double-buffer hack for the cases where we _do_ need that > extra information. How bad is the "double-buffer hack" anyway? Rather than have this as a fallback case that's rarely used (hence rarely tested), it might be simpler just to use it for everything if we're going to use it at all. --b. > I think a ->lookup_fh() method (which _expects_ to be called from within > filldir, and hence does its locking automatically) is the way to go. > > One alternative might just be a full lookup method with the same locking > rules: ->lookup_locked(). That might be easier to implement, and would > solve the problem even for the corner cases of NFSv4. Although I still > think we'd do best to avoid populating the inode cache with _all_ > children when we do a readdirplus. > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse@xxxxxxxxx Intel Corporation > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
