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? > I agree with Neil, though -- as a reviewer, I think the architecture > of your solution is valid, but would need to audit these pretty > closely to get a sense of the individual correctness/appropriateness > of each change. The important part to review is this one, which is fairly close to what XFS has been doing (for local access too) for a long time already: http://git.infradead.org/users/dwmw2/nfsexport-2.6.git?a=commitdiff;h=37f3aae5380eb4ef23a77f3f52b8849a18cee188 -- David Woodhouse Open Source Technology Centre David.Woodhouse@xxxxxxxxx Intel Corporation -- 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
