zfs discuss - Aug 2009 - Poor iSCSI performance

Hi,  I have just setup an ISCSI volume on ZFS to use with OS X as a backup disk
but performance is extremely bad.  I am using the GlobalSAN iSCSI initiator.

Without getting into too much detail does anyone know whether there is a reason
why an iSCSI device seems to perform so badly ?  I have configured the iSCSI
device as a Time Machine drive the backup is very very slow.

I have also seen a number of postings about the ZIL being the problem and
needing to put in a fast SSD drive to address this.

If anyone has a good explanation of what this problem is and how to fix it
please let me know.  I am using a small PC with 4 x1TB SATA drives as a file
server running OpenSolaris 2009.06.

Thanks
-- 
This message posted from opensolaris.org

Hi Duncan,

I also do the same with my Mac for timemachine and get the same WOEFUL
performance to my x4500 filer.

I have mounted ISCSI zvols on a linux machine and it performs as expected
(50 mbytes a second) as apposed to my Mac that goes @ 1mbyte a second. I do
believe the client for Mac is crap. Would be nice if apple wrote a client
for ISCSI.

But if anyone has a fix for Mac OS X that would be great to know !

Ta,
-- 
Cooper Ry Lees
HPC / UNIX Systems Administrator - Information Management Services (IMS)
Australian Nuclear Science and Technology Organisation
T  +61 2 9717 3853
F  +61 2 9717 9273
M  +61 403 739 446
E  cooper.lees at ansto.gov.au
www.ansto.gov.au <http://www.ansto.gov.au>

Important: This transmission is intended only for the use of the addressee.
It is confidential and may contain privileged information or copyright
material. If you are not the intended recipient, any use or further
disclosure of this communication is strictly forbidden. If you have received
this transmission in error, please notify me immediately by telephone and
delete all copies of this transmission as well as any attachments.




On 25/08/09 11:57 AM, "Duncan Groenewald" <dagroenewald at
optusnet.com.au>
wrote:
> Hi,  I have just setup an ISCSI volume on ZFS to use with OS X as a backup
> disk but performance is extremely bad.  I am using the GlobalSAN iSCSI
> initiator.  
> 
> Without getting into too much detail does anyone know whether there is a
> reason why an iSCSI device seems to perform so badly ?  I have configured
the
> iSCSI device as a Time Machine drive the backup is very very slow.
> 
> I have also seen a number of postings about the ZIL being the problem and
> needing to put in a fast SSD drive to address this.
> 
> If anyone has a good explanation of what this problem is and how to fix it
> please let me know.  I am using a small PC with 4 x1TB SATA drives as a
file
> server running OpenSolaris 2009.06.
> 
> Thanks

On Aug 24, 2009, at 10:02 PM, "LEES, Cooper" <crl at
ansto.gov.au> wrote:
> Hi Duncan,
>
> I also do the same with my Mac for timemachine and get the same WOEFUL
> performance to my x4500 filer.
>
> I have mounted ISCSI zvols on a linux machine and it performs as  
> expected
> (50 mbytes a second) as apposed to my Mac that goes @ 1mbyte a  
> second. I do
> believe the client for Mac is crap. Would be nice if apple wrote a  
> client
> for ISCSI.
>
> But if anyone has a fix for Mac OS X that would be great to know !
You know you can do time machine on NFS. An SSD drive will also go a  
long way too, you really on need a 16GB one for an slog.

-Ross

Ross,

Do you have any links to doco / blog posts for time machine over NFS? I
would love to do this ... I have mounted NFS before with "Connect to
Server"
/ Automoutner but don''t know how to get Mac OS X to see it as a valid
''disk''
to backup to.

Ta,
Cooper


On 25/08/09 2:10 PM, "Ross Walker" <rswwalker at gmail.com>
wrote:
> 
> On Aug 24, 2009, at 10:02 PM, "LEES, Cooper" <crl at
ansto.gov.au> wrote:
> 
>> Hi Duncan,
>> 
>> I also do the same with my Mac for timemachine and get the same WOEFUL
>> performance to my x4500 filer.
>> 
>> I have mounted ISCSI zvols on a linux machine and it performs as
>> expected
>> (50 mbytes a second) as apposed to my Mac that goes @ 1mbyte a
>> second. I do
>> believe the client for Mac is crap. Would be nice if apple wrote a
>> client
>> for ISCSI.
>> 
>> But if anyone has a fix for Mac OS X that would be great to know !
> 
> You know you can do time machine on NFS. An SSD drive will also go a
> long way too, you really on need a 16GB one for an slog.
> 
> -Ross
>

> 
> On Aug 24, 2009, at 10:02 PM, "LEES, Cooper"
> <crl at ansto.gov.au> wrote:
> 
> > Hi Duncan,
> >
> > I also do the same with my Mac for timemachine and
> get the same WOEFUL
> > performance to my x4500 filer.
> >
> > I have mounted ISCSI zvols on a linux machine and
> it performs as  
> > expected
> > (50 mbytes a second) as apposed to my Mac that goes
> @ 1mbyte a  
> > second. I do
> > believe the client for Mac is crap. Would be nice
> if apple wrote a  
> > client
> > for ISCSI.
> >
> > But if anyone has a fix for Mac OS X that would be
> great to know !
> 
> You know you can do time machine on NFS. An SSD drive
> will also go a  
> long way too, you really on need a 16GB one for an
> slog.
> 
> -Ross
> 
How do you set it up under NFS ?  I managed to get one of my Macs to backup to a
ZFS share but this is a smb share not an NFS share.

Can you post details on how to use an NFS share for time machine.  iSCSI seems
to be very easy to setup but is way too slow to be useful.

Thanks
-- 
This message posted from opensolaris.org

On Tue, Aug 25, 2009 at 12:02:51PM +1000, LEES, Cooper
wrote:
> Hi Duncan,
> 
> I also do the same with my Mac for timemachine and get the same WOEFUL
> performance to my x4500 filer.
> 
> I have mounted ISCSI zvols on a linux machine and it performs as expected
> (50 mbytes a second) as apposed to my Mac that goes @ 1mbyte a second. I do
> believe the client for Mac is crap. Would be nice if apple wrote a client
> for ISCSI.
> 
> But if anyone has a fix for Mac OS X that would be great to know !
>
I''m getting >30MB/s to/from my 4x1TB drive array, however I see some
v.slow speeds at the beginning. I believe there were a few things that
helped,
# updating to the latest dev release uname -a reports.
      - SunOS dendrite 5.11 snv_118  i86pc i386 i86pc
# Enableing the write-back cache. I beleive there''s some talk of linux 
  clients doing the wrong thing, but that may be NFS,
      - iscsitadm modify admin --fast-write-ack enable
# using the new COMSTAR stack, rather than the old. I think something,
  somewhere was getting confused, there seem to be two versions of
  instructions around. Having migrated an old set of pools onto this 
  system probably didn''t help matters.
      - svcs -a | grep -i iscsi
      disabled       Aug_16   svc:/network/iscsi_initiator:default
      disabled       Aug_16   svc:/system/iscsitgt:default
      online         Aug_16   svc:/network/iscsi/initiator:default
      online         Aug_16   svc:/network/iscsi/target:default

Hope that helps someone, thanks go to the people in #opensolaris on
freenode who helped me get this sorted.

Cheers,

Colin Morey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090825/2977b065/attachment.bin>

On Tue, Aug 25, 2009 at 12:02:51PM +1000, LEES, Cooper
wrote:
> Hi Duncan,
>=20
> I also do the same with my Mac for timemachine and get the same WOEFUL
> performance to my x4500 filer.
>=20
> I have mounted ISCSI zvols on a linux machine and it performs as expected
> (50 mbytes a second) as apposed to my Mac that goes @ 1mbyte a second. I do
> believe the client for Mac is crap. Would be nice if apple wrote a client
> for ISCSI.
>=20
> But if anyone has a fix for Mac OS X that would be great to know !
>
I''m getting >30MB/s to/from my 4x1TB drive array, however I see some
v.slow speeds at the beginning. I believe there were a few things that
helped,
# updating to the latest dev release uname -a reports.
      - SunOS dendrite 5.11 snv_118  i86pc i386 i86pc
# Enableing the write-back cache. I beleive there''s some talk of
linux=20
  clients doing the wrong thing, but that may be NFS,
      - iscsitadm modify admin --fast-write-ack enable
# using the new COMSTAR stack, rather than the old. I think something,
  somewhere was getting confused, there seem to be two versions of
  instructions around. Having migrated an old set of pools onto this=20
  system probably didn''t help matters.
      - svcs -a | grep -i iscsi
      disabled       Aug_16   svc:/network/iscsi_initiator:default
      disabled       Aug_16   svc:/system/iscsitgt:default
      online         Aug_16   svc:/network/iscsi/initiator:default
      online         Aug_16   svc:/network/iscsi/target:default

