On 2019/2/13 7:50 PM, Jeff Layton wrote: > On Wed, 2019-02-13 at 16:41 +0800, Yihao Wu wrote: >> Hi all, >> >> When looking into "Failures: generic/467" given by xfstests, I found that NFSv3 >> didn't implement LOOKUPP. I know that this might be by design. But LOOKUPP was >> meant to replace ".." in NFSv3, right? >> >> xfstests's generic/467 test case performs the following sequence of operations. >> >> name_to_handle -> drop_caches -> open_by_handle >> >> Dentry becomes disconnected due to drop_caches. NFSv3 doesn't support LOOKUPP. >> So when it performs open_by_handle to an directory, this test case fails. >> >> I did some small experiment by implementing LOOKUPP for NFSv3. The way I tried >> is to merely pass ".." to nfs3_proc_lookup. And it seems to work. At least it's >> a workaround for xfstests. >> >> I'm curious whether this sort of simulation of LOOKUPP will work or make sense. >> >> Thanks, >> Yihao Wu > > v3 was mostly designed with unix-like clients in mind. For v4, the spec > writers cast a wider net and decided not to put special meaning on > lookups of "." and "..", but they still needed a way to do a lookup of > "..". > > The question is why you want to implement LOOKUPP in v3. Mostly we added > it to the client to support reexporting NFSv4 filesystems via NFSv3. Are > you looking to reexport v3 filesystems for some reason? > Thanks a lot for your reply, Jeff! I'm just managing to figure out the source of this xfstests failure, that open_by_handle is simply not working for NFSv3 after drop_caches. I think NFSv3 might become able to reconnect_path too, with LOOKUP "..". However it's not, because nfs_get_parent fails as long as LOOKUPP is not supported. My server & client both support NFSv3. Can I take it that re-exporting is not a required option in this case? Thanks, Yihao Wu
