GNU bug report logs - #73418
ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share

Previous Next

Full log

Message #35 received at 73418 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>,
 Gian Domenico Bonazzoli <gbonazzoli <at> bonaz.it>
Cc: 73418 <at> debbugs.gnu.org
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
Date: Thu, 3 Oct 2024 15:28:59 +0100

On 03/10/2024 07:39, Paul Eggert wrote:
> On 2024-10-02 15:14, Pádraig Brady wrote:
>>
>> I notice that tests/ls/getxattr-speedup.sh is failing now,
>> which I've not looked into yet.
> 
> I'm not seeing that after the changes I committed this evening. If you
> can still reproduce it please let us know the details.

I can still repro.
I'm on BTRFS though I don't think that matters for this test.
I suspect the caching is being bypassed as we don't return ENOTSUP
in all cases where the underlying lgetxattr() returns ENOTSUP.
Actually in cases where the caching in file_has_aclinfo_cache()
is effective, and file_has_aclinfo() is bypassed, we get UMR
due to the uninitialized aclinfo struct.
So the whole interaction with file_has_aclinfo_cache() needs looking at.

If I remove the caching I also see issues with symlink handling,
where security contexts aren't read for symlinks.
Comparing system ls, with latest:
  $ ls -lZ INSTALL
  lrwxrwxrwx. 1 padraig padraig unconfined_u:object_r:user_home_t:s0 ...

  $ src/ls -lZ INSTALL
  lrwxrwxrwx 1 padraig padraig ? ...

I pushed two other fixes:

1. Since tests/ls/no-cap.sh is now always skipped.
I adjusted the test to avoid that.

2. ls -Z always output an error, so fixed up the
condition around the error() call in that case.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.