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. > 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. For which I think it just needs i_generation in addition to the information it already has. > - 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. 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
