> > Furthermore, adding such DM target would create a non power of 2 zone size > zoned device which will need support from the block layer. So some block layer > functions will need to change. In the end, this may not be different than > enabling non power of 2 zone sized devices for ZNS. > > And for this decision, I maintain some of my requirements: > 1) The added overhead from multiplication & divisions should be acceptable > and not degrade performance. Otherwise, this would be a disservice to the > zone ecosystem. > 2) Nothing that works today on available devices should break > 3) Zone size requirements will still exist. E.g. btrfs 64K alignment requirement > Adding to the existing points that has been made. I believe it hasn't been mentioned that for non-power of 2 zone sizes, holes are still allowed due to zones being/becoming offline. The offline zone state supports neither writes nor reads, and applications must be aware and work around such holes in the address space. Furthermore, the specification doesn't allow writes to cross zones - so while reads may cross a zone, the writes must always be broken up across zone boundaries. As a result, applications must work with zones independently and can't assume that it can write to the adjacent zone nor write across two zones. Best, Matias
