On Aug 3, 2010, at 5:56 PM, Robert Milkowski <mi...@task.gda.pl> wrote:
> On 03/08/2010 22:49, Ross Walker wrote:
>> On Aug 3, 2010, at 12:13 PM, Roch Bourbonnais<roch.bourbonn...@sun.com>
>> wrote:
>>
>>
>>> Le 27 mai 2010 à 07:03, Brent Jones a écrit :
>>>
>>>
>>>> On Wed, May 26, 2010 at 5:08 AM, Matt Connolly
>>>> <matt.connolly...@gmail.com> wrote:
>>>>
>>>>> I've set up an iScsi volume on OpenSolaris (snv_134) with these commands:
>>>>>
>>>>> sh-4.0# zfs create rpool/iscsi
>>>>> sh-4.0# zfs set shareiscsi=on rpool/iscsi
>>>>> sh-4.0# zfs create -s -V 10g rpool/iscsi/test
>>>>>
>>>>> The underlying zpool is a mirror of two SATA drives. I'm connecting from
>>>>> a Mac client with global SAN initiator software, connected via Gigabit
>>>>> LAN. It connects fine, and I've initialiased a mac format volume on that
>>>>> iScsi volume.
>>>>>
>>>>> Performance, however, is terribly slow, about 10 times slower than an SMB
>>>>> share on the same pool. I expected it would be very similar, if not
>>>>> faster than SMB.
>>>>>
>>>>> Here's my test results copying 3GB data:
>>>>>
>>>>> iScsi: 44m01s 1.185MB/s
>>>>> SMB share: 4m27 11.73MB/s
>>>>>
>>>>> Reading (the same 3GB) is also worse than SMB, but only by a factor of
>>>>> about 3:
>>>>>
>>>>> iScsi: 4m36 11.34MB/s
>>>>> SMB share: 1m45 29.81MB/s
>>>>>
>>>>>
>>> <cleaning up some old mail>
>>>
>>> Not unexpected. Filesystems have readahead code to prefetch enough to cover
>>> the latency of the read request. iSCSI only responds to the request.
>>> Put a filesystem on top of iscsi and try again.
>>>
>>> For writes, iSCSI is synchronous and SMB is not.
>>>
>> It may be with ZFS, but iSCSI is neither synchronous nor asynchronous is is
>> simply SCSI over IP.
>>
>> It is the application using the iSCSI protocol that determines whether it is
>> synchronous, issue a flush after write, or asynchronous, wait until target
>> flushes.
>>
>> I think the ZFS developers didn't quite understand that and wanted strict
>> guidelines like NFS has, but iSCSI doesn't have those, it is a lower level
>> protocol than NFS is, so they forced guidelines on it and violated the
>> standard.
>>
>>
> Nothing has been violated here.
> Look for WCE flag in COMSTAR where you can control how a given zvol should
> behave (synchronous or asynchronous). Additionally in recent build you have
> zfs set sync={disabled|default|always} which also works with zvols.
>
> So you do have a control over how it is supposed to behave and to make it
> nice it is even on per zvol basis.
> It is just that the default is synchronous.
I forgot to ask, if the ZVOL is set async with WCE will it still honor a flush
command from the initiator and flush those TXGs held for the ZVOL?
-Ross
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
