RE: 回复: 回复: 回复: 回复: HFS/HFS+ maintainership action items

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

On Sat, 2025-05-03 at 01:39 -0400, Theodore Ts'o wrote:
> On Fri, May 02, 2025 at 07:14:26PM +0000, Viacheslav Dubeyko wrote:
> > On Thu, 2025-05-01 at 23:01 -0400, Theodore Ts'o wrote:
> > > Hey, in case it would be helpfui, I've added hfs support to the
> > > kvm-xfstests/gce-xfstests[1] test appliance.  Following the
> > > instructions at [2], you can now run "kvm-xfstests -c hfs -g auto" to
> > > run all of the tests in the auto group.  If you want to replicate the
> > > failure in generic/001, you could run "kvm-fstests -c hfs generic/001".
> > > 
> > 
> > Yes, it is really helpful! Sounds great! Let me try this framework for HFS/HFS+.
> > Thanks a lot.
> 
> FYI, I'm using the hfsprogs from Debian, which at the moment only
> supports HFS+.  The prebuilt test appliance for {kvm,gce}-xfstests are
> based on Debian Stable (Bookworm), but I am building test appliances
> using Debian Testing (Trixie).  However, for the purposes of hfsprogs,
> both Debian Bookwrm and Trixie are based on the 540.1 version of
> hfsprogs.
> 
> But there are plenty of bugs to fix until we can manage to get a
> version of hfsprogs that supports HFS --- also I'd argue that for many
> users support of HFS+ is probably more useful.
> 

Yeah, HFS+ is more important. And, yes, we need to manage a lot of bugs yet.

> If you find some test failures which are more about test bugs than
> kernel bug, so we can add them to exclude files.  For example, in
> /root/fs/ext4/exclude I have things like:
> 
> // generic/04[456] tests how truncate and delayed allocation works
> // ext4 uses the data=ordered to avoid exposing stale data, and
> // so it uses a different mechanism than xfs.  So these tests will fail
> generic/044
> generic/045
> generic/046
> 

Yes, makes sense. Let us identify such cases at first.

> Since I aso test LTS kernels, and sometimes it's not practcal to
> backport fixes to older kernels we can also do versioned excludes.
> For example, I have in /root/fs/global_exclude entries like:
> 
> #if LINUX_VERSION_CODE < KERNEL_VERSION(6,6,30)
> // This test failure is fixed by commit 631426ba1d45q ("mm/madvise:
> // make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly"),
> // which first landed in v6.9, and was backported to 6.6.30 as commit
> // 631426ba1d45.  Unfortunately, it's too involved to backport it and its
> // dependencies to the 6.1 or earlier LTS kernels
> generic/743
> #endif
> 
> Finally, I have things set up to automatically run tests when a branch
> on a git tree that I'm watching changes.  For exmaple:
> 
> gce-xfstests ltm -c ext4/all,xfs/all,btrfs/all,f2fs/all -g auto --repo https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next   --watch fs-next
> 
> gce-xfstests ltm -c ext4/all,xfs/all -g auto --repo stable-rc.git --watch linux-6.12.y
> 
> gce-xfstests ltm -c ext4/all,xfs/all -g auto --repo stable-rc.git --watch linux-6.6.y
> 
> If it's helpful, I can set up watchers for hfs and send them to you or
> some mailing list once the number of failures are reduced toa
> manageable number.
> 

Sounds great! But we definitely have to reduce the number of bugs to manageable
level at first. :)

Thanks,
Slava.