On Jan 14, 2008 11:29 AM, Nigel Smith <[EMAIL PROTECTED]> wrote:
> One of Rick McNeal's posts, from last year, gives some
> backround on what might be happening:
> http://mail.opensolaris.org/pipermail/storage-discuss/2007-April/002567.html
> Maybe someone from the team currently working
> on the iscsi target can tell us if they still think
> this is a good idea.
> Regards
> Nigel Smith
That's what I thought was going on. It seems as though this behavior
can be skipped if using volumes.
# zfs create -o shareiscsi=on -o reservation=10m -V 100g san/100g
[long pause in door_call(7, 0xFFBFC3C0), /etc/dev/.devfsadm_synch_door]
cannot share 'san/100g': iscsitgtd failed request to share
filesystem successfully created, but not shared
# iscsitadm list target -v san/100g
Target: san/100g
iSCSI Name: iqn.1986-03.com.sun:02:9455f395-5393-605b-d711-d7142a1cc832
Alias: san/100g
Connections: 0
ACL list:
TPGT list:
LUN information:
LUN: 0
GUID: 010000144f0f42c400002a00478b9f6f
VID: SUN
PID: SOLARIS
Type: disk
Size: 100G
Backing store: /dev/zvol/rdsk/san/100g
Status: online
# zfs get all san/100g
NAME PROPERTY VALUE SOURCE
san/100g type volume -
san/100g creation Mon Jan 14 17:43 2008 -
san/100g used 16K -
san/100g available 49.1G -
san/100g referenced 16K -
san/100g compressratio 1.00x -
san/100g reservation 10M local
san/100g volsize 100G -
san/100g volblocksize 8K -
san/100g checksum on default
san/100g compression off default
san/100g readonly off default
san/100g shareiscsi on local
san/100g copies 1 default
The same pause and error message came about trying to create a 50MB
volume shared via iSCSI.
I'm not sure that it makes sense to have the iSCSI target hold my hand
so forcefully when other components (ldom vdisk, lofi, zfs zvols) with
similar failure scenarios don't.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
