On 1/6/25 6:08 PM, Damien Le Moal wrote: > On 1/7/25 02:38, Jens Axboe wrote: >>> I think this is a valid and reasonable discussion. But maybe we're >>> just not on the same page. I don't know anything existing and usable, >>> maybe I've just not found it? >> >> Not that I'm aware of, it was just a suggestion/thought that we could >> utilize an existing driver for this, rather than have a separate one. >> Yes the proposed one is pretty simple and not large, and maintaining it >> isn't a big deal, but it's still a new driver and hence why I was asking >> "why can't we just use ublk for this". That also keeps the code mostly >> in userspace which is nice, rather than needing kernel changes for new >> features, changes, etc. > > I did consider ublk at some point but did not switch to it because a > ublk backend driver to do the same as zloop in userspace would need a > lot more code to be efficient. And even then, as Christoph already > mentioned, we would still have performance suffer from the context > switches. But that performance point was not the primary stopper I don't buy this context switch argument at all. Why would it mean more sleeping? There's absolutely zero reason why a ublk solution would be at least as performant as the kernel one. And why would it need "a lot more code to be efficient"? > though as this driver is not intended for production use but rather to > be the simplest possible setup that can be used in CI systems to test > zoned file systems (among other zone related things). Right, that too. > A kernel-based implementation is simpler and the configuration > interface literally needs only a single echo bash command to add or > remove devices. This allows minimal VM configurations with no > dependencies on user tools/libraries to run these zoned devices, which > is what we wanted. > > I completely agree about the user-space vs kernel tradeoff you > mentioned. I did consider it but the code simplicity and ease of use > in practice won for us and I chose to stick with the kernel driver > approach. > > Note that if you are OK with this, I need to send a V2 to correct the > Kconfig description which currently shows an invalid configuration > command example. Sure, I'm not totally against it, even if I think the arguments are very weak, and in some places also just wrong. It's not like it's a huge driver. -- Jens Axboe
