Hi David, I think I have fixed all but 6 of the tests y'day night. So the errors below have all been fixed in CVS. Incidentally, the fixes for the latter tests will help it pass other LTP tests which were doing something really silly... I will get back to you later today on my progress.. Thanks again for the script! It was very helpful. Murali
> Those tests all failed on our end too. However, I see the following also, > which reports differently than EXT3 > > SUCCESS: ACL_USER_OBJ entry contains the owner execute permissions, > operation success [ Symlink Directory ] > setfacl: shared/team1: No data available > > attr -r to remove the named object > getfattr: shared/team1/symlinkfile1: Operation not supported > getfattr: shared/team2/symlinkfile1: Operation not supported > setfattr: shared: Invalid argument > setfattr: shared/team1: Invalid argument > setfattr: shared/team1/file1: Invalid argument > setfattr: shared/team1/file1: Invalid argument > setfattr: shared/team2: Invalid argument > setfattr: shared/team2/file1: Invalid argument > setfattr: shared/team2/file1: Invalid argument > getfattr: shared/team1/symlinkfile1: Operation not supported > getfattr: shared/team2/symlinkfile1: Operation not supported > > > > > On 8/16/06, Murali Vilayannur <[EMAIL PROTECTED]> wrote: > > > > Thanks for bringing this up, David.. > > Sigh.. there are several tests failing. > > I will get to the bottom of this over the course of this week. > > Hopefully, I can fix them soon :) > > > > Are these the ones failing for you? > > FAILED: ACL_USER entry contains the user permissions, > > but operation denied [ Physical Directory ] > > > > FAILED: ACL_USER entry contains the user permissions, > > but operation denied [ Symlink Directory ] > > > > FAILED: [ touch ] ACL_GROUP entry already contains the group permissions, > > but option success [ Physical Directory ] > > > > FAILED: [ touch ] ACL_GROUP entry already contains the group permissions, > > but option success [ Symlink Directory ] > > > > FAILED: [ touch ] ACL_GROUP_OBJ entry already contains the group owner, > > but option denied [ Physical Directory ] > > > > FAILED: [ touch ] ACL_GROUP_OBJ entry already contains the group owner, > > but option denied [ Symlink Directory ] > > > > FAILED: ACL_OTHER entry contains the user permissions, > > but operation denied [ Physical Directory ] > > > > FAILED: ACL_OTHER entry contains the user permissions, > > but operation denied [ Symlink Directory ] > > > > FAILED: ACL_OTHER do not strick by ACL_MASK [ Physical Directory ] > > > > FAILED: ACL_OTHER do not strick by ACL_MASK [ Symlink Directory ] > > touch: cannot touch `/mnt/pvfs2/ltp-tmp/tacl/shared/team1/newfile1': > > Permission denied > > ls: shared/team1/newfile1: No such file or directory > > > > FAILED: With default ACLs set , new file permission set not correct > > touch: cannot touch `/mnt/pvfs2/ltp-tmp/tacl/shared/team1/newfile2': > > Permission denied > > ls: shared/team1/newfile2: No such file or directory > > > > FAILED: With default ACLs set , new file permission set not correct > > touch: cannot touch `/mnt/pvfs2/ltp-tmp/tacl/shared/team1/newfile3': > > Permission denied > > ls: shared/team1/newfile3: No such file or directory > > > > FAILED: With default ACLs set , new file permission set not correct > > chmod: cannot access `/mnt/pvfs2/ltp-tmp/tacl/shared/team1/newfile3': > > Permission denied > > getfacl: shared/team1/newfile3: No such file or directory > > > > FAILED: Chmod with ACL_USER_OBJ ACL_GROUP_OBJ and ACL_OTHER are not > > correct > > chown: cannot access `shared/team1/newfile2': No such file or directory > > getfacl: shared/team1/newfile2: No such file or directory > > FAILED: Chown are not correct > > > > thanks, > > Murali > > > > On Tue, 15 Aug 2006, David Metheny wrote: > > > > > I've attached an updated version of the tacl_xattr.sh script mentioned > > > below. This should now execute tests for both PVFS2 and EXT3. > > > > > > To run the script > > > - EXT3 or PVFS2 file system must be mounted with acl,user_xattr. > > > - must be root > > > - ./tacl_xattr.sh [ EXT3_DIR | PVFS2_DIR ] > > > > > > There are several tests failing on PVFS2 at the moment. > > > > > > > > > > -----Original Message----- > > > > From: Murali Vilayannur [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, August 08, 2006 2:31 PM > > > > To: David Metheny > > > > Cc: pvfs2-developers@beowulf-underground.org > > > > Subject: Re: [Pvfs2-developers] ACL errors using LTP tests > > > > > > > > Hi David, > > > > Thanks for bringing this up.. > > > > Sorry for taking time to respond to this. > > > > Before I got to the acl tests, I did uncover and fix a few > > > > other bugs some of which were in the LTP script (runltp) and > > > > some of which were in pvfs2. > > > > The runltp script requires a mkdir -m 777 when it creates the > > > > temp directory for many of the tests to work properly (Before > > > > that change, the runltp script was failing even on /tmp for me). > > > > > > > > The tests that continue to fail for me now are > > > > a) the nftw() tests when run as the user "nobody" on a > > > > directory owned by <nobody,root> > > > > b) the writev01 test which passes in a bogus address amongst > > > > valid addresses in the iovec and expects that writev() does > > > > not return -EFAULT. > > > > I think we had this discussion a long time back when the > > > > writev implementation was done and I still havent had a > > > > chance to fix this. > > > > > > > > The acl tests in the LTP suite does something very naive (I > > > > am referring to the acl_file_test and acl_link_test). They > > > > open a file, do a > > > > (l)listxattr() on it, do a (l)getxattr() on the first key and > > > > then do a > > > > (l)setxattr() on it. > > > > For a regular file, we return "system.pvfs2.dh" and "system.pvfs2.md" > > > > as part of listxattr(), and any attempt to do a setxattr() > > > > will obviously fail (currently with -EINVAL) since these are > > > > not settable xtended attributes. > > > > Quite frankly, these acl tests are not worth fixing. > > > > > > > > That said, it would be great if we could modify the > > > > tacl_xattr.sh to somehow work with pvfs2 (It is currently > > > > ext3 specific) since that is really a good acl test... > > > > If there are any other (Acl or otherwise) tests that fail for > > > > you, please let me know and I can take a shot at fixing them. > > > > thanks, > > > > Murali > > > > > > > > On Wed, 2 Aug 2006, David Metheny wrote: > > > > > > > > > We're seeing some acl errors in the LTP tests > > > > (http://ltp.sourceforge.net/). > > > > > This is on a SMP RHEL4 x86_64 server with kernel > > > > 2.6.9-34.0.2. This is > > > > > using the code in the CVS tree on July 19th. I've attached > > > > a test set > > > > > for LTP that runs this. > > > > > > > > > > To run it, do something like this: > > > > > > > > > > # su > > > > > # tar -xvzf ltp-full-20060717.tgz > > > > > # cd ltp-full-20060717 > > > > > # export CFLAGS="-g" > > > > > # make && make install > > > > > # mkdir /mnt/pvfs2/ltp-tmp > > > > > # chmod 777 /mnt/pvfs2/ltp-tmp > > > > > # cp ../pvfs-test-cases runtest/ > > > > > # cp ./testcases/kernel/fs/acls/acl_test01 ./testcases/bin/ > > > > # ./runltp > > > > > -p -l /tmp/ltp.log -d /mnt/pvfs2/ltp-tmp -f pvfs-test-cases 2>&1 > > > > > | tee /tmp/ltp.output > > > > > # tail /tmp/ltp.log > > > > > > > > > > some notes on the above steps: > > > > > ------------------------------- > > > > > - ltp needs to be built and run as root > > > > > - -g CFLAGS helps if you need to run a debugger to track > > > > down failures > > > > > - make install leaves binaries in ltp-full-20050307 directory > > > > > - I don't know if it is strictly required, but it seems like I had > > > > > better luck when running the tests in a subdir with 777 permissions > > > > > - the end of the log file shows a summary (how many tests > > > > passed and > > > > > failed) > > > > > > > > > > > > > > > _______________________________________________ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
