GNU bug report logs - #73418
ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Gian Domenico Bonazzoli <gbonazzoli <at> bonaz.it>, 73418 <at> debbugs.gnu.org
Subject: bug#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share
Date: Sun, 22 Sep 2024 10:42:10 +0100

On 22/09/2024 07:21, Gian Domenico Bonazzoli wrote:
> Hi all,
> 
> During an upgrade from Ubuntu 22.04 to Ubuntu 24.04 we discovered that "ls
> (GNU coreutils) 9.4" is extremely slower than "ls (GNU coreutils) 8.32"
> listing files on a cifs mounted share.
> 
> Facts to help you in troubleshooting the problem.
> 
> In the same Ubuntu 24.04 machine I have the vanilla executable in
> /usr/bin/ls and a copy of Ubuntu 22.04 in /tmp/ls
> 
> root <at> kube-node04:~# /usr/bin/ls --version
> ls (GNU coreutils) 9.4
> 
> root <at> kube-node04:~# /tmp/ls --version
> ls (GNU coreutils) 8.32
> 
> I have also a cifs share mounted by:
> 
> //172.16.0.100/export /cifs/colom/export cifs
> vers=2.0,uid=50000,username=teledba,password=***** 0 1
> 
> This is what happens:
> 
> root <at> kube-node04:~# time /tmp/ls -l  /cifs/colom/export >/dev/null
> real 0m0.232s
> user 0m0.027s
> sys 0m0.027s
> 
> 
> root <at> kube-node04:~# time /usr/bin/ls -l  /cifs/colom/export >/dev/null
> real 0m5.744s
> user 0m0.068s
> sys 0m0.349s
> 
> So "ls -l" in 9.4 is 50 time slower then "ls -l" in 8.32
> 
> If I launch the ls command without the -l parameter the computing times are
> instead quite similar:
> 
> root <at> kube-node04:~# time /tmp/ls  /cifs/colom/export >/dev/null
> real 0m0.198s
> user 0m0.015s
> sys 0m0.021s
> 
> root <at> kube-node04:~# time /usr/bin/ls  /cifs/colom/export >/dev/null
> real 0m0.174s
> user 0m0.017s
> sys 0m0.016s
> 
> looking at the strace output I saw that the new version is doing for each
> file processed the adjunctive call listxattr (in my case the directory
> contains 14500 files):
> 
> ...
> statx(AT_FDCWD, "/cifs/colom/export/ARTP000.CSV",
> AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT,
> STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE,
> {stx_mask=STATX_TYPE|STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_CTIME|STATX_INO|STATX_SIZE|STATX_BLOCKS|STATX_BTIME|STATX_MNT_ID,
> stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=840, ...}) = 0
> listxattr("/cifs/colom/export/ARTP000.CSV", "", 152) = 0
> ...
> 
> maybe it is the root cause of the elapsed time when the ls command had the
> "-l" option fired ?
> 
> Regards

You listxattr() above doesn't seem to be returning an error,
but perhaps this is another manifestation of
https://bugs.gnu.org/68283 ?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.