On 5/20/22 08:41, Damien Le Moal wrote: >>>>> >>>>> So what about creating a device-mapper target, that's taking npo2 drives >>>>> and >>>>> makes them po2 drives for the FS layers? It will be very similar code to >>>>> dm-linear. >>>> Keith and Adam had a similar suggestion to go create a device mapper (dm-unholy) when we tried the po2 emulation[1]. >>>> +1 >>>> >>>> This will simplify the support for FSes, at least for the initial drop (if >>>> accepted). >>>> >>>> And more importantly, this will also allow addressing any potential >>>> problem with user space breaking because of the non power of 2 zone size. >>>> >>> Seconded (or maybe thirded). >>> >>> The changes to support npo2 in the block layer are pretty simple, and >>> really I don't have an issue with those. >>> Then adding a device-mapper target transforming npo2 drives in po2 >>> block devices should be pretty trivial. >>> >>> And once that is in you can start arguing with the the FS folks on >>> whether to implement it natively. >>> >> >> So you are suggesting adding support for !PO2 in the block layer and >> then a dm to present the device as a PO2 to the FS? This at least >> addresses the hole issue for raw zoned block devices, so it can be a >> first step. > > Yes, and it also allows supporting these new !po2 devices without > regressions (read lack of) in the support at FS level. > >> >> This said, it seems to me that the changes to the FS are not being a >> real issue. In fact, we are exposing some bugs while we generalize the >> zone size support. > > Not arguing with that. But since we are still stabilizing btrfs ZNS > support, adding more code right now is a little painful. > >> >> Could you point out what the challenges in btrfs are in the current >> patches, that it makes sense to add an extra dm layer? > > See above. No real challenge, just needs to be done if a clear agreement > can be reached on zone size alignment constraints. As mentioned above, the > btrfs changes timing is not ideal right now though. > > Also please do not forget applications that may expect a power of 2 zone > size. A dm-zsp2 would be a nice solution for these. So regardless of the > FS work, that new DM target will be *very* nice to have. > >> >> Note that for F2FS there is no blocker. Jaegeuk picked the initial >> patches, and he agreed to add native support. > > And until that is done, f2fs will not work with these new !po2 devices... > Having the new dm will avoid that support fragmentation which I personally > really dislike. With the new dm, we can keep support for *all* zoned block > devices, albeit needing a different setup depending on the device. That is > not nice at all but at least there is a way to make things work continuously. >
I see that many people in the community feel it is better to target the dm layer for the initial support of npo2 devices. I can give it a shot and maintain a native out-of-tree support for FSs for npo2 devices and merge it upstream as we see fit later. [1] https://lore.kernel.org/all/20220311223032.ga2...@dhcp-10-100-145-180.wdc.com/ -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
