public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Yihao Wu <wuyihao@linux.alibaba.com>, linux-nfs@vger.kernel.org
Subject: Re: Why doesn't NFSv3 implement LOOKUPP?
Date: Wed, 13 Feb 2019 06:50:16 -0500	[thread overview]
Message-ID: <0bd905c30a652d19404eef82b40f6b92987ca814.camel@redhat.com> (raw)
In-Reply-To: <3dc67361-9c2f-d183-09e5-0a4d5c48d0f7@linux.alibaba.com>

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 <jlayton@redhat.com>


  reply	other threads:[~2019-02-13 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13  8:41 Why doesn't NFSv3 implement LOOKUPP? Yihao Wu
2019-02-13 11:50 ` Jeff Layton [this message]
2019-02-15  5:14   ` Yihao Wu
2019-02-15  9:49     ` Jeff Layton
2019-02-15 13:24     ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0bd905c30a652d19404eef82b40f6b92987ca814.camel@redhat.com \
    --to=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=wuyihao@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox