[Pvfs2-developers] ACL errors using LTP tests

[Phil Carns]

I am fairly sure that I was running this with the current CVS head.  We 
originally saw these latest problems in our local tree after a vendor 
merge, but I switched to the HEAD version from Clemson this afternoon to 
double check that we didn't introduce anything on our end (that's when I 
saw the memory problems from the encoder that Sam has since fixed).

I will try repeating this on a system with a stock kernel.org kernel to 
see if there is anything odd about these rhel4 kernels, but for some 
reason I am having some problem (not pvfs2 related) getting the test 
script to run on my normal development box.

-Phil

Murali Vilayannur wrote:
> Hi Phil,
> Drat.. this ACL thing is really proving to be annoying :)
> I dont see any errors on FC5 (2.6.16 kernels) as far as I can tell..
> 
> 
>>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.
> 
> 
> Was this with the cvs head? I thought I updated the error messages..
> 
> 
>>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
> 
> 
> Again, I thought I fixed all these errors in HEAD.. can you check if you
> are running the latest version?
> 
> 
>>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
> 
> 
> Hmm..setfacl program prints this error message  for ext3 and not for
> pvfs2! wow. So this looks like a case where pvfs2 might be doing the right
> thing and not ext3 :) I will dig up some more..
> 
> 
>>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?
> 
> 
> Hmm.. Nope. getfacl should follow symbolic links with those arguments..
> sigh. let me re-run them and see if I see similar behavior.
> something with the user-space tools is buggy?
> 
> 
>>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!
> 
> 
> Please feel free to remove them from HEAD. I was so defensive when I was
> debugging these tests that I forgot to disable them when I checked the
> changes in.
> 
> I will let you know over the course of the week if I find out anything
> thanks,
> Murali
> 
> 
>  >
> 
>>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
>>
>>