Am 12.04.2019 um 09:44 hat Richard W.M. Jones geschrieben:
So I had a think about this.
Isn't this easier/better solved by lifting the 32 bit restriction on
the size of certain non-data requests (ie. NBD_CMD_BLOCK_STATUS,
NBD_CMD_TRIM, NBD_CMD_WRITE_ZEROES). The client can then query the
disk efficiently to see if it starts as zeroes, and can decide on the
basis of that whether it needs to "infill" zeroes as it goes along, or
can ignore zeroes because they are already zero.
While at the same time lifting this restriction also solves other
problems we have, notably the 32 bit limitation on trims which affects
large mkfs greatly.
Previously discussed here:
https://lists.debian.org/nbd/2018/09/msg00001.html
& continuing the next month here:
https://lists.debian.org/nbd/2018/10/msg00000.html
Actually, I think having both is useful.
Detecting that an image is already completely zeroed is useful because
then you don't need to do any preparation (but can we actually query
that e.g. for Nir's block device in question?).
But if you can't decide whether it's zeroed or you know it contains
non-zero data, you still need a way to choose the most efficient way to
write the image to it.
So having one of the features doesn't make the other one irrelevant.
Kevin