From: martin@omnibond.com
To: hubcap@omnibond.com, devel@lists.orangefs.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] orangefs: misc attribute fixes
Date: Tue, 28 Nov 2017 16:02:35 -0500 [thread overview]
Message-ID: <20171128210235.GA70432@stumphouse.sysblue.org> (raw)
In-Reply-To: <20171128202201.8717-1-martin@omnibond.com>
On Tue, Nov 28, 2017 at 03:21:56PM -0500, Martin Brandenburg wrote:
> Mike,
>
> Here's a few fixes for OrangeFS.
>
> Most important is to run getattr for size during a mmap page fault.
>
> I have also found a bug in d_revalidate. The test is backwards.
> However I haven't found a test that demonstrates that it is wrong, which
> makes me doubt that all the code here is completely optimal.
The reason I can't find a test is because this code only gets run
if the inode being tested has the same handle as the inode in the
dcache. Of course this happens all the time (it wasn't changed). We
would return that it was not valid even though it was, which didn't
affect correctness but caused OrangeFS to perform extra round-trips with
the server.
We would return that it was valid even though it wasn't when an inode
is deleted and re-created on the server as a different type or different
symlink target AND has the same handle as the one in the cache. This
practically never happens.
Martin
prev parent reply other threads:[~2017-11-28 21:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 20:21 Martin Brandenburg
2017-11-28 20:21 ` [PATCH 1/5] orangefs: open code short single-use functions Martin Brandenburg
2017-11-28 20:21 ` [PATCH 2/5] orangefs: implement vm_ops->fault Martin Brandenburg
2017-11-28 20:21 ` [PATCH 3/5] orangefs: do not invalidate attributes on inode create Martin Brandenburg
2017-11-28 20:22 ` [PATCH 4/5] orangefs: do not invalidate attribute cache on setattr Martin Brandenburg
2017-11-28 20:22 ` [PATCH 5/5] orangefs: reverse sense of revalidate is-inode-stale test Martin Brandenburg
2017-11-28 21:02 ` martin [this message]
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=20171128210235.GA70432@stumphouse.sysblue.org \
--to=martin@omnibond.com \
--cc=devel@lists.orangefs.org \
--cc=hubcap@omnibond.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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
Powered by JetHome