On Sun, Apr 10, 2022 at 10:53:04PM +0800, Eryu Guan wrote: > On Wed, Mar 16, 2022 at 01:25:13PM -0700, Boris Burkov wrote: > > There are some btrfs specific fsverity scenarios that don't map > > neatly onto the tests in generic/574 like holes, inline extents, > > and preallocated extents. Cover those in a btrfs specific test. > > > > This test relies on the btrfs implementation of fsverity in the patch: > > btrfs: initial fsverity support > > > > and on btrfs-corrupt-block for corruption in the patches titled: > > btrfs-progs: corrupt generic item data with btrfs-corrupt-block > > btrfs-progs: expand corrupt_file_extent in btrfs-corrupt-block > > > > Signed-off-by: Boris Burkov <boris@xxxxxx> > > --- > > tests/btrfs/290 | 168 ++++++++++++++++++++++++++++++++++++++++++++ > > tests/btrfs/290.out | 25 +++++++ > > 2 files changed, 193 insertions(+) > > create mode 100755 tests/btrfs/290 > > create mode 100644 tests/btrfs/290.out > > > > diff --git a/tests/btrfs/290 b/tests/btrfs/290 > > new file mode 100755 > > index 00000000..f9acd55a > > --- /dev/null > > +++ b/tests/btrfs/290 > > @@ -0,0 +1,168 @@ > > +#! /bin/bash > > +# SPDX-License-Identifier: GPL-2.0 > > +# Copyright (C) 2021 Facebook, Inc. All Rights Reserved. > > I noticed that all patches have 2021 in copyright statement, should be > updated to 2022? > > And I'd like btrfs folks to help review these 2 btrfs specific tests. I did not do a deep review so no rev-by tag, but overall it looks sane to me, also we'd rather like to have some fsverity tests in the suite and fix them later eventually than nothing.
|