[Pvfs2-developers] ACL/getxattr overhead in ls

[Rob Ross]

Hi Phil,

Yes, it seems reasonable to just tell the kernel that they aren't there 
in the case that ACLs are disabled. However, this might lead to a weird 
situation if a user then decides to play with or set these values. Is it 
possible for a user to adjust ACLs even if the file system mount isn't 
currently honoring them?

Just another example of how ls is the worst app ever for file systems.

Rob

Phil Carns wrote:
> 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
> 
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>