Re: [LSF/MM TOPIC] FS, MM, and stable trees

[Josef Bacik <josef@toxicpanda.com>]

On Wed, Mar 09, 2022 at 11:00:49AM -0800, Luis Chamberlain wrote:
> On Wed, Mar 09, 2022 at 01:49:18PM -0500, Josef Bacik wrote:
> > On Wed, Mar 09, 2022 at 10:41:53AM -0800, Luis Chamberlain wrote:
> > > On Tue, Mar 08, 2022 at 11:40:18AM -0500, Theodore Ts'o wrote:
> > > > One of my team members has been working with Darrick to set up a set
> > > > of xfs configs[1] recommended by Darrick, and she's stood up an
> > > > automated test spinner using gce-xfstests which can watch a git branch
> > > > and automatically kick off a set of tests whenever it is updated.
> > > 
> > > I think its important to note, as we would all know, that contrary to
> > > most other subsystems, in so far as blktests and fstests is concerned,
> > > simply passing a test once does not mean there is no issue given that
> > > some test can fail with a failure rate of 1/1,000 for instance.
> > > 
> > 
> > FWIW we (the btrfs team) have been running nightly runs of fstests against our
> > devel branch for over a year and tracking the results.
> 
> That's wonderful, what is your steady state goal? And do you have your
> configurations used public and also your baseline somehwere? I think
> this later aspect could be very useful to everyone.
> 

Yeah I post the results to http://toxicpanda.com, you can see the results from
the runs, and http://toxicpanda.com/performance/ has the nightly performance
numbers and graphs as well.

This was all put together to build into something a little more polished, but
clearly priorities being what they are this is as far as we've taken it.  For
configuration you can see my virt-scripts here
https://github.com/josefbacik/virt-scripts which are what I use to generate the
VM's to run xfstests in.

The kernel config I use is in there, I use a variety of btrfs mount options and
mkfs options, not sure how interesting those are for people outside of btrfs.

Right now I have a box with ZNS drives waiting for me to set this up on so that
we can also be testing btrfs zoned support nightly, as well as my 3rd
RaspberryPi that I'm hoping doesn't blow up this time.

I have another virt setup that uses btrfs snapshots to create a one off chroot
to run smoke tests for my development using virtme-run.  I want to replace the
libvirtd vms with virtme-run, however I've got about a 2x performance difference
between virtme-run and libvirtd that I'm trying to figure out, so right now all
the nightly test VM's are using libvirtd.

Long, long term the plan is to replace my janky home setup with AWS VM's that
can be fired from GitHub actions whenever we push branches, that way individual
developers can get results for their patches before they're merged, and we don't
have to rely on my terrible python+html for test results.

> Yes, everyone's test setup can be different, but this is why I went with
> a loopback/truncated file setup, it does find more issues and so far
> these have all been real.
> 
> It kind of begs the question if we should adopt something like kconfig
> on fstests to help enable a few test configs we can agree on. Thoughts?
> 

For us (and I imagine other fs'es) the kconfigs are not interesting, it's the
combo of different file system features that can be toggled on and off via mkfs
as well as different mount options.  For example I run all the different mkfs
features through normal mount options, and then again with compression turned
on.  Thanks,

Josef