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

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Mar 04, 2026 at 01:55:02PM +0100, Christoph Hellwig wrote:
> 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.

Correct, I'm just complaining about x841 in general.  Your bdev fix
eliminated one of the sources of test failures.

> > 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..

Yeah.  I missed the detail that none of the existing protofile tests
actually tried to import sparse files, let alone checked the results.

I'll try to send the fix patches in a bit but QA blew up last night so I
should probably go figure out why there's suddenly log corruption, or if
some cloud thing got really FUBARd at 17:08 last night.

--D