10:10 a.m.
[...] No entries are omitted when the client is Fedora 30 with
kernel
5.2.nn or with GRML 2018.12 or Parrot 4.7 (kernel 4.19.nn in both
cases). [...]
This is a directory with 90 entries under ULTS 18 with the native 4.15.0
kernel and the backported 5.0 kernel, with various 'rsize' values:
$ uname -a; for N in 1024 2048 4096 6144 8192 12288 16384 32768 65536;
do echo -n "$N => "; sudo mount -t nfs -o
rw,vers=4,proto=tcp,timeo=10,intr,rsize=$N azara:/scratch /mnt/tmp && ls
/mnt/tmp/test | wc -l; sudo umount /mnt/tmp; done
Linux noether 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
1024 => 90
2048 => 81
4096 => 86
6144 => 86
8192 => 88
12288 => 88
16384 => 90
32768 => 90
65536 => 90
$ uname -a; for N in 1024 2048 4096 6144 8192 12288 16384 32768 65536;
do echo -n "$N => "; sudo mount -t nfs -o
rw,vers=4,proto=tcp,timeo=10,intr,rsize=$N azara:/scratch /mnt/tmp && ls
/mnt/tmp/test | wc -l; sudo umount /mnt/tmp; done
Linux noether 5.0.0-27-generic #28~18.04.1-Ubuntu SMP Thu Aug 22
03:00:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
1024 => 90
2048 => 90
4096 => 90
6144 => 90
8192 => 90
12288 => 90
16384 => 90
32768 => 90
65536 => 90
So my suspicion that the bug in the NFSv4 kernel client was fixed
between 4.15 and 5.0 seems reliable.
On another client with 4.15 (server also 4.15) 'rsize' 8192 and 12288
seemed to "hang", and on this client with 4.15 the listing was much
slower.