On 05/11/2012 09:25 AM, Aaron Davies wrote: > `ls -l' (v. 8.12) is often brutally slow on our networked filesystems (nfs & > afs) at work (~40s for a 1500 file directory). stracing reveals that almost > all the time (~4.5ms per call) is spent in lgetxattr, which doesn't even > appear to be supported on these fs's. (all the calls return -1 and report > EOPNOTSUPP (as do all the calls to getxattr, but they only seem to take ~43µs > each, slightly less than the lstat's which are doing the actual work (~39µs), > so that isn't such a big deal.) > > is this expected behavior?
Upgrade. From the NEWS for 8.16 (and 8.17 is the current release), we have: ls can be much more efficient, especially with large directories on file systems for which getfilecon-, ACL-check- and XATTR-check-induced syscalls fail with ENOTSUP or similar. -- Eric Blake [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
