On Fri, Apr 08, 2022 at 09:19:43PM +0200, David Disseldorp wrote: > When testing against an NFS export backed by a Btrfs filesystem, > generic/020 may fail, e.g. > > --- /xfstests/tests/generic/020.out > +++ /xfstests/results/generic/020.out.bad > @@ -47,9 +47,13 @@ > user.snrub="fish2\012" > > *** really long value > -0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > -* > -ATTRSIZE > +attr_set: No space left on device > +Could not set "long_attr" for <TESTFILE> > +attr_get: No data available > +Could not get "long_attr" for <TESTFILE> > +0000000 > +attr_remove: No data available > +Could not remove "long_attr" for <TESTFILE> > > This is due to the MAX_ATTRVAL_SIZE=65536 setting for NFS, which exceeds > the Btrfs (and XFS) limit of MAX_ATTRVAL_SIZE=64. Change NFS to use this > lower bound value. I think that what XFS/UDF/BTRFS set here is bogus. There is *one* test - generic/020 - that uses MAX_ATTRS and MAX_ATTRVAL_SIZE, and it uses MAX_ATTRVAL_SIZE as a byte count. Which means for those 3 filesytems, the correct value for them is 65536, not 64.... This looks like it was broken back when the test was made generic - the dd command before this used a bs=1024, so a maz size of 64 would have been correct. Except the dd command also go changed to use bs=1, which meant 64 bytes.... So, yeah, the test got "broken" for XFS back in 2012 and so the correct fix here is to change (at least) XFS and btrfs to have a MAX_ATTRVAL_SIZE=65536.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
