`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?
-- 
Aaron Davies
[email protected]

Reply via email to