Date:   Fri, 3 Feb 2023 16:15:12 -0800 (PST)
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
In-Reply-To: <0D7A0393-EE80-4785-9A83-44CF8269758B@hammerspace.com>
Message-ID: <ab632691-7e4c-ccbf-99a0-397f1f7d30ec@google.com>
References: <9A4A5673-691D-47EC-BC44-C43BE7E50A48@oracle.com> <D0404F55-2692-4DB6-8DD6-CAC004331AC1@redhat.com> <5FF4061F-108C-4555-A32D-DDBFA80EE4E7@redhat.com> <F1833EA0-263F-46DF-8001-747A871E5757@redhat.com> <B90C62F2-1D3A-40E0-8E33-8C349C6FFD3D@oracle.com>
 <44CB1E86-60E0-4CF0-9FD4-BB7E446542B7@redhat.com> <1AAC6854-2591-4B21-952A-BC58180B4091@oracle.com> <41813D21-95C8-44E3-BB97-1E9C03CE7FE5@redhat.com> <79261B77-35D0-4E36-AA29-C7BF9FB734CC@oracle.com> <104B6879-5223-485F-B099-767F741EB15B@redhat.com>
 <966AEC32-A7C9-4B97-A4F7-098AF6EF0067@oracle.com> <545B5AB7-93A6-496E-924E-AE882BF57B72@hammerspace.com> <FA8392E6-DAFC-4462-BDAE-893955F9E1A4@oracle.com> <4dd32d-9ea3-4330-454a-36f1189d599@google.com>
 <0D7A0393-EE80-4785-9A83-44CF8269758B@hammerspace.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="-1463760895-1720490057-1675469721=:2591"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1463760895-1720490057-1675469721=:2591
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

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=E2=80=99ve always been playing the lotter=
y when mounting tmpfs over NFS.
> >>=20
> >> I'm not debating the truth of that. I just don't think we should
> >> be making that situation needlessly worse.
> >>=20
> >> 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.
> >=20
> > I very much agree with you, Chuck.  Making something imperfect
> > significantly worse is called "a regression".
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > Hugh
>=20
>=20
> No! If it was impossible to hit this problem before the patch, then I mig=
ht agree with you. However what it does is exposes a problem that has alway=
s existed, but was a lot less likely to happen timing wise when we were all=
owing glibc to suck in all 50000 or so directory entries in one gulp.
>=20
> IOW: this patch doesn=E2=80=99t cause the problem, it just makes it easie=
r to hit when you are using a high performance setup like Chuck's. It was a=
lways easy to hit when you were using slower networking and/or smaller rsiz=
e 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
---1463760895-1720490057-1675469721=:2591--