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? Tim Day
