[RFC] Why generic/073 is generic but not btrfs specific?

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

Hello,

Running generic/073 for the case of HFS+ finishes with volume corruption:

sudo ./check generic/073
FSTYP -- hfsplus
PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC
Wed Oct 1 15:02:44 PDT 2025
MKFS_OPTIONS -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/073 _check_generic_filesystem: filesystem on /dev/loop51 is inconsistent
(see XFSTESTS-2/xfstests-dev/results//generic/073.full for details)

Ran: generic/073
Failures: generic/073
Failed 1 of 1 tests

sudo fsck.hfsplus -d /dev/loop51
** /dev/loop51
Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
Executing fsck_hfs (version 540.1-Linux).
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
Invalid directory item count
(It should be 1 instead of 0)
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000
CBTStat = 0x0000 CatStat = 0x00004000
** Repairing volume.
** Rechecking volume.
** Checking non-journaled HFS Plus Volume.
The volume name is untitled
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** The volume untitled was repaired successfully.

Initially, I considered that something is wrong with HFS+ driver logic. But
after testing and debugging the issue, I believe that HFS+ logic is correct.

As far as I can see, the generic/073 is checking specific btrfs related case:

# Test file A fsync after moving one other unrelated file B between directories
# and fsyncing B's old parent directory before fsyncing the file A. Check that
# after a crash all the file A data we fsynced is available.
#
# This test is motivated by an issue discovered in btrfs which caused the file
# data to be lost (despite fsync returning success to user space). That btrfs
# bug was fixed by the following linux kernel patch:
#
#   Btrfs: fix data loss in the fast fsync path

The test is doing these steps on final phase:

mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar
$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1
$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo

So, we move file bar from testdir_1 into testdir_2 folder. It means that HFS+
logic decrements the number of entries in testdir_1 and increments number of
entries in testdir_2. Finally, we do fsync only for testdir_1 and foo but not
for testdir_2. As a result, this is the reason why fsck.hfsplus detects the
volume corruption afterwards. As far as I can see, the HFS+ driver behavior is
completely correct and nothing needs to be done for fixing in HFS+ logic here.

But what could be the proper solution? Should generic/073 be excluded from
HFS/HFS+ xfstests run? Or, maybe, generic/073 needs to be btrfs specific? Am I
missing something here?

Thanks,
Slava.