Re: [PATCH] xfs/841: create a block device that must exist

[Christoph Hellwig <hch@lst.de>]

On Tue, Mar 03, 2026 at 09:53:00AM -0800, Darrick J. Wong wrote:
> On Mon, Feb 02, 2026 at 09:57:01AM +0100, Christoph Hellwig wrote:
> > This test currently creates a block device node for /dev/ram0,
> > which isn't guaranteed to exist, and can thus cause the test to
> > fail with:
> > 
> > mkfs.xfs: cannot open $TEST_DIR/proto/blockdev: No such device or address
> > 
> > Instead, create a node for the backing device for $TEST_DIR, which must
> > exist.
> 
> Hrm.  I'm still noticing regressions with this test, particularly when
> the blocksize of the test filesystem is different from the block size
> of the $IMG_FILE filesystem.

That is with the test in general, and not because of the block device
fix, right?  Your description seems to indicate that, I'm just a bit
confused as it is replying to my incremental patch.

> So I started looking for fsblock discrepancies between
> xfs_reproducible_test.img.[1-3] and noticed that EOF block contents are
> different if the file being copied in has sparse holes in it that are
> not aligned to the fsblock size of the new filesystem.

Oooh.

> Next, the region at 3k causes mkfs to re-call libxfs_file_write, but
> this time it writes 3072 bytes of zeroes and 1024 bytes of copied-in
> data, thus obliterating the first write.
> 
> That bug's on me,

Yeah.


> and I'll fix it in writefile by rounding data_pos and
> hole_pos outward as needed to be aligned to the block size of the copied
> in filesystem.  And I'll update xfs/841 to compare $PROTO_DIR against
> what's in the new filesystem.
> 
> That fixes the data corruption problem, but then the test still fails
> because now the space map isn't the same between mkfs invocations.

Aarg.  But I'm glad we got a test for this feature that's uncovering
old buggy/sloppy libxfs code..