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
