[Pvfs2-developers] ACL/getxattr overhead in ls

Phil Carns pcarns at wastedcycles.org
Thu May 4 11:29:58 EDT 2006


We have noticed on RedHat RHEL3 and RHEL4 that when you do a long 
listing of a directory (on any file system, not just pvfs2) that the ls 
triggers a getxattr of "system.posix_acl_access" and 
"system.posix_acl_default" for every single entry that is listed.  This 
happens regardless of whether ACLs are enabled for the file system or not.

Digging in the coreutils/ls source, it turns out that ls (with -l 
options at least) is checking to see if any acl's are set on each entry 
so that it can display them differently, maybe with a "+" character.

On RHEL3 at least (2.4 kernel) these extra getxattrs are causing 2 
serialized getxattr requests that are probably significantly slowing 
down the listing, which is a shame because the 2.4 kernel module doesn't 
even support ACLs so there is never any point in checking.

Does it seem reasonable to add a test in the kernel module so that if a) 
acl's are not enabled (which can be determined by checking the super 
block acl flag), and b) the getxattr name matches "system.posix_acl" 
then we just immediately return an appropriate error code rather than 
servicing the getxattr?

The stock coreutils package doesn't currently have this problem, because 
their acl check is broken for Linux.  RedHat supplies a patch with their 
rpm that adds acl checks that work on linux (using the 
acl_extended_file() function rather than the unsupported acl() 
function).  I imagine there are other distributions that have done 
likewise, and probably it will be "fixed" in the official gnu version 
eventually also.

-Phil



More information about the Pvfs2-developers mailing list