On Sat, Feb 1, 2025 at 12:01 AM Day, Timothy <timday@xxxxxxxxxx> wrote: > > On 1/31/25, 5:11 PM, "Amir Goldstein" <amir73il@xxxxxxxxx <mailto:amir73il@xxxxxxxxx>> wrote: > > On Fri, Jan 31, 2025 at 3:35 AM Andreas Dilger via Lsf-pc > > <lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx <mailto:lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx>> wrote: > > > > > > > > > As Tim mentioned, it is possible to mount a Lustre client (or two) plus one or > > > more MDT/OST on a single ~3GB VM with loopback files in /tmp and run testing. > > > There is a simple script we use to format and mount 4 MDTs and 4 OSTs on > > > temporary loop files and mount a client from the Lustre build tree. > > > > > > There haven't been any VFS patches needed for years for Lustre to be run, > > > though there are a number patches needed against a copied ext4 tree to > > > export some of the functions and add some filesystem features. Until the > > > ext4 patches are merged, it would also be possible to run light testing with > > > Tim's RAM-based OSD without any loopback devices at all (though with a > > > hard limitation on the size of the filesystem). > > > > > > Recommendation: if it is easy to setup loopback lustre server, then the best > > practice would be to add lustre fstests support, same as nfs/afs/cifs can be > > tested with fstests. > > > > > > Adding fstests support will not guarantee that vfs developers will run fstest > > with your filesystem, but if you make is super easy for vfs developers to > > test your filesystem with a the de-facto standard for fs testing, then at least > > they have an option to verify that their vfs changes are not breaking your > > filesystem, which is what upstreaming is supposed to provide. > > I was hoping to do exactly that. I've been able run to fstests on Lustre > (in an adhoc manner), but I wanted to put together a patch series to > add proper support. Would fstests accept Lustre support before Lustre > gets accepted upstream? Or should it be maintained as a separate > branch? > Up to the maintainer (CC) but in any case, you will need to maintain a development branch until the fstests patches are reviewed, so I do not see much difference for the process. My own vote would be to merge lustre support to fstest *before* merging lustre to linux-next tree (to fs-next branch), so that lustre could potentially be tested by 3rd party when it hits linux-next. IMO, if lustre is on track for upstreaming with all the open questions addressed, I see no reason not to merge fstests support earlier. I was going to recommend that you consider adding lustre support to one or more of the available "fstest runners" to provide a turnkey solution for the standalone test setup, but I see that you already contributed to ktest, So that's great! and one more reason to merge fstests support sooner. Thanks, Amir.
