On 2/3/25, 1:44 AM, "Christoph Hellwig" <hch@xxxxxxxxxxxxx <mailto:hch@xxxxxxxxxxxxx>> wrote: > On Sun, Feb 02, 2025 at 10:26:28AM -0500, Theodore Ts'o wrote: > > Well, in the past I attempted to land a "local" file system type that > > could be used for file systems that were available via docker (and so > > there was no block device to mount and unmount). This was useful for > > testing gVisor[1] and could also be used for testing Windows Subsystem > > for Linux v1. As I recall, either Dave or Cristoph objected, even > > though the diffstat was +73, -4 lines in common/rc. > > Yes, xfstests should just support upstream code. Even for things where > we through it would get upstream ASAP like the XFS > rtrmap/reflink/metadir work (which finally did get upstream now) having > the half-finished support in xfstests without actually landing the rest > caused more than enough problems. That’s fair. From the perspective of someone making changes to xfstests, it'd probably be hard to change any of the Lustre stuff without an easy way to validate that the tests are still working correctly. But I gave it another look yesterday - the changes need to support Lustre are pretty minimal. fstests assumes that any miscellaneous filesystem is disk based. So either relaxing that assumption or adding an explicit Lustre $FSTYPE is enough. Of course, in the fullness of time - Lustre ought to have its own tests exercising striping and such. We have our own test scripts to cover this - but porting a subset to fstests would be helpful. But the initial support doesn't need all that. But I suppose I could keep this all downstream until Lustre gets closer to acceptance. > Something like lustre that has > historically been a complete trainwreck and where I have strong doubts > that the maintainers get their act together is even worse. Did you have any specific doubts, beyond the development model and disk/wire protocol stability? In other words, is the development model the primary concern? Or are there technical concerns with Lustre itself? Tim Day
