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, . 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?)