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

View this message in rfc822 format

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: bug#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share
Date: Sat, 9 Nov 2024 17:16:13 +0000

On 03/10/2024 15:28, Pádraig Brady wrote:
> 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.

I can confirm that the following commit fixes both issues above:
https://github.com/coreutils/coreutils/commit/b857d66b5

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

This is still an issue here.

thanks,
Pádraig

Previous Next

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