qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] ISCSI: Add support for thin-provisioning via di


From: ronnie sahlberg
Subject: Re: [Qemu-devel] [PATCH] ISCSI: Add support for thin-provisioning via discard/UNMAP and bigger LUNs
Date: Tue, 24 Apr 2012 18:02:16 +1000

On Tue, Apr 24, 2012 at 4:46 PM, Paolo Bonzini <address@hidden> wrote:
> Il 24/04/2012 08:29, Ronnie Sahlberg ha scritto:
>> Update the configure test for libiscsi support to detect version 1.3 or 
>> later.
>> Version 1.3 of libiscsi provides both READCAPACITY16 as well as UNMAP 
>> commands.
>>
>> Update the iscsi block layer to use READCAPACITY16 to detect the size of the 
>> LUN instead of READCAPACITY10. This allows support for LUNs larger than 2TB.
>>
>> Update to implement bdrv_aio_discard() using the UNMAP command.
>> This allows us to use thin-provisioned LUNs from TGTD and other iSCSI 
>> targets that support thin-provisioning.
>
> Looks good.  Kevin, do you want me to take libiscsi patches via the SCSI
> tree?
>
> As an aside, I am not really sure of the utility of adding these utility
> functions directly in libiscsi, rather than making it a pure transport
> library.  block/iscsi.c is going to grow as you add more functionality
> (e.g. WRITE SAME commands), and libiscsi will have to be updated each
> time in lockstep.
>
> I can see the value of basic read/write/flush and readcap10/16, but with
> unmap it's starting to be a bit more specific.  Are there other clients
> of libiscsi that use these functions?  Should they be placed into
> block/iscsi.c or a new block/iscsi-cdb.c instead?

I see your point.
I like to add scsi commands as I use them to libiscsi, since then I
dont have to
re-write the marshalling/unmarshalling code everytime in my small test
and utility programs.
For example when i want to write some one-off small tools to test something.


But, yes. There is no real need to use them directly from qemu.


So ignore this patch for now. I will redo UNMAP in the patch to
instead use the generic scsi function inside libiscsi.

That will serve the purpose to verify that the public API in libiscsi
is sufficient for accessing the generic transport and
secondly that will show a useful example on how to send CDB+data to
and to receive data back from the generic function.

This generic API would be what a future virt-scsi->libiscsi
integration would use anyway.



regards
ronnie sahlberg



reply via email to

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