Hope that helps someone, thanks go to the people in #opensolaris on
freenode who helped me get this sorted.

Cheers,

Colin Morey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090825/07ec7a67/attachment.bin>

> On Tue, Aug 25, 2009 at 12:02:51PM +1000, LEES,
> Cooper wrote:
> > Hi Duncan,
> >=20
> > I also do the same with my Mac for timemachine and
> get the same WOEFUL
> > performance to my x4500 filer.
> >=20
> > I have mounted ISCSI zvols on a linux machine and
> it performs as expected
> > (50 mbytes a second) as apposed to my Mac that goes
> @ 1mbyte a second. I > do
> > believe the client for Mac is crap. Would be nice
> if apple wrote a client
> > for ISCSI.
> >=20
> > But if anyone has a fix for Mac OS X that would be
> great to know !
> >
> 
> I''m getting >30MB/s to/from my 4x1TB drive array,
> however I see some
> v.slow speeds at the beginning. I believe there were
> a few things that
> helped,
> # updating to the latest dev release uname -a
> reports.
>       - SunOS dendrite 5.11 snv_118  i86pc i386 i86pc
> leing the write-back cache. I beleive there''s some
> talk of linux=20
>   clients doing the wrong thing, but that may be NFS,
>     - iscsitadm modify admin --fast-write-ack enable
> ing the new COMSTAR stack, rather than the old. I
> think something,
> somewhere was getting confused, there seem to be
>  two versions of
> instructions around. Having migrated an old set of
>  pools onto this=20
>  system probably didn''t help matters.
>      - svcs -a | grep -i iscsi
> disabled       Aug_16
>    svc:/network/iscsi_initiator:default
> disabled       Aug_16
>    svc:/system/iscsitgt:default
> online         Aug_16
>    svc:/network/iscsi/initiator:default
> online         Aug_16
>    svc:/network/iscsi/target:default
> pe that helps someone, thanks go to the people in
> #opensolaris on
> freenode who helped me get this sorted.
> 
> Cheers,
> 
> Colin Morey
> 
Colin - thanks.  

Is there an easy way to update to snv_118 ?  I am using 2009.06 (snv_111).

I had svc:/system/iscsitgt:default online and svc:/network/iscsi/target:default
offline, however I can''t get /iscsi/target to start.  It just reports
back as Offline after I run "svcadm enable ..."   - any idea why it
would not startup ?  Do I need to restart the server ?

What is the difference between iscsitgt and the other ?

Thanks
-- 
This message posted from opensolaris.org

Duncan Groenewald wrote:
> Is there an easy way to update to snv_118 ?  I am using 2009.06 (snv_111).
# pkg set-authority -O http://pkg.opensolaris.org/dev opensolaris.org
# pkg image-update
# init 6

-- 
Darren J Moffat

BTW I fixed the /iscsi/target problem by starting the stmf service ...

Still I don''t see the iSCSI targets listed and when I run ZFS set
shareiscsi=on  I get an error complaining that the /iscsitgt service is not
running ??

I presume the ZFS iscsi commands don''t work with the /iscsi/target
service ? (or something??)

Thanks
-- 
This message posted from opensolaris.org

Thanks - what is the chance of something breaking if I do this ??
-- 
This message posted from opensolaris.org

Duncan Groenewald wrote:
> Thanks - what is the chance of something breaking if I do this ??
It should work just fine but do read the release notes here:

http://mail.opensolaris.org/pipermail/opensolaris-announce/2009-July/002240.html

Plus you will be able to go back and boot your snv_111 build if it does.


-- 
Darren J Moffat

Mmm - OK I think I managed to start things by using the "itadm
create-target" command.  Anyone''s guess as to how this knows to
share the ZFS iscsi shares but it seems to do so...

Anyway performance is still really bad !!!  Perhaps it is the GlobalSAN OSX
initiator that is not good !
-- 
This message posted from opensolaris.org

The ZFS set shareiscsi=on mechanism is only used with the iscsitgt and 
not with COMSTAR iscsi/target.   Since you shifted to using 
iscsi/target, it should not be working for you now.  

