[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