Subject: bug#73418: closed (Re: bug#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 10 Nov 2024 00:58:03 +0000

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

-- 
73418: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73418
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share
From: Paul Eggert <[email-masked]>
To: Pádraig Brady <[email-masked]>
Cc: Gian Domenico Bonazzoli <[email-masked]>, [email-masked]
Date: Sat, 9 Nov 2024 16:57:45 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

From b048c4d37f4f1b313c6334525ad3f4589efda1a4 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Sat, 9 Nov 2024 10:29:14 -0800
Subject: [PATCH 1/2] build: update gnulib submodule to latest

---
 gnulib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnulib b/gnulib
index ba9136b76..74b6a2a73 160000
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit ba9136b7646ef9e01ffad3ddcf232002354531d0
+Subproject commit 74b6a2a7386cf8586c1244297d4d87dde123db42
-- 
2.47.0

From 45ba6c6f54c771778761776e496ed3d6a4622b19 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Sat, 9 Nov 2024 16:51:02 -0800
Subject: [PATCH 2/2] ls: add test case for ls -Z bug
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem reported by Pádraig Brady <https://bugs.gnu.org/73418#35>.
This bug was fixed by the recent gnulib update.
* tests/ls/selinux-segfault.sh:
Also test for ls -Z on broken symlinks.
---
 tests/ls/selinux-segfault.sh | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/tests/ls/selinux-segfault.sh b/tests/ls/selinux-segfault.sh
index ebcfbfe13..9ac1d950c 100755
--- a/tests/ls/selinux-segfault.sh
+++ b/tests/ls/selinux-segfault.sh
@@ -30,4 +30,19 @@ mkdir sedir || framework_failure_
 ln -sf missing sedir/broken || framework_failure_
 returns_ 1 ls -L -R -Z -m sedir > out || fail=1
 
+nl='
+'
+if sestatus=$(LC_ALL=C sestatus); then
+  sestatus_line_1=${sestatus%%$nl*}
+  case $sestatus_line_1 in
+    'SELinux status:'*' enabled')
+      ls_output=$(LC_ALL=C ls -lnZ sedir/broken) || fail=1
+      set x $ls_output
+      case $6 in
+        *:*:*:*) ;;
+        *) fail=1;
+      esac
+  esac
+fi
+
 Exit $fail
-- 
2.47.0

Subject: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share
From: Gian Domenico Bonazzoli <[email-masked]>
To: [email-masked]
Date: Sun, 22 Sep 2024 08:21:30 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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@kube-node04:~# /usr/bin/ls --version
ls (GNU coreutils) 9.4

root@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@kube-node04:~# time /tmp/ls -l  /cifs/colom/export >/dev/null
real 0m0.232s
user 0m0.027s
sys 0m0.027s

root@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@kube-node04:~# time /tmp/ls  /cifs/colom/export >/dev/null
real 0m0.198s
user 0m0.015s
sys 0m0.021s

root@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