> -----Original Message----- > From: zfs-discuss-boun...@opensolaris.org > [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of > Robert Milkowski > Sent: Tuesday, August 03, 2010 5:57 PM > To: zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] iScsi slow > > 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.
And if it's synchronous, you can still accelerate performance by using L2ARC and SLOG devices, just like you can with NFS, correct? -Will _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
