Sorry about the missing subject line in the previous mail
Got confused when using git-send-patch :-)
regards
ronnie sahlberg
On Sun, Jun 12, 2011 at 12:47 PM, Ronnie Sahlberg
wrote:
> Please find attached a patch to add built-in support for iSCSI into QEMU.
> Please review and/or apply this patc
This is a patch that adds support for iSCSI to QEMU when QEMU is built against
libiscsi (https://github.com/sahlberg/libiscsi)
ISCSI devices are specified using a special iSCSI URL:
-drive file=iscsi://10.1.1.1:3260/iqn.ronnie.test/1
This allows a guest to access iscsi devices without exposin
On Fri, Apr 22, 2011 at 04:35:11PM +1000, ronnie sahlberg wrote:
> Ok, I am confused
And this time it's my fault, sorry.
> I have to set FUA if the WB(I guessed this meant write-back) flag is set?
> Not the opposite (I assume opposite of write-back is write-through) ?
Sorry, I meant exactly the
Ok, I am confused
On Fri, Apr 22, 2011 at 4:13 PM, Christoph Hellwig wrote:
> On Fri, Apr 22, 2011 at 04:08:57PM +1000, ronnie sahlberg wrote:
>> So I should set FUA when
>> BDRV_O_CACHE_WB==0 or BDRV_O_NOCACHE==1
>> right?
>
> At this point you need to set it if either the BDRV_O_CACHE_WB and
On Fri, Apr 22, 2011 at 04:08:57PM +1000, ronnie sahlberg wrote:
> So I should set FUA when
> BDRV_O_CACHE_WB==0 or BDRV_O_NOCACHE==1
> right?
At this point you need to set it if either the BDRV_O_CACHE_WB and
BDRV_O_NOCACHE flags are set. And yes, the naming of the nocache
flag is rather confu
Thanks,
On Fri, Apr 22, 2011 at 2:08 PM, Christoph Hellwig wrote:
> On Fri, Apr 22, 2011 at 06:23:58AM +1000, ronniesahlb...@gmail.com wrote:
>> iSCSI block driver for QEMU
>>
>> Please find an updated iSCSI patch.
>> This patch adds setting FUA on all writes when the bit
>> BDRV_O_CACHE_WB is no
On Fri, Apr 22, 2011 at 06:23:58AM +1000, ronniesahlb...@gmail.com wrote:
> iSCSI block driver for QEMU
>
> Please find an updated iSCSI patch.
> This patch adds setting FUA on all writes when the bit
> BDRV_O_CACHE_WB is not set.
At this point you need to check for BDRV_O_CACHE_WB and BDRV_O_NOC
On Thu, Apr 21, 2011 at 10:49 PM, Christoph Hellwig wrote:
> On Thu, Apr 21, 2011 at 09:36:12PM +1000, ronnie sahlberg wrote:
>> There are some high-volume arrays that advertise support but fail any
>> cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional.
>
> Which on would th
iSCSI block driver for QEMU
Please find an updated iSCSI patch.
This patch adds setting FUA on all writes when the bit
BDRV_O_CACHE_WB is not set.
regards
ronnie sahlberg
From: Ronnie Sahlberg
Subject: iSCSI support for QEMU, update
In-Reply-To:
On Thu, Apr 21, 2011 at 09:36:12PM +1000, ronnie sahlberg wrote:
> There are some high-volume arrays that advertise support but fail any
> cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional.
Which on would that be? Linux uses the FUA bit if the device advertises support
via
On Thu, Apr 21, 2011 at 12:36 PM, ronnie sahlberg
wrote:
> I understand.
>
> Let me re-send a patch tomorrow that can optionally enable/force FUA
> bits for write.
> There are some high-volume arrays that advertise support but fail any
> cdb with FUA, FUA_NV bits set with sense, so it needs to be
Am 21.04.2011 13:36, schrieb ronnie sahlberg:
> Stephan,
>
> I understand.
>
> Let me re-send a patch tomorrow that can optionally enable/force FUA
> bits for write.
> There are some high-volume arrays that advertise support but fail any
> cdb with FUA, FUA_NV bits set with sense, so it needs to
Stephan,
I understand.
Let me re-send a patch tomorrow that can optionally enable/force FUA
bits for write.
There are some high-volume arrays that advertise support but fail any
cdb with FUA, FUA_NV bits set with sense, so it needs to be made optional.
regards
ronnie sahlberg
On Thu, Apr 21, 2
On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg
wrote:
> On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi wrote:
>> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
>> wrote:
>>> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote:
We only claim WCE=1 to the guest if cache=writebac
On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi wrote:
> On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
> wrote:
>> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote:
>>> We only claim WCE=1 to the guest if cache=writeback or cache=none are
>>> set. So ignoring the issue of having a
On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
wrote:
> On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote:
>> We only claim WCE=1 to the guest if cache=writeback or cache=none are
>> set. So ignoring the issue of having a cache on the initiator side
>> you must implement stable writes
Christoph,
I think you misread my test.
My test is pure reading :
sudo time dd if=/dev/sda of=/dev/null bs=1M
There are no writes involved at all in this test, only a huge number
of READ10 being sent to the target,
or in the case of when using QEMU+openiscsi-mounted-lun sometimes
being served ou
On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig wrote:
>> In my patch, there are NO data integrity issues.
>> Data is sent out on the wire immediately as the guest issues the write.
>> Once the guest issues a flush call, the flush call will not terminate
>> until the SYNCCACHE10 task has comple
> In my patch, there are NO data integrity issues.
> Data is sent out on the wire immediately as the guest issues the write.
> Once the guest issues a flush call, the flush call will not terminate
> until the SYNCCACHE10 task has completed.
No guest will even issue a cache flush, as we claim to be
Please re-read my post or read the patch.
It has O_DIRECT like behaviour in that it will not pollute the hosts cache.
This for the simple reason that the host is not aware that there is
any block i/o happening.
In my patch, there are NO data integrity issues.
Data is sent out on the wire immediat
On Thu, Apr 21, 2011 at 06:43:10PM +1000, Ronnie Sahlberg wrote:
> Some basic tests thatve been performed show it to be significantly faster
> than an out-of-the-box open-iscsi mounted LUN being accessed by default
> QEMU i/o options.
Which isn't a useful comparism. qemu's default is the braindea
Please find attached a new version of the patch for iSCSI support.
iSCSI support is automaticallt detected and activated during configure/build
if the libiscsi library is available on the build host.
This library is available at : https://github.com/sahlberg/libiscsi
This new version contains tw
22 matches
Mail list logo