On Fri, 2008-08-01 at 12:05 -0400, Chuck Lever wrote: > Some NFSv3 clients don't support READDIRPLUS at all, while some can > disable it (like Linux, Mac OS, and FreeBSD), and others use it only > in certain cases (Linux). I wouldn't describe any of these as saner > or more commonly encountered than another. Readdirplus is easy enough to fix with a lookup_fh() method and some way to check if a given entry is a mountpoint. I'm not worried about that. > > Or maybe we could just mask the offending attrs out of ->rd_bmval for > > readdir calls, and say we don't support them? Would anyone scream if we > > did that? > > I'm not an NFSv4 expert (hence my initial incorrect assertion about > NFSv4 not supporting readdirplus at all). I defer to those who are > actually working on the standard and Linux implementation (Bruce?) > But typically masking out these features could potentially cause > severe interoperability problems for certain client implementations. > We can only know for sure after a lot of testing at multivendor events > like Connectathon; it's not something I would disable cavalierly. It's not readdirplus (FATTR4_WORD0_FILEHANDLE?) I was talking about masking out -- as I said, we can cope with that. It's things that would _really_ require the inode, like FATTR4_WORD0_ACL, FATTR4_WORD0_CHANGE, etc. But still, if masking them out would be a problem, we could use the existing trick of doing readdir into a buffer and then going back and doing the actual lookup later. But _only_ for that relatively rare case, rather than for _all_ users of readdirplus, as we do at the moment. > I rather prefer making NFSD do the right thing here -- it seems to > localize and document the issue and provide a solution that all file > systems can use with a minimum of real fuss. Yes, that's definitely my preference too. What I've posted is a good first step to that, and we can talk about improving it later. -- 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
