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
ronniesahlb...@gmail.com wrote:
Please find attached a patch to add built-in support for iSCSI into QEMU.
Please review
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
Thanks,
On Fri, Apr 22, 2011 at 2:08 PM, Christoph Hellwig h...@lst.de 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
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
Ok, I am confused
On Fri, Apr 22, 2011 at 4:13 PM, Christoph Hellwig h...@lst.de 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
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
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
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 braindead
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
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
On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig h...@lst.de 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
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
On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig h...@lst.de 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
On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig h...@lst.de wrote:
We only claim WCE=1 to the guest if cache=writeback or cache=none
On Thu, Apr 21, 2011 at 12:12 PM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
On Thu, Apr 21, 2011 at 8:58 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Apr 21, 2011 at 10:28 AM, ronnie sahlberg
ronniesahlb...@gmail.com wrote:
On Thu, Apr 21, 2011 at 7:09 PM, Christoph Hellwig
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,
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 be made
On Thu, Apr 21, 2011 at 12:36 PM, ronnie sahlberg
ronniesahlb...@gmail.com 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,
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
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 ronniesahlb...@gmail.com
Subject: iSCSI support for QEMU, update
In-Reply-To:
On Thu, Apr 21, 2011 at 10:49 PM, Christoph Hellwig h...@lst.de 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
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_NOCACHE
22 matches
Mail list logo
