From: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: "viro@ZenIV.linux.org.uk" <viro@ZenIV.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>
Subject: Re: [PATCH 9/9] nfs: don't open in ->d_revalidate
Date: Tue, 6 Mar 2012 16:41:20 +0000 [thread overview]
Message-ID: <1331052079.3260.33.camel@lade.trondhjem.org> (raw)
In-Reply-To: <87boo9k861.fsf@tucsk.pomaz.szeredi.hu>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2613 bytes --]
On Tue, 2012-03-06 at 17:26 +0100, Miklos Szeredi wrote:
> "Myklebust, Trond" <Trond.Myklebust@netapp.com> writes:
>
> > On Tue, 2012-03-06 at 13:56 +0100, Miklos Szeredi wrote:
> >> From: Miklos Szeredi <mszeredi@suse.cz>
> >>
> >> NFSv4 can't do reliable opens in d_revalidate, since it cannot know whether a
> >> mount needs to be followed or not. It does check d_mountpoint() on the dentry,
> >> which can result in a weird error if the VFS found that the mount does not in
> >> fact need to be followed, e.g.:
> >>
> >> # mount --bind /mnt/nfs /mnt/nfs-clone
> >> # echo something > /mnt/nfs/tmp/bar
> >> # echo x > /tmp/file
> >> # mount --bind /tmp/file /mnt/nfs-clone/tmp/bar
> >> # cat /mnt/nfs/tmp/bar
> >> cat: /mnt/nfs/tmp/bar: Not a directory
> >>
> >> Which should, by any sane filesystem, result in "something" being printed.
> >>
> >> So instead do the open in f_op->open() and in the unlikely case that the cached
> >> dentry turned out to be invalid, drop the dentry and return ESTALE to let the
> >> VFS retry.
> >
> > This patch would force a complete new walk of the path in cases where
> > today we just do a single lookup of the last component.
>
> I sort of anticipated that, but I really don't know how much of an issue
> is this.
It makes a big difference to the cache miss case, since not only is the
entire path looked up again, but the LOOKUP_REVAL flag gets set, which
forces a full lookup of each component (as opposed to just
revalidating).
> Of course it is possible to redo only the last component after
> f_op->open() return ESTALE but that requires reshuffling do_last().
>
> > It really
> > doesn't seem worth taking that penalty just in order to make some insane
> > bind mount corner cases work.
>
> It's not at all insane if for example we have multiple mount namespaces.
> NFS is clearly broken and it needs to be fixed, one way or another.
Right, but this is still an extremely rare usage case: you are the first
person to report it as being broken (OK, Al may have mentioned it in the
past too). There have been no actual user reports AFAIK.
OTOH, cache misses are frequent.
> If you think this is a serious performance regression then lets drop
> this patch and add it to the atomic open series together with the
> do_last() reshuffling.
That sounds like a good suggestion to me.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2012-03-06 16:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-06 12:56 [PATCH 0/9] vfs: path lookup fixes and cleanups Miklos Szeredi
2012-03-06 12:56 ` [PATCH 1/9] vfs: fix double put after complete_walk() Miklos Szeredi
2012-03-06 12:56 ` [PATCH 2/9] vfs: fix return value from do_last() Miklos Szeredi
2012-03-06 12:56 ` [PATCH 3/9] vfs: fix d_need_lookup/d_revalidate order in do_lookup Miklos Szeredi
2012-03-06 12:56 ` [PATCH 4/9] vfs: don't revalidate just looked up dentry Miklos Szeredi
2012-03-06 12:56 ` [PATCH 5/9] vfs: move MAY_EXEC check from __lookup_hash() Miklos Szeredi
2012-03-06 12:56 ` [PATCH 6/9] vfs: set LOOKUP_JUMPED in follow_managed Miklos Szeredi
2012-03-06 12:56 ` [PATCH 7/9] vfs: reorganize do_lookup Miklos Szeredi
2012-03-13 9:34 ` Christoph Hellwig
2012-03-13 11:04 ` Miklos Szeredi
2012-03-06 12:56 ` [PATCH 8/9] vfs: split __lookup_hash Miklos Szeredi
2012-03-20 16:39 ` Christoph Hellwig
2012-03-26 10:44 ` Miklos Szeredi
2012-03-06 12:56 ` [PATCH 9/9] nfs: don't open in ->d_revalidate Miklos Szeredi
2012-03-06 14:12 ` Myklebust, Trond
2012-03-06 16:26 ` Miklos Szeredi
2012-03-06 16:41 ` Myklebust, Trond [this message]
2012-03-06 17:10 ` Miklos Szeredi
2012-03-06 17:47 ` Myklebust, Trond
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=1331052079.3260.33.camel@lade.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@ZenIV.linux.org.uk \
/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
all inboxes | Powered by JetHome®