From: Hugh Dickins <hughd@google.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: Hugh Dickins <hughd@google.com>,
Charles Edward Lever <chuck.lever@oracle.com>,
Benjamin Coddington <bcodding@redhat.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Anna Schumaker <anna@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Amir Goldstein <amir73il@gmail.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: git regression failures with v6.2-rc NFS client
Date: Fri, 3 Feb 2023 16:15:12 -0800 (PST) [thread overview]
Message-ID: <ab632691-7e4c-ccbf-99a0-397f1f7d30ec@google.com> (raw)
In-Reply-To: <0D7A0393-EE80-4785-9A83-44CF8269758B@hammerspace.com>
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
On Sat, 4 Feb 2023, Trond Myklebust wrote:
> > On Feb 3, 2023, at 18:53, Hugh Dickins <hughd@google.com> wrote:
> > On Fri, 3 Feb 2023, Chuck Lever III wrote:
> >>> On Feb 3, 2023, at 5:26 PM, Trond Myklebust <trondmy@hammerspace.com> wrote:
> >>> The bottom line is that you’ve always been playing the lottery when mounting tmpfs over NFS.
> >>
> >> I'm not debating the truth of that. I just don't think we should
> >> be making that situation needlessly worse.
> >>
> >> And I would be much more comfortable with this if it appeared in
> >> a man page or on our wiki, or ... I'm sorry, but "some email in
> >> 2001" is not documentation a user should be expected to find.
> >
> > I very much agree with you, Chuck. Making something imperfect
> > significantly worse is called "a regression".
> >
> > And I would expect the (laudable) optimization which introduced
> > that regression to be reverted from 6.2 for now, unless (I imagine
> > not, but have no clue) it can be easily conditionalized somehow on
> > not-tmpfs or not-simple_dir_operations. But that's not my call.
> >
> > What is the likelihood that simple_dir_operations will be enhanced,
> > or a satisfactory complicated_dir_operations added? I can assure
> > you, never by me! If Al or Amir or some dcache-savvy FS folk have
> > time on their hands and an urge to add what's wanted, great: but
> > that surely will not come in 6.2, if ever.
> >
> > More likely that effort would have to come from the NFS(D) end,
> > who will see the benefit. And if there's some little tweak to be
> > made to simple_dir_operations, which will give you the hint you need
> > to handle it better, I expect fsdevel would welcome a patch or two.
> >
> > Hugh
>
>
> No! If it was impossible to hit this problem before the patch, then I might agree with you. However what it does is exposes a problem that has always existed, but was a lot less likely to happen timing wise when we were allowing glibc to suck in all 50000 or so directory entries in one gulp.
>
> IOW: this patch doesn’t cause the problem, it just makes it easier to hit when you are using a high performance setup like Chuck's. It was always easy to hit when you were using slower networking and/or smaller rsize values against a remote server with multiple clients creating + deleting files in the same NFS exported tmpfs directory.
> _________________________________
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
I can only repeat,
making something imperfect significantly worse is called "a regression".
Hugh
next prev parent reply other threads:[~2023-02-04 0:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-31 21:15 git regression failures with v6.2-rc NFS client Chuck Lever III
2023-01-31 22:02 ` Benjamin Coddington
2023-02-01 14:10 ` Benjamin Coddington
2023-02-01 15:53 ` Benjamin Coddington
2023-02-03 14:38 ` Chuck Lever III
2023-02-03 15:13 ` Benjamin Coddington
2023-02-03 15:35 ` Chuck Lever III
2023-02-03 17:14 ` Benjamin Coddington
2023-02-03 18:03 ` Chuck Lever III
2023-02-03 20:01 ` Benjamin Coddington
2023-02-03 20:25 ` Chuck Lever III
2023-02-03 22:26 ` Trond Myklebust
2023-02-03 23:11 ` Chuck Lever III
2023-02-03 23:53 ` Hugh Dickins
2023-02-04 0:07 ` Trond Myklebust
2023-02-04 0:15 ` Hugh Dickins [this message]
2023-02-04 0:59 ` Trond Myklebust
2023-02-04 11:07 ` Thorsten Leemhuis
2023-02-04 13:15 ` Benjamin Coddington
2023-02-04 16:52 ` Trond Myklebust
2023-02-04 20:44 ` Benjamin Coddington
2023-02-05 11:24 ` Jeff Layton
2023-02-05 16:11 ` Benjamin Coddington
2023-02-01 15:11 ` Chuck Lever III
2023-02-03 12:39 ` Linux kernel regression tracking (#adding)
2023-02-21 14:58 ` Linux regression tracking #update (Thorsten Leemhuis)
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=ab632691-7e4c-ccbf-99a0-397f1f7d30ec@google.com \
--to=hughd@google.com \
--cc=amir73il@gmail.com \
--cc=anna@kernel.org \
--cc=bcodding@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.com \
--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;
as well as URLs for NNTP newsgroup(s).