On Thu, Mar 10, 2022 at 02:58:07PM +0000, Matias Bjørling wrote: > >> Yes, these drives are intended for Linux users that would use the > > >> zoned block device. Append is supported but holes in the LBA space > > >> (due to diff in zone cap and zone size) is still a problem for these users. > > > > > > With respect to the specific users, what does it break specifically? What are > > key features are they missing when there's holes? > > > > What we hear is that it breaks existing mapping in applications, where the > > address space is seen as contiguous; with holes it needs to account for the > > unmapped space. This affects performance and and CPU due to unnecessary > > splits. This is for both reads and writes. > > > > For more details, I guess they will have to jump in and share the parts that > > they consider is proper to share in the mailing list. > > > > I guess we will have more conversations around this as we push the block > > layer changes after this series. > > Ok, so I hear that one issue is I/O splits - If I assume that reads > are sequential, zone cap/size between 100MiB and 1GiB, then my gut > feeling would tell me its less CPU intensive to split every 100MiB to > 1GiB of reads, than it would be to not have power of 2 zones due to > the extra per io calculations. Don't you need to split anyway when spanning two zones to avoid the zone boundary error? Maybe this is a silly idea, but it would be a trivial device-mapper to remap the gaps out of the lba range.
