Ross Walker writes: > 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. >
Hey Ross, Nothing to do with ZFS here, but you're right to point out that iSCSI is neither. It was just that in the context of this test (and 99+% of iSCSI usage) it will be. SMB is not. Thus a large discrepancy on the write test. Resilient storage, by default, should expose iSCSI channels with write caches disabled. > 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. > True. > 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. > > -Ross > Not True. ZFS exposes LUNS (or ZVOL) and while at first we didn't support DKIOCSETWCE, we now do. So a ZFS LUN can be whatever you need it to be. Now in the context of iSCSI luns hosted by a resilient storage system, enabling write caches is to be used only in very specific circumstances. The situation is not symmetrical with WCE in disks of a JBOD since that can be setup with enough redundancy to deal with potential data loss. When using a resilient storage, you need to trust the storage for persistence of SCSI commands and building a resilient system on top of write cache enabled SCSI channels is not trivial. Then Matts points out As I indicated above, there is a mac filesystem on the iscsi volume. Matt. On the read side, single threaded performance is just very much controled by the readahead. Each filesystem will implement something different, the fact that you got 3X more throughput with SMB that with the Mac (HSFS+?) simply means that SMB had a 3X larger readahead buffer than HSFS. -r _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
