On Feb 3, 2023, at 19:15, Hugh Dickins <hughd@xxxxxxxxxx> wrote:
On Sat, 4 Feb 2023, Trond Myklebust wrote:
On Feb 3, 2023, at 18:53, Hugh Dickins <hughd@xxxxxxxxxx> wrote:
On Fri, 3 Feb 2023, Chuck Lever III wrote:
On Feb 3, 2023, at 5:26 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
I can only repeat,
making something imperfect significantly worse is called "a regression".
Hugh
It is exposing a problem which was always there. You can’t just pick and choose your tests and claim that one result is more significant than the other: that’s called bias.
The functional change here is simply to cut the very first readdir short: i.e. it returns fewer entries than previously. Reducing the readdir buffer size supplied by the userspace application would have the exact same effect. The fact that Chuck’s test
happened to work before the patch went in, is due to a systematic bias in that test. Change the systematic bias (by changing the buffer size supplied by glibc in the sys_getdents call) and you should see the same problem that this patch exposed.
_________________________________
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
|
