On Wed, Aug 02, 2017 at 10:33:34AM -0700, Darrick J. Wong wrote: > On Wed, Aug 02, 2017 at 12:48:09PM -0300, Ernesto A. Fernández wrote: > > On Wed, Aug 02, 2017 at 03:00:30PM +0800, Eryu Guan wrote: > > > On Wed, Aug 02, 2017 at 01:19:34AM -0300, Ernesto A. Fernández wrote: > > > > > > > > +# The content of this file will be used as the value of the attributes > > > > +VFILE=$SCRATCH_MNT/valuefile > > > > +touch $VFILE > > > > +$XFS_IO_PROG -c "pwrite -S 0x2E 0 1k" $VFILE >>$seqres.full 2>&1 > > > > + > > > > > > I think this VFILE is not needed, because .. > > > > > > > # Try to run out of space so setfacl will fail > > > > $XFS_IO_PROG -c "pwrite 0 50m" $TFILE >>$seqres.full 2>&1 > > > > i=1 > > > > +while $SETFATTR_PROG -n trusted.$i -v $(cat $VFILE) $TFILE &>/dev/null; do > > > > > > we can use something like $(perl -e 'print "a"x1024') to generate 1k > > > attr value. > > But we can do 60x better than that on xfs, which supports 64k attr values. > ext4 is adding support for large values too. Thanks for bringing this up. I did know that larger attr values were supported; I set it to 1k on purpose, as I thought that made it more likely to work for all. There are several filesystems I have not tried yet that will probably fail this test. > I guess the complicated part is having to experimentally determine the > maximum attr value size for a given fs and then plugging that in... the > gains for which aren't necessarily obvious aside from reducing test runtime. In this particular test the filesystem has already been mostly filled by xfs_io, so I don't imagine we would see a big difference in runtime. I wouldn't go through all that trouble unless you think other tests will benefit from this. Another thing: right after the filesystem runs out of space for large attribute values, the test will start to set attrs without a value until that fails as well. Otherwise there could still be some room left for the acls. I'm guessing that, if we used 64k values, that could leave up to 64k to be filled by those attributes with no value, which could actually worsen the runtime, if only a bit. Thanks, Ernest -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
