[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:
https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg03465.html
"? 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:
https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg05136.html
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
NBD?
--
Best regards,
Vladimir