Hi David, On 2022-03-15 15:27, David Sterba wrote: > > PO2 is really easy to work with and I guess allocation on the physical > device could also benefit from that, I'm still puzzled why the NPO2 is > even proposed. > Quick recap: Hardware NAND cannot naturally align to po2 zone sizes which led to having a zone cap and zone size, where, zone cap is the actually storage available in a zone. The main proposal is to remove the po2 constraint to get rid of this LBA holes (generally speaking). That is why this whole effort was started. > We can possibly hide the calculations behind some API so I hope in the > end it should be bearable. The size of block groups is flexible we only > want some reasonable alignment. > I agree. I already replied to Johannes on what it might look like. Reiterating here again, the reasonable alignment I was thinking while I was doing a POC for btrfs with npo2 zone size is the minimum stripe size that is required by btrfs (64K) to reduce the impact of this change on the zoned support in btrfs. > I haven't read the whole thread yet, my impression is that some hardware > is deliberately breaking existing assumptions about zoned devices and in > turn breaking btrfs support. I hope I'm wrong on that or at least that > it's possible to work around it. Based on the POC we did internally, it is definitely possible to support it in btrfs. And making this change will not break the existing btrfs support for zoned devices. Naive approach to making this change will have some performance impact as we will be changing the po2 calculations from log & shifts to division, multiplications. I definitely think we can optimize it to minimize the impact on the existing deployments. -- Regards, Pankaj
