Subject: bug#73418: 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]>
Date: Mon, 30 Sep 2024 09:19:34 +0200

Hi Paul:

These are the mount options on Ubuntu 24.04:

//172.16.0.100/export on /cifs/colom/export type cifs
(rw,relatime,vers=2.0,cache=strict,username=teledba,uid=50000,forceuid,gid=0,noforcegid,addr=172.16.0.100,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=65536,wsize=65536,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)

instead on Ubuntu 22.04:

//172.20.150.103/External on /cifs/colom/export type cifs
(rw,relatime,vers=1.0,cache=strict,username=teledba,domain=WORKGROUP,uid=50000,forceuid,gid=0,noforcegid,addr=172.20.150.103,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=61440,wsize=4096,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1)

mentre lo strace -r shows:

     0.000105 listxattr("/cifs/colom/export/M606219.CSV", "", 152) = 0
     0.000630 statx(AT_FDCWD, "/cifs/colom/export/M606220.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=4992, ...}) = 0
     0.000077 listxattr("/cifs/colom/export/M606220.CSV", "", 152) = 0
     0.000464 statx(AT_FDCWD, "/cifs/colom/export/M606221.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=0, ...}) = 0
     0.000076 listxattr("/cifs/colom/export/M606221.CSV", "", 152) = 0
     0.000542 statx(AT_FDCWD, "/cifs/colom/export/M606222.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=0, ...}) = 0

Sorry but I can't change anything on the cifs server side, it is a closed
system (IBM AS/400)

On Mon, Sep 30, 2024 at 7:24 AM Paul Eggert <[email-masked]> wrote:

> On 2024-09-21 23:21, Gian Domenico Bonazzoli wrote:
> > 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 ?
>
> What does "strace -r" report? That will tell us about elapsed time.
>
> What options are you using with your CIFS mount? The "mount" command can
> tell you that.
>
> What happens if you mount the CIFS file system with the nouser_xattr
> option?
>
> Can you disable extended attributes from the server side? E.g., if it's
> a Samba server configure with "ea support = no". If so, does that help?
> See, for example,
> <
> https://www.truenas.com/community/threads/cifs-directory-browsing-slow-try-this.27751/
> >.
>
> Looking at the current coreutils source, I noticed that 'ls' called
> getxattr when it didn't need to. I installed the attached patch to fix
> some of the issue; more could be done and perhaps I'll find the time.
> Among other things this patch should cause GNU ls to use llistxattr
> instead of listxattr which may make a difference.
>
> That being said, it does appear that CIFS is quite slow about getting
> extended attributes.
>
> (I wish Linux attributes weren't such a pain to deal with. Among other
> things, why aren't there any *at functions?)