Could it be that somehow you ended up with both kinds of target 
(iscsitgt and comstar iscsi/target) running at the same time, and that 
iscsitgt "owns" the well known port of 3260.   Could you run
"svcs
iscsitgt" to verify that the iscsitgt service is off?  

Other posters have agreed with you  that performance is much worse for 
the GlobalSAN OSX initiator than for an equivalent Linux initiator.

Peter


On 08/25/09 07:29, Duncan Groenewald wrote:
> Mmm - OK I think I managed to start things by using the "itadm
create-target" command.  Anyone''s guess as to how this knows to
share the ZFS iscsi shares but it seems to do so...
>
> Anyway performance is still really bad !!!  Perhaps it is the GlobalSAN OSX
initiator that is not good !
>

On Tue, Aug 25, 2009 at 09:05:47AM -0400, Peter Cudhea
wrote:
> The ZFS set shareiscsi=on mechanism is only used with the iscsitgt and not 
> with COMSTAR iscsi/target.   Since you shifted to using iscsi/target, it 
> should not be working for you now.  
> Could it be that somehow you ended up with both kinds of target (iscsitgt 
> and comstar iscsi/target) running at the same time, and that iscsitgt 
> "owns" the well known port of 3260.   Could you run "svcs
iscsitgt" to
> verify that the iscsitgt service is off?  
> Other posters have agreed with you  that performance is much worse for the 
> GlobalSAN OSX initiator than for an equivalent Linux initiator.
>
> Peter
I''ll try and get some nice benchmarks for you to counter-act this, but
I
know that I problems with the same initiator, until I dropped the old
style of configuring the targets and went down the new method. 

I have access to the sun server side at the moment, but the mac is off-net at
the moment due to an office move.

I do seem to recall I had a problem getting one of the dependant
services started, but I think i resolved that with a reboot.

Cheers,

Colin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090825/4cfefdf0/attachment.bin>

I am going to upgrade to snv118 and see what happens.

In the meantime would you mind explaining what the new way of configuring
targets is vs the old way.

Thanks
Duncan
-- 
This message posted from opensolaris.org

Ok, I just completed the upgrade to snv 118 and everything still works except
the iSCSI is still sloowww...

It is still unclear to me what the COMSTAR iscsi command set is vs the older
method !!

I presume one cannot use ZFS commands, so could someone point me to a
description of the new way of doing things ?  BTW what is COMSTAR ?
-- 
This message posted from opensolaris.org

On Tue, Aug 25, 2009 at 10:38 PM, Duncan Groenewald <
dagroenewald at optusnet.com.au> wrote:
> Ok, I just completed the upgrade to snv 118 and everything still works
> except the iSCSI is still sloowww...
>
> It is still unclear to me what the COMSTAR iscsi command set is vs the
> older method !!
>
> I presume one cannot use ZFS commands, so could someone point me to a
> description of the new way of doing things ?  BTW what is COMSTAR ?
>

COMSTAR (COmon Multiprotocol Scsi TARget) is the project to unify the "SCSI
target stack" IE: FC, iSCSI, FCOE (although I''m not sure how baked
FCOE is
at this point).

http://www.opensolaris.org/os/project/comstar/;jsessionid=507478D1B2496DCEA0A764D4C8A63131

http://wikis.sun.com/display/OpenSolarisInfo/comstar+Administration

--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090825/040d3885/attachment.html>

OK, I found a blog on COMSTAR and tried creating the iSCSI target using the
"new" method...
Seemed to be ok until sbdadm failed - see below...any ideas?

duncan at osshsrvr:~# itadm create-target
Target iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f successfully
created
duncan at osshsrvr:~# itadm list-target -v
TARGET NAME                                                  STATE    SESSIONS 
iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f  online   0        
	alias:              	-
	auth:               	none (defaults)
	targetchapuser:     	-
	targetchapsecret:   	unset
	tpg-tags:           	default
duncan at osshsrvr:~# sbdadm create-lu
/dev/zvol/rdsk/storagepool/backups/macbook_dg
sbdadm: could not create meta file
-- 
This message posted from opensolaris.org

