[...] 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.