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 > > [email protected] > > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers > > _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
