On Tue, Jun 21, 2022 at 05:07:10PM -0700, Luis Chamberlain wrote: > On Thu, Jun 16, 2022 at 11:27:41AM -0700, Leah Rumancik wrote: > > https://gist.github.com/lrumancik/5a9d85d2637f878220224578e173fc23. > > The coverage for XFS is using profiles which seem to come inspired > by ext4's different mkfs configurations. The configs I am using for the backports testing were developed with Darrick's help. If you guys agree on a different set of configs, I'd be happy to update my configs moving forward. As there has been testing of these patches on both 5.10 with those configs as well as on 5.15 with my configs, I don't think this should be blocking for this set of patches. - Leah > > Long ago (2019) I had asked we strive to address popular configurations > for XFS so that what would be back then oscheck (now kdevops) can cover > them for stable XFS patch candidate test consideration. That was so long > ago no one should be surprised you didn't get the memo: > > https://lkml.kernel.org/r/20190208194829.GJ11489@xxxxxxxxxxxxxxxxxxxxxxxxx > > This has grown to cover more now: > > https://github.com/linux-kdevops/kdevops/blob/master/playbooks/roles/fstests/templates/xfs/xfs.config > > For instance xfs_bigblock and xfs_reflink_normapbt. > > My litmus test back then *and* today is to ensure we have no regressions > on the test sections supported by kdevops for XFS as reflected above. > Without that confidence I'd be really reluctant to support stable > efforts. > > If you use kdevops, it should be easy to set up even if you are not > using local virtualization technologies. For instance I just fired > up an AWS cloud m5ad.4xlarge image which has 2 nvme drives, which > mimics the reqs for the methodology of using loopback files: > > https://github.com/linux-kdevops/kdevops/blob/master/docs/seeing-more-issues.md > > GCE is supported as well, so is Azure and OpenStack, and even custom > openstack solutions... > > Also, I see on the above URL you posted there is a TODO in the gist which > says, "find a better route for publishing these". If you were to use > kdevops for this it would have the immediate gain in that kdevops users > could reproduce your findings and help augment it. > > However if using kdevops as a landing home for this is too large for you, > we could use a new git tree which just tracks expunges and then kdevops can > use it as a git subtree as I had suggested at LSFMM. The benefit of using a > git subtree is then any runner can make use of it. And note that we > track both fstests and blktests. > > The downside is for kdevops to use a new git subtree is just that kdevops > developers would have to use two trees to work on, one for code changes just > for kdevops and one for the git subtree for expunges. That workflow would be > new. I don't suspect it would be a really big issue other than addressing the > initial growing pains to adapt. I have used git subtrees before extensively > and the best rule of thumb is just to ensure you keep the code for the git > subtree in its own directory. You can either immediately upstream your > delta or carry the delta until you are ready to try to push those > changes. Right now kdevops uses the directory workflows/fstests/expunges/ > for expunges. Your runner could use whatever it wishes. > > We should discuss if we just also want to add the respective found > *.bad, *.dmesg *.all files for results for expunged entries, or if > we should be pushing these out to a new shared storage area. Right now > kdevops keeps track of results in the directory workflows/fstests/results/ > but this is a path on .gitignore. If we *do* want to use github and a > shared git subtree perhaps a workflows/fstests/artifacts/kdevops/ would > make sense for the kdevops runner ? Then that namespace allows other > runners to also add files, but we all share expunges / tribal knowledge. > > Thoughts? > > Luis
