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

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.