[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 13/20] block/iscsi: use UNMAP to write zeroes

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 13/20] block/iscsi: use UNMAP to write zeroes if LBPRZ=1
Date: Thu, 21 Nov 2013 12:49:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 21/11/2013 12:43, Peter Lieven ha scritto:
>>   @@ -1579,7 +1582,7 @@ static int iscsi_get_info(BlockDriverState
>> *bs, BlockDriverInfo *bdi)
>>   {
>>       IscsiLun *iscsilun = bs->opaque;
>>       bdi->unallocated_blocks_are_zero = !!iscsilun->lbprz;
>> -    bdi->can_write_zeroes_with_unmap = iscsilun->lbprz &&
>> iscsilun->lbp.lbpws;
>> +    bdi->can_write_zeroes_with_unmap = !!iscsilun->lbprz;
>>       return 0;
>>   }
> I would definetly not do that! I have seen at least my target to execute
> only parts of a discard request.

Does that target have LBPRZ and LBPU but not LBPWS?  Note that I'm still
preferring WRITE SAME to UNMAP if both are available.

If so, then this patch is indeed problematic.  Otherwise, it's just
making the same assumptions that Linux has been making forever.

> Additionally in our semantic a discard request may silently fail.

That doesn't matter, the silent failure is handled in block.c.  Here I'm
calling iscsi_co_discard, not bdrv_co_discard.  If it returns ENOTSUP,
it is passed up to bdrv_co_do_write_zeroes which will fall back to writes.

> In general this could lead to data corruption
> due to broken implementations.

A broken implementation could also have LBPWS=1 and execute only the
aligned parts of a WRITE SAME with UNMAP request.


reply via email to

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