* Re: Why doesn't NFSv3 implement LOOKUPP?
2019-02-15 5:14 ` Yihao Wu
@ 2019-02-15 9:49 ` Jeff Layton
2019-02-15 13:24 ` Trond Myklebust
1 sibling, 0 replies; 5+ messages in thread
From: Jeff Layton @ 2019-02-15 9:49 UTC (permalink / raw)
To: Yihao Wu, linux-nfs
On Fri, 2019-02-15 at 13:14 +0800, Yihao Wu wrote:
> 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?
Yes, I don't think we're too interested in reexporting v3.
The open_by_handle_at call is mostly there to support userland NFS
servers (though there are some other legit use-cases). If you're not
planning on reexporting NFSv3, then those failures probably won't matter
much.
If you do have need to use open_by_handle_at on NFSv3 for some
legitimate purpose, then we could certainly look at patching that up in
some fashion.
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Why doesn't NFSv3 implement LOOKUPP?
2019-02-15 5:14 ` Yihao Wu
2019-02-15 9:49 ` Jeff Layton
@ 2019-02-15 13:24 ` Trond Myklebust
1 sibling, 0 replies; 5+ messages in thread
From: Trond Myklebust @ 2019-02-15 13:24 UTC (permalink / raw)
To: jlayton, wuyihao, linux-nfs
On Fri, 2019-02-15 at 13:14 +0800, Yihao Wu wrote:
> 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?
While linux client don't generally need it, you may want to note that
some non-linux clients do need to make use of LOOKUP ".." in order to
navigate the server's namespace. I know that the Solaris client does
rely on it, and I suspect that FreeBSD does too.
I'd therefore strongly recommend that you do support the LOOKUP ".."
functionality in your server if you care about NFSv3 client
interoperability.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
^ permalink raw reply [flat|nested] 5+ messages in thread