[Pvfs2-developers] ACL errors using LTP tests

[Murali Vilayannur]

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
>
>