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.
