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
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?
--
Jeff Layton <[email protected]>
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
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 <[email protected]>
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
[email protected]