On Tue, Apr 16, 2024 at 05:37:55PM -0700, Darrick J. Wong wrote:
> On Tue, Apr 16, 2024 at 04:51:08PM -0700, Luis Chamberlain wrote:
> > This test is rather simple, and somehow we managed to capture a
> > non-crash failure. The test was added to fstests via fstests commit
> > 0c95fadc35c8e450 ("expand 252 with more corner case tests") which
> > essentially does this:
> >
> > + $XFS_IO_PROG $xfs_io_opt -f -c "truncate $block_size" \
> > + -c "pwrite 0 $block_size" $sync_cmd \
> > + -c "$zero_cmd 128 128" \
> > + -c "$map_cmd -v" $testfile | $filter_cmd
> >
> > The map_cmd in this case is: 'bmap -p'. So the test does:
> >
> > a) truncates data to the block size
> > b) sync
> > c) zero-fills the the blocksize
>
> Which subtest is this?
It's the:
17. data -> hole in single block file
> I've seen periodic failures in xfs/242 that I can't reproduce either:
Oh good to hear.
> --- /tmp/fstests/tests/xfs/242.out 2024-02-28 16:20:24.448887914 -0800
> +++ /var/tmp/fstests/xfs/242.out.bad 2024-04-15 17:36:46.736000000 -0700
> @@ -6,8 +6,7 @@ QA output created by 242
> 1aca77e2188f52a62674fe8a873bdaba
> 2. into allocated space
> 0: [0..127]: data
> -1: [128..383]: unwritten
> -2: [384..639]: data
> +1: [128..639]: unwritten
> 2f7a72b9ca9923b610514a11a45a80c9
> 3. into unwritten space
> 0: [0..639]: unwritten
Oh curious, you hit #2 while I saw #17.
VM or bare metal? If VM, real drive or sparse files? Mine guest files
are virtio drives on files placed on the host on an XFS partition, the
guest uses btrfs truncated files for the sparse files and loopback
devices.
ie: TEST_DEV=/dev/loop16
kdevops@base-xfs-reflink-2k ~ $ sudo losetup -a| grep loop16
/dev/loop16: [0038]:268 (/media/sparsefiles/sparse-disk16)
kdevops@base-xfs-reflink-2k ~ $ df -h /media/sparsefiles/sparse-disk16
Filesystem Size Used Avail Use% Mounted on
/dev/vdc 100G 408M 96G 1% /media/sparsefiles
kdevops@base-xfs-reflink-2k ~ $ du -hs /media/sparsefiles/sparse-disk16
70M /media/sparsefiles/sparse-disk16
kdevops@base-xfs-reflink-2k ~ $ mount | grep -E "sparse|loop16"
/dev/vdc on /media/sparsefiles type btrfs (rw,relatime,discard=async,noacl,space_cache=v2,subvolid=5,subvol=/)
/dev/loop16 on /media/test type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
> It's very strange to me that the block map changes but the md5 doesn't?
Great point! How is that possible?
> The pwrite should have written 0xcd into the file and then the space
> between 64k and 192K got replaced with an unwritten extent. But
> everything between 192K and 320K should still be written data.
Luis
