Re: [PATCH] fstests: btrfs/153: Remove it from auto group

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Sat, Feb 1, 2020 at 9:41 AM Eryu Guan <guaneryu@xxxxxxxxx> wrote:
>
> On Tue, Jan 14, 2020 at 08:50:44PM +0800, Qu Wenruo wrote:
> > This test case always fail after commit c6887cd11149 ("Btrfs: don't do
> > nocow check unless we have to").
> > As btrfs no longer checks nodatacow at buffered write time.
> >
> > That commits brings in a big performance enhancement, as that check is
> > not cheap, but breaks qgroup, as write into preallocated space now needs
> > extra space.
> >
> > There isn't yet a good solution (reverting that patch is not possible,
> > and only check nodatacow for quota enabled case is very bug prune due to
> > quite a lot code change).
> >
> > We may solve it using the new ticketed space reservation facility, but
> > that won't come into fruit anytime soon.
> >
> > So let's just remove that test case from 'auto' group, but still keep
> > the test case to inform we still have a lot of work to do.
> >
> > Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
>
> I'd like to see an ACK from btrfs folks. Thanks!
>
> Eryu
>
> > ---
> >  tests/btrfs/group | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/btrfs/group b/tests/btrfs/group
> > index 697b6a38ea00..3c554a194742 100644
> > --- a/tests/btrfs/group
> > +++ b/tests/btrfs/group
> > @@ -155,7 +155,7 @@
> >  150 auto quick dangerous
> >  151 auto quick volume
> >  152 auto quick metadata qgroup send
> > -153 auto quick qgroup limit
> > +153 quick qgroup limit

Hmm, if removing from auto it might make sense to also remove it
from quick, because people often use quick as a sanity regression group.

The issue at hand is a recurring pattern.
It is also been discussed recently about generic/484:
https://lore.kernel.org/fstests/20200131164619.GA13005@xxxxxxxxxxxxx/

I also handled something like this with:
fdb69864 overlay/061: remove from auto and quick groups

I suggest adding a group 'broken' to mark known/wontfix issues
then a default regression test could run -g auto -x broken
or -g quick -x broken for a quick regression sanity.

Thoughts?

Amir.



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux