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

Package: coreutils;

Reported by: Gian Domenico Bonazzoli <gbonazzoli <at> bonaz.it>

Date: Sun, 22 Sep 2024 07:30:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gian Domenico Bonazzoli <gbonazzoli <at> bonaz.it>
To: 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 08:21:30 +0200
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

This bug report was last modified 187 days ago.

Previous Next


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