qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO


From: Kevin Wolf
Subject: Re: [Qemu-block] [RFC PATCH] protocol: Add NBD_CMD_FLAG_FAST_ZERO
Date: Fri, 12 Apr 2019 13:04:33 +0200
User-agent: Mutt/1.11.3 (2019-02-01)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]