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