I think I know the problem you are encountering well, and have managed to 
overcome it. I'll outline here exactly how I'm creating my iscsi targets, and 
I'm hoping you might see where your commands are different.

As Jim pointed out, the problem was that I was creating the filesystem on a 
cached zfs volume. I should have been using the ***R***dsk path when creating 
it. Here's how I configured the iscsi targets successfully without using a ton 
of RAM, and utilizing the shareiscsi=on functionality successfully:


[u]Here I've got the pool created with seven disks:[/u]
bash-3.00# zpool status
  pool: backups
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        backups     ONLINE       0     0     0
          raidz1    ONLINE       0     0     0
            c2d0    ONLINE       0     0     0
            c3d0    ONLINE       0     0     0
            c4d0    ONLINE       0     0     0
            c5d0    ONLINE       0     0     0
            c6d0    ONLINE       0     0     0
            c7d0    ONLINE       0     0     0
            c8d0    ONLINE       0     0     0

errors: No known data errors
bash-3.00# zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
backups                4.75T    232G   4.52T     4%  ONLINE     -

[u]Here are my existing filesystems:[/u]
bash-3.00# zfs list
NAME              USED  AVAIL  REFER  MOUNTPOINT
backups          1.98T  2.00T  26.7G  /backups
backups/server1  2.78G  2.98T  2.78G  -
backups/server2  85.3G  2.02T  85.3G  -
backups/server3  71.5G  2.03T  71.5G  -
backups/server4  11.7G  2.28T  11.7G  -

[u]Now I'm creating a new zfs filesystem of 500 GB:[/u]
bash-3.00# zfs create -V 500G backups/sample

[u]Here are my existing targets (before turning on shareiscsi on this new 
filsystem):[/u]
bash-3.00# iscsitadm list target
Target: backups/server1
    iSCSI Name: iqn.1986-03.com.sun:02:2cd67427-eeeb-e32f-e9b2-a1db82f81b9d
    Connections: 0
Target: backups/server2
    iSCSI Name: iqn.1986-03.com.sun:02:82994ecc-94cd-6616-85c8-f77b6f415724
    Connections: 0
Target: backups/server3
    iSCSI Name: iqn.1986-03.com.sun:02:485b5231-9bca-437c-9888-fb57f0fd099d
    Connections: 0
Target: backups/server4
    iSCSI Name: iqn.1986-03.com.sun:02:1efe77e7-1fd3-60f6-e1c3-8fc2f4f74fd9
    Connections: 1

[u]Now I'm going to set shareiscsi=on on my new filesystem:[/u]
bash-3.00# zfs set shareiscsi=on backups/sample

[u]And behold, the new target exists (and the machine doesn't grind to a 
halt:[/u]
bash-3.00# iscsitadm list target
Target: backups/server1
    iSCSI Name: iqn.1986-03.com.sun:02:2cd67427-eeeb-e32f-e9b2-a1db82f81b9d
    Connections: 0
Target: backups/server2
    iSCSI Name: iqn.1986-03.com.sun:02:82994ecc-94cd-6616-85c8-f77b6f415724
    Connections: 0
Target: backups/server3
    iSCSI Name: iqn.1986-03.com.sun:02:485b5231-9bca-437c-9888-fb57f0fd099d
    Connections: 0
Target: backups/server4
    iSCSI Name: iqn.1986-03.com.sun:02:1efe77e7-1fd3-60f6-e1c3-8fc2f4f74fd9
    Connections: 1
[b]Target: backups/sample
    iSCSI Name: iqn.1986-03.com.sun:02:130d1ac4-f846-e29e-cc45-819663bda4e2
    Connections: 0[/b]


When I first starting working with iSCSI and ZFS, I couldn't get the 
shareiscsi=on flag to create the target. I was trying to do things manually 
because of that, and that is when I discovered the huge memory usage (I could 
watch the iscsitgtd try to allocate four terabytes of RAM when I tried to share 
the whole pool... yes, it really did grind to a halt, but tried for a good 
eight hours before dying!!!).

Hope it helps-
John
 
 
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to