On Thu, 2008-05-01 at 16:48 -0400, Christoph Hellwig wrote: > Yes, and get_fsid would be extremly useful, especially for those > filesystems that already have an uuid in the superblock > (*cough*, XFS, *cough*), but it'll need some co-operations with > nfs-utils on when to use it. Why do you need to co-operate with userspace? Userspace shouldn't need to do anything -- we'll just generate a suitable fsid/uuid for ourselves, unless userspace deliberately overrides it for the export in question. > Patch looks good for me except for the few introduced overlong lines. Bah, don't you start. A less onanistic problem with it is the deadlock with NFS readdirplus (->readdir->encode_entry->compose_entry_fh->lookup) I wonder if we should postpone the calls to compose_entry_fh() until _after_ readdir() has completed. Leave space in the response for the filehandles, but only walk through it again calling compose_entry_fh() once we're done in readdir. That would allow us to get rid of the various icky hacks that file systems have to avoid that deadlock. -- dwmw2 -- 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
