On Wed, 2021-07-07 at 13:27 +0800, Eryu Guan wrote: > On Tue, Jul 06, 2021 at 06:56:41AM -0400, Jeff Layton wrote: > > On Mon, 2021-07-05 at 19:04 +0800, Zorro Lang wrote: > > > On Fri, Jul 02, 2021 at 09:40:24AM -0400, Jeff Layton wrote: > > > > We had a broken optimization in cephfs and netfs lib that could cause > > > > part of a page to be improperly zeroed-out when writing to an offset > > > > that was beyond the EOF but in an existing page. > > > > > > > > Add a simple test that would have caught this. > > > > > > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > > > > --- > > > > tests/generic/639 | 39 +++++++++++++++++++++++++++++++++++++++ > > > > tests/generic/639.out | 5 +++++ > > > > 2 files changed, 44 insertions(+) > > > > create mode 100755 tests/generic/639 > > > > create mode 100644 tests/generic/639.out > > > > > > > > v3: adapt to new test template > > > > > > > > diff --git a/tests/generic/639 b/tests/generic/639 > > > > new file mode 100755 > > > > index 000000000000..c30f7644a2fc > > > > --- /dev/null > > > > +++ b/tests/generic/639 > > > > @@ -0,0 +1,39 @@ > > > > +#! /bin/bash > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +# Copyright (c) 2021, Jeff Layton <jlayton@xxxxxxxxxx> > > > > +# > > > > +# FS QA Test No. 639 > > > > +# > > > > +# Open a file and write a little data to it. Unmount (to clean out the cache) > > > > +# and then mount again. Then write some data to it beyond the EOF and ensure > > > > +# the result is correct. > > > > +# > > > > +# Prompted by a bug in ceph_write_begin that was fixed by commit 827a746f405d. > > > > +# > > > > +. ./common/preamble > > > > +_begin_fstest auto quick rw > > > > + > > > > +# Import common functions. > > > > +. ./common/filter > > > > + > > > > +# real QA test starts here > > > > +_supported_fs generic > > > > +_require_test > > > > + > > > > +testfile="$TEST_DIR/test_write_begin.$$" > > > > + > > > > +# write some data to file and fsync it out > > > > +$XFS_IO_PROG -f -c "pwrite -q 0 32" $testfile > > > > > > Looks good to me, if you've used this case to reproduce that issue. > > > > > > Just one question, the comment says "fsync it out", does that mean we need an > > > explicit "fsync" call (e.g. -c "pwrite -q 0 32" -c "fsync") to reproduce this > > > bug? Or there's an implicit "fsync" somewhere? > > > > > > > > > > No, there is no implicit fsync. This is holdover from copy/paste that I > > did from another test. The patch is already merged now, but if we expand > > this test to cover other cases, I'll plan to clean up the comment then. > > > > Thanks, > > Jeff > > > > > > > > > + > > > > +# cycle the mount to clean out the pagecache > > > > +_test_cycle_mount > > I think this cycle mount accounts as an implicit fsync? > Yes, the data should get synced out naturally during a umount. The comment is still a bit misleading though since it may not happen until this point. > > > > + > > > > +# now, write to the file (near the end) > > > > +$XFS_IO_PROG -c "pwrite -q 32 32" $testfile > > > > + > > > > +# dump what we think is in there > > > > +echo "The result should be 64 bytes filled with 0xcd:" > > > > +hexdump -C $testfile > > > > + > > > > +status=0 > > > > +exit > > > > diff --git a/tests/generic/639.out b/tests/generic/639.out > > > > new file mode 100644 > > > > index 000000000000..9bf0bac96864 > > > > --- /dev/null > > > > +++ b/tests/generic/639.out > > > > @@ -0,0 +1,5 @@ > > > > +QA output created by 639 > > > > +The result should be 64 bytes filled with 0xcd: > > > > +00000000 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd |................| > > > > +* > > > > +00000040 > > > > -- > > > > 2.31.1 > > > > > > > > > > > -- > > Jeff Layton <jlayton@xxxxxxxxxx> -- Jeff Layton <jlayton@xxxxxxxxxx>
