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