On Tue, Aug 25, 2009 at 10:54 PM, Duncan Groenewald <
dagroenewald at optusnet.com.au> wrote:
> OK, I found a blog on COMSTAR and tried creating the iSCSI target using the
> "new" method...
> Seemed to be ok until sbdadm failed - see below...any ideas?
>
> duncan at osshsrvr:~# itadm create-target
> Target iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f
> successfully created
> duncan at osshsrvr:~# itadm list-target -v
> TARGET NAME                                                  STATE
>  SESSIONS
> iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f  online   0
>        alias:                  -
>        auth:                   none (defaults)
>        targetchapuser:         -
>        targetchapsecret:       unset
>        tpg-tags:               default
> duncan at osshsrvr:~# sbdadm create-lu
> /dev/zvol/rdsk/storagepool/backups/macbook_dg
> sbdadm: could not create meta file
>

I''m not entirely sure what you''re trying to do here.  Is
/dev/zvol/rdsk/storagepool/backups/macbook_dg a zfs snapshot?


--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090825/e0e8a958/attachment.html>

Oops I left that bit out...

duncan at osshsrvr:~# itadm create-target
Target iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f successfully
created
duncan at osshsrvr:~# itadm list-target -v
TARGET NAME                                                  STATE    SESSIONS
iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f  online   0
       alias:                  -
       auth:                   none (defaults)
       targetchapuser:         -
       targetchapsecret:       unset
       tpg-tags:               default
duncan at osshsrvr:~# zfs create storagepool/backups/iscsi
duncan at osshsrvr:~# zfs create -V 200g storagepool/backups/iscsi/macbook_dg
duncan at osshsrvr:~# sbdadm create-lu
/dev/zvol/rdsk/storagepool/backups/isci/macbook_dg
sbdadm: could not create meta file
-- 
This message posted from opensolaris.org

On Tue, Aug 25, 2009 at 11:14 PM, Duncan Groenewald <
dagroenewald at optusnet.com.au> wrote:
> Oops I left that bit out...
>
> duncan at osshsrvr:~# itadm create-target
> Target iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f
> successfully created
> duncan at osshsrvr:~# itadm list-target -v
> TARGET NAME                                                  STATE
>  SESSIONS
> iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f  online   0
>       alias:                  -
>       auth:                   none (defaults)
>       targetchapuser:         -
>       targetchapsecret:       unset
>       tpg-tags:               default
> duncan at osshsrvr:~# zfs create storagepool/backups/iscsi
> duncan at osshsrvr:~# zfs create -V 200g
storagepool/backups/iscsi/macbook_dg
> duncan at osshsrvr:~# sbdadm create-lu
> /dev/zvol/rdsk/storagepool/backups/isci/macbook_dg
> sbdadm: could not create meta file
>
Can you link the blog you got the instructions from?  I''m unsure why
you''d
do a zfs create instead of just doing an mkfile.  The only reason I can
think of is if you wanted to take snapshots, and you were storing other data
inside the zfs pool you had other data in (HORRIBLE idea IMO).

Oh, and blatant observation here, did you just make a typo?  Your last line
is incorrect as you''ve pasted it.  You put:
sbdadm create-lu /dev/zvol/rdsk/storagepool/backups/isci/macbook_dg

If that''s what you literally typed, you missed an S in iscsi.  It
should be:
sbdadm create-lu /dev/zvol/rdsk/storagepool/backups/iscs********i/macbook_dg


******* added by me to make it obvious what you missed :)


If that''s not it, from all the documentation I''ve see,
they''d prefer you
used mkfile to create your LUN, and typed the path to the file as
/storagepool/backups/iscsi/macbook_dg.

Reference:
http://de.opensolaris.org/os/project/comstar/COMSTAR_Admin-FC-iSCSI.pdf;jsessionid=2C549A4253A0B211ED9DABBF66EF1495

--Tim (four jamesons later)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090825/322c12cd/attachment.html>

That was a typo, missing an s - I copied the incorrect line from the terminal...

sbdadm create-lu /dev/zvol/rdsk/storagepool/backups/isci/macbook_dg

Blog is here...

http://www.cuddletech.com/blog/pivot/entry.php?id=968
-- 
This message posted from opensolaris.org

On Wed, Aug 26, 2009 at 12:09 AM, Duncan Groenewald <
dagroenewald at optusnet.com.au> wrote:
> That was a typo, missing an s - I copied the incorrect line from the
> terminal...
>
> sbdadm create-lu /dev/zvol/rdsk/storagepool/backups/isci/macbook_dg
>
> Blog is here...
>
> http://www.cuddletech.com/blog/pivot/entry.php?id=968
> --
>
So the typo fixed it?

--Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090826/470f811c/attachment.html>

No unfortunately the type does not fix it !!

