On Sat, Feb 01, 2025 at 11:55:21AM +0100, Amir Goldstein wrote: > 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, I think fstests has nothing to lose to support one more testing :) Let's see the patchset (to fstests@) at first. If it's simple enough, likes 4cbc0a0fa8b ("fstests: add GlusterFS support"), then it's easy to be merged. If it needs to change many common things or generic cases, we'd better to give it more reviewing and testing, and maybe merge it into a separated branch at first. Anyway, let's check the patches at first :) Meanwhile, I'd like to track the patches you send to linux VFS, to think about when it's time to have the testing part at first, so feel free to CC. Thanks, Zorro > > Thanks, > Amir. >
