On Apr 5, 2007, at 5:01 PM, Nigel Smith wrote:
Rick, I'm trying to comply with your request to retry the test without
specifying the '--type raw', but I'm struggling to get the correct
syntax.
If I simply remove '--type raw', and leave the rest of the line as
it is,
then I get an error:
# iscsitadm create target --backing-store /dev/dsk/c0t0d0p0 --lun 0
zd-4565
iscsitadm: Error Failed to create backing store
Hmm... Very strange. I just reproduced this problem. If you use s
[0-7] partitions it works just fine. For some reason the p0 partition
fails.
So I guess the pathname is no longer valid with out the '--type raw'.
I had a look at the iscsitadm man page, and it does not give many
examples.
I must admit I am not very familiar with specifying storage device
names
for Solaris. In this case I just have a single scsi drive hanging
off a adaptec
pci card, and I want to totally dedicate it to being the storage
device for
the iscsi target. So please could you offer some advise on the correct
pathname &/or syntax to use for this scenario.
Your CLI syntax is correct. I failed to test this case and I think I
know what's occurring. When a block device is given as the backing
store the daemon needs to determine the size of the device and does
so by attempting to read the VTOC or EFI label and get the partition
size for the current path. Since your using p0, which should work,
the daemon needs to deal with these p0 type paths.
On a wider note, I guess the question is this - "For what Rafael is
trying to do,
is using '--type raw' the right approach. Rick, you seem to be
saying - NO".
It would work, if I understand Rafael's setup correctly there's
nothing wrong with using the 'raw' type. My concern would be
performance, in particular increased latency. You've got a RAID array
which has it's own stack and now you're sticking another stack in
front of that which can only increase the latency.
Using the iSCSI Target as a bridge between FC and iSCSI is a cheap
means of allowing other systems to access a FC SAN without purchasing
more FC HBAs and switches. There would be a performance trade off. I
read where certain customers have machines outside of the data center
than have storage needs which are not high bandwidth and low latency.
Today these machines are isolated because the customer don't wish to
invest in FC HBAs and switches for these remote machines. An iSCSI to
FC bridge is a perfect solution which can be done very cheaply.
Also, 'rlhamil' poses an interesting question, regarding using the
iscsi target
to share a dvd burner. I guess he is thinking of something like the
'Alcohol 120%' software available for Windows:
http://support.alcohol-soft.com/knowledgebase.php?postid=20309
I saw that message and it sounds interesting. Someone would need to
look at that some more.
By the way, I did try using 'truss', to look at what iscsitgt was
doing before
the assertion. The following is edited highlights of the calls:
/[EMAIL PROTECTED]: -> raw_cmd(0x4b2e80, 0x472050, 0x10, 0x0, 0x481550,
0x48ec40)
/[EMAIL PROTECTED]: -> raw_read(0x4b2e80, 0x472050, 0x10, 0x0, 0x500,
0x446490)
/[EMAIL PROTECTED]: -> trans_params_area(0x4b2e80, 0x472050, 0x10, 0x0,
0x500, 0x446490)
/[EMAIL PROTECTED]: <- trans_params_area() = 0x472890
/[EMAIL PROTECTED]: -> trans_cmd_dup(0x4b2e80, 0x0, 0x0, 0x0, 0x0, 0xe000)
/[EMAIL PROTECTED]: <- trans_cmd_dup() = 0x4a1ab0
/[EMAIL PROTECTED]: -> trans_aioread(0x4a1ab0, 0x474010, 0x2000, 0x0,
0x480d50, 0x490f78)
/[EMAIL PROTECTED]: <- trans_aioread() = 0
/[EMAIL PROTECTED]: -> trans_aioread(0x4b2e80, 0x476410, 0x2000, 0x2000,
0x480cd0, 0x490f88)
/[EMAIL PROTECTED]: <- trans_aioread() = 0
/[EMAIL PROTECTED]: -> trans_aioread(0x4b2e80, 0x4a7410, 0x2000, 0x4000,
0x480ad0, 0x46b368)
/16: write(2, " A s s e r t i o n f a".., 49) Err#89 ENOSYS
Rick, can you give some further information on the 'bug' you
spotted, for the
benefit of those of us that like to look at your code, and aspire
to understand
what it is doing.
Sure.
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/
iscsi/iscsitgtd/t10_raw_if.c
If you look at line 411 you'll see:
if ((offset * min) < (cnt * 512LL))
The first '*' should be a '+'.
What's happening here is that during a read operation the daemon has
decoded the SCSI CDB and knows how much data must be transfered.
Since transports can impose limits on the amount of data which can be
sent at one point the daemon needs to break up the read if the
transfer limit is less than the command length request. The daemon
uses the original t10_cmd_t pointer if it's the last packet, other it
duplicates the packet using trans_cmd_dup(). With this bug the daemon
attempts to use the original cmd again and the state machine catches
that error and causes the daemon to dump core.
Thanks
Nigel Smith
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
----
Rick McNeal
"If ignorance is bliss, this lesson would appear to be a deliberate
attempt on your part to deprive me of happiness, the pursuit of which
is my unalienable right according to the Declaration of
Independence. I therefore assert my patriotic prerogative not to
know this material. I'll be out on the playground." -- Calvin
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
