Re: [PATCH v2] generic/449: make the test effective against xfs

["Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>]

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