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
[Message part 1 (text/plain, inline)]
Your bug report
#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 73418 <at> debbugs.gnu.org.
--
73418: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73418
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
On 2024-11-09 09:16, Pádraig Brady wrote:
>> $ src/ls -lZ INSTALL
>> lrwxrwxrwx 1 padraig padraig ? ...
>
> This is still an issue here.
Oh, thanks for reminding me. That's a Gnulib bug, fixed here:
https://lists.gnu.org/r/bug-gnulib/2024-11/msg00075.html
with the fix propagated into Coreutils by installing the attached.
I thinks this closes out all the problems mentioned in this bug report,
so I'm boldly closing it. We can reopen it if I'm wrong.
[0001-build-update-gnulib-submodule-to-latest.patch (text/x-patch, attachment)]
[0002-ls-add-test-case-for-ls-Z-bug.patch (text/x-patch, attachment)]
[Message part 6 (message/rfc822, inline)]
[Message part 7 (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 8 (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.