Hi Yangtao, On Mon, 2025-06-09 at 18:52 +0800, Yangtao Li wrote: > Hi Slava and Adrian, > > 在 2025/6/6 06:41, Viacheslav Dubeyko 写道: > > Hi Adrian, Yangtao, > > > > We have failure for generic/740 test: > > > > ./check generic/740 > > FSTYP -- hfs > > PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc4+ #8 SMP > > PREEMPT_DYNAMIC Thu May 1 16:43:22 PDT 2025 > > MKFS_OPTIONS -- /dev/loop51 > > MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch > > > > generic/740 - output mismatch (see /home/slavad/XFSTESTS-2/xfstests- > > dev/results//generic/740.out.bad) > > --- tests/generic/740.out 2025-04-24 12:48:45.964286739 -0700 > > +++ /home/slavad/XFSTESTS-2/xfstests- > > dev/results//generic/740.out.bad 2025-06-05 15:25:18.071217224 -0700 > > @@ -1,2 +1,16 @@ > > QA output created by 740 > > Silence is golden. > > +Failed - overwrote fs type bfs! > > +Failed - overwrote fs type cramfs! > > +Failed - overwrote fs type exfat! > > +Failed - overwrote fs type ext2! > > +Failed - overwrote fs type ext3! > > ... > > (Run 'diff -u /home/slavad/XFSTESTS-2/xfstests-dev/tests/generic/740.out > > /home/slavad/XFSTESTS-2/xfstests-dev/results//generic/740.out.bad' to see the > > entire diff) > > Ran: generic/740 > > Failures: generic/740 > > Failed 1 of 1 tests > > > > As far as I can see, the workflow of the test is to reformat the existing file > > system by using the forcing option of mkfs tool (for example, -F of mkfs.ext4). > > And, then, it tries to reformat the partition with existing file system (ext4, > > xfs, btrfs, etc) by HFS/HFS+ mkfs tool with default option. By default, it is > > expected that mkfs tool should refuse the reformat of partition with existing > > file system. However, HFS/HFS+ mkfs tool easily reformat the partition without > > any concerns or questions: > > > > sudo mkfs.ext4 /dev/loop51 > > mke2fs 1.47.0 (5-Feb-2023) > > /dev/loop51 contains a hfs file system labelled 'untitled' > > Proceed anyway? (y,N) n > > > > sudo mkfs.ext4 -F /dev/loop51 > > mke2fs 1.47.0 (5-Feb-2023) > > /dev/loop51 contains a hfs file system labelled 'untitled' > > Discarding device blocks: done > > Creating filesystem with 2621440 4k blocks and 655360 inodes > > Filesystem UUID: 2062e-d8d5-4731-9f3d-dddcf1aa73ee > > Superblock backups stored on blocks: > > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 > > > > Allocating group tables: done > > Writing inode tables: done > > Creating journal (16384 blocks): done > > Writing superblocks and filesystem accounting information: done > > > > sudo mkfs.hfs /dev/loop51 > > Initialized /dev/loop51 as a 10240 MB HFS volume > > > > It looks like we need to modify the HFS/HFS+ mkfs tool to refuse the reformat of > > existing file system and to add the forcing option. > > I wonder if this is a good time to reimplement hfs-progs in rust. > Frankly speaking, I don't see the point to re-write the hfs-progs in Rust for multiple reasons: (1) mostly, the main use-case that HFS/HFS+ partition is created under Mac OS and somebody tries to mount it under Linux to access data; (2) Apple is the owner of the code on Mac OS side and it's not good to significantly deviate from the Apple's state of the code; (3) I believe that Apple considers hfs-progs as obsolete code and they don't want any significant changes in it; (4) the hfs-progs is user-space tool, it is not frequently used, and even it fails, then there is no much harm. The point for Linux kernel driver is completely different: (1) it's completely independent from Apple implementation and we can modify in any reasonable way; (2) the memory safety and stability of kernel driver is more important; (3) using Rust for HFS/HFS+ driver is a practically new technology adoption; (4) potentially, re-writing HFS/HFS+ drivers in Rust could remove multiple existing (and unknown yet) bugs and improve efficiency of it; (5) re-writing HFS/HFS+ kernel driver could be potentially interesting for involving new guys into HFS/HFS+ activity but hfs-progs is not so attractive, from my point of view. Thanks, Slava.
