qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 06/11] scsi-disk: correctly implement WRITE SAME


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 06/11] scsi-disk: correctly implement WRITE SAME
Date: Wed, 13 Nov 2013 10:38:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 13/11/2013 07:18, Peter Lieven ha scritto:
>> > The WRITE SAME command is implemented incorrectly.  WRITE SAME with the
>> > UNMAP bit set should _not_ unmap the sectors unless the written data
>> > matches the payload of the WRITE SAME command; currently, QEMU is not
>> > looking at the payload at all.
>> > 
>> > Thus, fetch the data to be written from the input buffer.  If it is
>> > all zeroes, we can use the write_zeroes call (possibly with the new
>> > MAY_UNMAP flag).  Otherwise, do as many write cycles as needed, covering
>> > 512k at a time to avoid allocating lots of memory for the bounce
>> > buffer.
> 
> Would it make sense to add a bdrv_write_same or is the use case for
> WRITE SAME with non-zero payload too rare?

It would, but it is definitely very rare, probably so much that we need
not care.  Linux only invokes it for zero payloads.

Also, for zero payload there are additional benefits.  First, supporting
WRITE SAME with UNMAP if the host has LBPRZ=1 or analogous.  Second,
using zero clusters in qcow2/qed/vmdk.

> And secondly would it make sense to add an optimal request size field
> to the BlockLimits?

The optimal request size is not particularly useful if it is not visible
to the guest, unfortunately.  But we cannot pass values arbitrarily to
the guest because they would change if the backing storage changed (e.g.
from NFS to local, or from raw to qcow2).

So I'm not sure who would actually use the optimal request size.

Paolo



reply via email to

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