Re: Per-entry WSL EA queries during readdir cause severe ls -la slowdown on high-latency links (6.12)

Gustavo F N <[email protected]>
Newsgroups org.kernel.vger.linux-cifs
Message-ID <CAJr=uVTOKnPDnqdzSw9j48gjdXVZ+ZwcSvKNZ=heDRnUsnY1mg@mail.gmail.com>
Hi Paulo,

Confirmed, nouser_xattr fixes it completely:

  before:  real 0m39.031s
  after:   real 0m0.367s

  QueryInfos: 1 total 0 failed   (was 511)

And strace shows no llistxattr(2) calls at all with that option, so
`ls` stops asking once the mount reports no xattr support.

The two hosts:

  old:  CentOS Linux 7.9.2009
        kernel 3.10.0-1160.119.1.el7.x86_64
        coreutils-8.22-24.el7_9.2

  new:  Rocky Linux 10.2
        kernel 6.12.0-211.16.1.el10_2.0.1.x86_64
        coreutils-9.5-7.el10

The tell was in the listing output all along, and I missed it:

  old:  drwxrwxr-x  2 fwservice fwservice ...
  new:  drwxrwxr-x. 2 fwservice fwservice ...

The trailing dot on the new host is `ls` reporting a security context
on the files, which is exactly the llistxattr(2) result you found. The
old host prints no dot and issues no such calls.

I don't know which coreutils change introduced this either, but 8.22 to
9.5 is a wide enough gap that it could be any of several.

Thanks very much for tracking it down, and apologies for pointing you at
the WSL EA path, I'd read the STATUS_NO_EAS_ON_FILE responses as the
cause rather than a consequence.

All the best,

Gustavo

On Sun, Aug 9, 2026 at 10:40 AM Paulo Alcantara <[email protected]> wrote:
>
> Hi Gustavo,
>
> I was able to reproduce your problem with coreutils-9.10-5.fc44.x86_64
> and mainline kernel.
>
> The `ls -la` command is, in fact, calling llistxattr(2) on every file
> returned by getdents64(2).  That's why you're seeing those extra
> requests being sent to the server.  See below
>
>         $ mount.cifs //srv/share /mnt/1 -o ...
>         $ strace -e llistxattr -f ls -la /mnt/1 >/dev/null
>         llistxattr("/mnt/1", "", 152)           = 0
>         llistxattr("/mnt/1/.", "", 152)         = 0
>         llistxattr("/mnt/1/..", "security.selinux\0", 152) = 17
>         llistxattr("/mnt/1/008.174041", "", 152) = 0
>         llistxattr("/mnt/1/008.5301", "", 152)  = 0
>         llistxattr("/mnt/1/008.5307", "", 152)  = 0
>         llistxattr("/mnt/1/008.5313", "", 152)  = 0
>         llistxattr("/mnt/1/008.5384", "", 152)  = 0
>         llistxattr("/mnt/1/008.6320", "", 152)  = 0
>         llistxattr("/mnt/1/009.6781", "", 152)  = 0
>         llistxattr("/mnt/1/012.8056", "", 152)  = 0
>         ...
>
> That has nothing to do with the client trying to get WSL EAs on the
> files.  By using 'reparse=' mount option will also not help because it
> is only used for creating special files and symlinks.
>
> I don't know why why llistxattr(2) is being called by default when
> running `ls -la`, sorry.
>
> One way to prevent the above from happening is by using 'nouser_xattr'
> mount option, which would disable getfattr/setfattr entirely, so `ls
> -la` wouldn't attempt to llistxattr(2) each file over directory listing.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.