Nevermind, My memory is starting to fail me. The target value you listed
is based on the session OID (ie. A lame IMA value the initiator tracks.)
This isn't going to help you much as the OIDs are not required to persist
across reboot (ie. Your mappings might float around using the target
property.) I guess I should have been more consistent with the
/etc/path_to_inst
value years ago.
http://cvs.opensolaris.org/source/xref/nwsc/src/sun_nws/iscsi/src/iscsi_lun.c#417
What is the application your trying to get to work?
My guess is that application is using that funky mapping because the
/dev/rmt/#
with FC on Solaris floats around across reboots unless you follow the
workaround
someone posted about a Sun blog a year ago. To avoid those types of
issues I
used the /etc/path_to_inst value for the /dev/rmt/# with iSCSI. I
didn't really
expect at the time for someone to use the target property outside the OS.
http://cvs.opensolaris.org/source/xref/nwsc/src/sun_nws/iscsi/src/iscsi_lun.c#456
It might be possible for someone at Sun to migrate the target property
to use that same path_to_inst value. Although I'm not completely sure of
all the code impacts right now. There shouldn't be an upgrade impact that
I can think of since the target property value will already float across
reboots, due the OIDs nature.
David Weibel wrote:
The target value should be based on the /etc/path_to_inst value if I
remember correctly.
Louwtjie Burger wrote:
I've noticed from prtconf the following:
"name='lun' type=int items=1
value=00000000
name='target' type=int items=1
value=00000074
Device Minor Nodes:
dev=(33,1560)
dev_path=/iscsi/[EMAIL PROTECTED],0:
spectype=chr type=minor
dev_link=/dev/rmt/9
"
Could someone please explain the target value ...
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
