On Thu, Jul 31, 2008 at 9:00 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > On Thu, 2008-07-31 at 20:53 -0400, Chuck Lever wrote: >> For now it is sufficient, IMO. NFSv4 doesn't implement a readdirplus >> operation, and the performance benefits of NFSv3 readdirplus are >> equivocal -- there isn't a strong desire to replicate the complexity >> of NFSv3 readdirplus in NFSv4. I'm not even sure you can do it even >> with a single compound RPC, so even in the long run NFSv4 may not ever >> have the locking issues that NFSv3 does here. > > AFAICT NFSv4 does have the same recursion issues already. The call trace > goes fs->readdir() ... nfsd4_encode_dirent() ... > nfsd4_encode_dirent_fattr() ... lookup_one_len() ... fs->lookup(). > > Or am I mistaken? It looks like it needs a directory entry's dentry for a couple of reasons: 1. To determine whether a directory entry is a mount point 2. If the client has asked for file handles (via a bitmask) for the directory entries So, yep, you're right. NFSv4 will hit this too. As I recall, the Linux NFSv4 client doesn't use FATTR4_WORD0_FILEHANDLE during NFSv4 READDIR for the reasons I stated earlier; and it only uses FATTR4_WORD0_FSID during GETATTR. Other clients might use these during a READDIR however. -- "Alright guard, begin the unnecessarily slow-moving dipping mechanism." --Dr. Evil -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
