On Tue, Mar 22, 2016 at 03:12:25PM -0700, Liu Bo wrote: > On Tue, Mar 22, 2016 at 12:00:13PM +0800, Eryu Guan wrote: > > On Thu, Mar 17, 2016 at 03:56:38PM -0700, Liu Bo wrote: > > > This is to test if COW enabled btrfs can end up with single 4k extents > > > when doing subpagesize buffered writes. > > > > What happens if btrfs is mounted with "nodatacow" option? Does it need > > to _notrun if cow is disabled? > > In my test, the test passes if mounting with "nodatacow". > Yes, it makes sense to have a _notrun for nodatacow. If "nodatacow" btrfs should pass the test as well, then I don't think _notrun is needed, so when it failed, something went wrong. > > > > > > > > > The patch to fix the problem is > > > https://patchwork.kernel.org/patch/8527991/ > > > > > > Signed-off-by: Liu Bo <bo.li.liu@xxxxxxxxxx> > > > --- > > > v2: - Teach awk to know system's pagesize. > > > - Add "Silence is golden" to output. > > > - Use local variables to lower case. > > > - Add comments to make code clear. > > > > This should be v3, and this patch was buried in the v2 thread :) > > Oops, thanks for pointing it out. > > > > > > > > > tests/btrfs/027 | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > tests/btrfs/027.out | 2 ++ > > > tests/btrfs/group | 1 + > > > 3 files changed, 105 insertions(+) > > > create mode 100755 tests/btrfs/027 > > > create mode 100644 tests/btrfs/027.out > > > > > > diff --git a/tests/btrfs/027 b/tests/btrfs/027 > > > new file mode 100755 > > > index 0000000..19d324b > > > --- /dev/null > > > +++ b/tests/btrfs/027 > > > @@ -0,0 +1,102 @@ > > > +#! /bin/bash > > > +# FS QA Test 027 > > > +# > > > +# When btrfs is using cow mode, buffered writes of sub-pagesize can end up with > > > +# single 4k extents. > > > +# Ref: > > > +# "Stray 4k extents with slow buffered writes" > > > +# https://www.spinics.net/lists/linux-btrfs/msg52628.html > > > > After going through this thread, my understanding is that nodatacow > > btrfs should pass this test even on unpatched kernel (e.g. v4.5). But > > my test on v4.5 kernel failed with nodatacow mount option, pagesize > > extent is still found. > > > > I verified it again on my kvm box and it passed with a unpatched v4.5 kernel. > > Can you please show me the 027.full file? > > I can't think of a reason for this.. I'm using v4.5 kernel and v4.4 btrfs-progs, and it's not reproduced everytime. SECTION -- btrfs_nodatacow RECREATING -- btrfs on /dev/sda5 FSTYP -- btrfs PLATFORM -- Linux/x86_64 dhcp-66-86-11 4.5.0 MKFS_OPTIONS -- /dev/sda6 MOUNT_OPTIONS -- -o nodatacow -o context=system_u:object_r:nfs_t:s0 /dev/sda6 /mnt/testarea/scratch btrfs/027 28s ... - output mismatch (see /root/xfstests/results//btrfs_nodatacow/btrfs/027.out.bad) --- tests/btrfs/027.out 2016-03-23 15:39:41.562000000 +0800 +++ /root/xfstests/results//btrfs_nodatacow/btrfs/027.out.bad 2016-03-23 19:37:38.962000000 +0800 @@ -1,2 +1,3 @@ QA output created by 027 Silence is golden +8 ... (Run 'diff -u tests/btrfs/027.out /root/xfstests/results//btrfs_nodatacow/btrfs/027.out.bad' to see the entire diff) Ran: btrfs/027 Failures: btrfs/027 Failed 1 of 1 tests And btrfs/027.full shows: /mnt/testarea/scratch/testfile: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..28863]: 2154496..2183359 28864 0x0 1: [28864..57751]: 2183360..2212247 28888 0x0 2: [57752..85543]: 2212248..2240039 27792 0x0 3: [85544..113239]: 2240040..2267735 27696 0x0 4: [113240..113247]: 2267736..2267743 8 0x0 5: [113248..141999]: 2267744..2296495 28752 0x0 6: [142000..142023]: 2296496..2296519 24 0x0 7: [142024..159799]: 2296520..2314295 17776 0x1 Thanks, Eryu -- 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
