[Pvfs2-developers] ACL errors using LTP tests

[Phil Carns]

Hi Murali,

Thanks for working on this stuff.  I think we are still seeing a few 
problems, though.  We are running tests on a redhat 2.6.9-34.0.2.ELsmp 
kernel.

There is still one failure listed on PVFS2:

   Do not follow symlinks.
   but extended user attributes are disallowed for symbolic links
   getfattr: shared/team2/symlinkfile1: Operation not supported
   FAILED: getfattr: Do not follow symlinks.

Towards the end of the test, there are also some extra error messages 
generated, though these aren't registered as a "FAILED" by the test script:

   attr -r to remove the named object
   getfattr: shared/team1/symlinkfile1: Operation not supported
   getfattr: shared/team2/symlinkfile1: Operation not supported
   getfattr: shared/team1/symlinkfile1: Operation not supported
   getfattr: shared/team2/symlinkfile1: Operation not supported

There is one other difference between ext3 and pvfs2, though it isn't 
clear if this is an error or not.  At one point in the test, ext3 shows 
this output:

   SUCCESS: Chown correct
   setfacl: shared/symlinkdir1: Only directories can have default ACLs

While PVFS2 only shows this:

   SUCCESS: Chown correct

David also pointed out another interesting piece of information.  There 
is a line in the test script that runs "getfacl -RL shared > tmp1". 
This is recursively dumping acls from one of the test directory.  If you 
compare the output of this command in PVFS2 and EXT3 (by saving that 
tmp1 file) there are some significant differences, aside from the 
expected ordering and path differences.  This is one example (some 
objects, particularly related to symlinks, don't show up on pvfs2), 
though there may be some other differences:

    $ grep symlinkdir1 /tmp/tmp1.ext3
    # file: shared/symlinkdir1
    # file: shared/symlinkdir1/symlinkfile1
    # file: shared/symlinkdir1/newfile1
    # file: shared/symlinkdir1/file1
    # file: shared/symlinkdir1/newfile3
    # file: shared/symlinkdir1/newfile2
    $ grep symlinkdir1 /tmp/tmp1.pvfs2
    $

Do you have any of these same differences on your platform?

Oh, and one other thing.  The acl code in the kernel is printing a lot 
of information into dmesg right now.  After running these tests there 
are many duplicates of each of the following messages in the kernel logs:

    pvfs2_acl_chmod: get acl (access) failed with 0
    pvfs2_get_acl failed due to no acls!


thanks again,
-Phil

Murali Vilayannur wrote:
> David,
> 
> I think I have fixed the last of the failed tests with LTP and ACLs.
> (replaced EOPNOTSUPP with EACCES). I have tested this only on FC5.
> Hopefully, things work on your platform now. It is possible that the
> differences we see could be because of kernel versions or something?
> Please let me know if anything else fails,
> Thanks,
> Murali
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers