This thread is actually a bit different than what you're experiencing. I never
see any huge memory usage from the iscsitgtd in the process table, but I'm
definitely encountering memory leaks. And the box itself stays stable and at
low CPU utilization. I can restart the iscsitgtd and the problems disappear.
However, I think I know the problem you are encountering well, and have managed
to overcome it. It looks like you found my post from last November with the
answer. 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 problem, 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!!!).
Check out this thread I made back in Nov, and you'll see what I was
experiencing:
http://www.opensolaris.org/jive/thread.jspa?messageID=178912𫫠
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
