[Top][All Lists]

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

Re: [PATCH] nbd: server: Report holes for raw images

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH] nbd: server: Report holes for raw images
Date: Thu, 25 Feb 2021 21:50:54 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

19.02.2021 19:58, Eric Blake wrote:
On 2/19/21 10:42 AM, Eric Blake wrote:

To me, data=false looks compatible with NBD_STATE_HOLE. From user point
of view, getting same results from qemu-nbd and qemu-img is more
important than being more correct about allocation status.

More to the point, here is our inconsistency:

In nbd/server.c, we turn !BDRV_BLOCK_ALLOCATED into NBD_STATE_HOLE

In block/nbd.c, we turn !NBD_STATE_HOLE into BDRV_BLOCK_DATA

The fact that we are not doing a round-trip conversion means that one of
the two places is wrong.  And your argument that the server side is
wrong makes sense to me.

In fact, when I went back and researched when this was introduced (see
commit e7b1948d51 in 2018), we may have been aware of the inconsistency
between client and server, but didn't make up our minds at the time:
"? Hm, don't remember, what we decided about DATA/HOLE flags mapping.."

I'll wait a few days for any other reviewer commentary before taking
this through my NBD tree.

I can add the following.

First, link to my research of block_status in Qemu: 

And about HOLE and ZERO..

As I've noted in the research above, SCSI may return HOLE & !ZERO:

from SCSI:
Logical Block Provisioning Read Zeros (LBPRZ) bit
1     If the logical block provisioning read zeros (LBPRZ) bit is set to one, 
then, for an unmapped LBA specified by a read operation, the deviceserver shall 
send user data with all bits set to zero to the data-in buffer.
0     If the TPRZ bit is set to zero, then, for an unmapped LBA specified by a 
read operation, the device server may send user data with all bitsset to any 
value to the data-in buffer.

So we can have an unmapped area that can be read as any random data. Same thing 
can be said about null-co driver with read-zeroes=false

Also, qcow2 support ALLOCATED ZERO clusters which reads as zero but data is 
allocated - they are reasonable to report as ZERO & !HOLE

And of-course UNALLOCATED ZERO clusters in qcow2 and lseek-holes are reasonable to report as 
ZERO & HOLE,  because they reads as zero and "future writes to that area may cause 
fragmentation or encounter an NBD_ENOSPC"..

So, all combination are reasonable, we just need to fix Qemu NBD server to 
report correct statuses in all these cases.

It seems that ZERO/HOLE specification is a lot more reasonable than what we 
have with ZERO/DATA/ALLOCATED in Qemu, and may be true way is move internal 
block_status to use NBD terms.

And thanks for CCing me. Hmm, maybe, I'll suggest myself as co-maintainer for 

Best regards,

reply via email to

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