Re: big issue with Ubuntu 14/16 clients
[...] 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.
Thanks for tracking this down. I took a quick look at the kernel NFS list, and didn't see any patches that seemed related to this issue, but I may have just missed it. I'll try to dig a bit further later. Daniel On 9/9/19 11:10 AM, Peter Grandi wrote:
[...] 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. _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
[...] 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: [...]
Thanks for tracking this down. I took a quick look at the kernel NFS list, and didn't see any patches that seemed related to this issue, but I may have just missed it. I'll try to dig a bit further later.
I had a look too and this is the only commit that I could spot that mentions missing directory entries: https://github.com/torvalds/linux/commit/98de9ce6f6660d02aa72d7b9b17696fa68a... This one may also be related, in the sense that it is about alignment/decoding: https://github.com/torvalds/linux/commit/02ef04e432babf8fc703104212314e54112...
-----Original Message----- From: Peter Grandi [mailto:pg@ganesha.list.sabi.co.UK] Sent: Wednesday, September 11, 2019 2:57 AM To: list Ganesha support <support@lists.nfs-ganesha.org> Subject: [NFS-Ganesha-Support] Re: big issue with Ubuntu 14/16 clients
[...] 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: [...]
Thanks for tracking this down. I took a quick look at the kernel NFS list, and didn't see any patches that seemed related to this issue, but I may have just missed it. I'll try to dig a bit further later.
I had a look too and this is the only commit that I could spot that mentions missing directory entries:
https://github.com/torvalds/linux/commit/98de9ce6f6660d02aa72d7b9b17696f a68a2ed9b
This one may also be related, in the sense that it is about alignment/decoding:
https://github.com/torvalds/linux/commit/02ef04e432babf8fc703104212314e5 4112ecd2d
Either of these seem unlikely, you could verify the XDR is ok from the tcpdump trace. Frank
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
Peter Grandi