Still stuck !!
-- 
This message posted from opensolaris.org

Cool - just found the problem.  I had to upgrade the zpool using 
   upgrade zpool storagepool

onwards...
-- 
This message posted from opensolaris.org

All fixed now ...  Backup has been running for maybe a minute or two and has
backed up over 1GB.

Thanks guys...

Here is the complete command set I used...

Creating the ZFS iSCSI target using COMSTAR.

1.  DO NOT use "ZFS set shareiscsi=on ..."  
2.  MAKE SURE your zpool is upgraded.  Run "zpool upgrade" to see and
"zpool upgrade storagepool" to upgrade

Commands
=======01:~# [b]itadm create-target[/b]
Target iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f successfully
created

02:~# [b]itadm list-target -v[/b]
TARGET NAME STATE SESSIONS
iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f online 0
alias: -
auth: none (defaults)
targetchapuser: -
targetchapsecret: unset
tpg-tags: default

03:~# [b]zfs create storagepool/backups/iscsi[/b]

04:~# [b]zfs create -V 200g storagepool/backups/iscsi/macbook_dg[/b]

05:~# [b]sbdadm create-lu /dev/zvol/rdsk/storagepool/backups/iscsi/macbook_dg
[/b]
06:~# [b]stmfadm list-lu -v[/b]
LU Name: 600144F0000827723ED54A95FD4B0002
    Operational Status: Online
    Provider Name     : sbd
    Alias             : /dev/zvol/rdsk/storagepool/backups/iscsi/macbook_dg
    View Entry Count  : 0
    Data File         : /dev/zvol/rdsk/storagepool/backups/iscsi/macbook_dg
    Meta File         : not set
    Size              : 214748364800
    Block Size        : 512
    Vendor ID         : SUN     
    Product ID        : COMSTAR         
    Serial Num        : not set
    Write Protect     : Disabled
    Writeback Cache   : Enabled

07:~# [b]stmfadm list-target -v[/b]
Target: iqn.1986-03.com.sun:02:7af8d188-b1e8-4d98-fee1-f4da18bbe46f
    Operational Status: Online
    Provider Name     : iscsit
    Alias             : -
    Sessions          : 0

08:~# [b]stmfadm list-view -l 600144F0000827723ED54A95FD4B0002[/b]
stmfadm: 600144f0000827723ed54a95fd4b0002: no views found

09:~# [b]stmfadm add-view 600144F0000827723ED54A95FD4B0002[/b]

10:~# [b]stmfadm list-view --lu-name 600144F0000827723ED54A95FD4B0002[/b]
View Entry: 0
    Host group   : All
    Target group : All
    LUN          : 0
-- 
This message posted from opensolaris.org

Unlike NFS which can issue sync writes and async writes, iscsi needs  
to be serviced with synchronous semantics (unless the write caching is  
enabled, caveat emptor).
If the workloads issuing the iscsi request is single threaded, then  
performance is governed by I/O size over rotational latency and that  
is often dismall.

Some form of solid state acceleration becomes a must for iscsi and is  
very often of benefit for NFS.

-r

Le 25 ao?t 09 ? 08:38, Duncan Groenewald a ?crit :
>>
>> On Aug 24, 2009, at 10:02 PM, "LEES, Cooper"
>> <crl at ansto.gov.au> wrote:
>>
>>> Hi Duncan,
>>>
>>> I also do the same with my Mac for timemachine and
>> get the same WOEFUL
>>> performance to my x4500 filer.
>>>
>>> I have mounted ISCSI zvols on a linux machine and
>> it performs as
>>> expected
>>> (50 mbytes a second) as apposed to my Mac that goes
>> @ 1mbyte a
>>> second. I do
>>> believe the client for Mac is crap. Would be nice
>> if apple wrote a
>>> client
>>> for ISCSI.
>>>
>>> But if anyone has a fix for Mac OS X that would be
>> great to know !
>>
>> You know you can do time machine on NFS. An SSD drive
>> will also go a
>> long way too, you really on need a 16GB one for an
>> slog.
>>
>> -Ross
>>
>
> How do you set it up under NFS ?  I managed to get one of my Macs to  
> backup to a ZFS share but this is a smb share not an NFS share.
>
> Can you post details on how to use an NFS share for time machine.   
> iSCSI seems to be very easy to setup but is way too slow to be useful.
>
> Thanks
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2431 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090902/82eec75f/attachment.bin>