Hi Johannes, On 2022-03-15 15:14, Johannes Thumshirn wrote: > Please also make sure to support btrfs and not only throw some patches > over the fence. Zoned device support in btrfs is complex enough and has > quite some special casing vs regular btrfs, which we're working on getting > rid of. So having non-power-of-2 zone size, would also mean having NPO2 I already made a simple btrfs npo2 poc and it involved mostly changing the po2 calculation to be based on generic calculation. I understand that changing the calculations from using log & shifts to division will incur some performance penalty but I think we can wrap them with helpers to minimize those impact. > So having non-power-of-2 zone size, would also mean having NPO2 > block-groups (and thus block-groups not aligned to the stripe size). > I agree with your point that we risk not aligning to stripe size when we move to npo2 zone size which I believe the minimum is 64K (please correct me if I am wrong). As David Sterba mentioned in his email, we could agree on some reasonable alignment, which I believe would be the minimum stripe size of 64k to avoid added complexity to the existing btrfs zoned support. And it is a much milder constraint that most devices can naturally adhere compared to the po2 zone size requirement. > Just thinking of this and knowing I need to support it gives me a > headache. > This is definitely not some one off patch that we want upstream and disappear. As Javier already pointed out, we would be more than happy help you out here. > Also please consult the rest of the btrfs developers for thoughts on this. > After all btrfs has full zoned support (including ZNS, not saying it's > perfect) and is also the default FS for at least two Linux distributions. > > Thanks a lot, > Johannes -- Regards, Pankaj
