Yikes, 4 bytes? Is there any special considerations bumping up the to
the maximum for an iSCSI Initiator SCSI port name of 264 bytes?
>
> Also the SCSI subsystem has tended to hide the the initiator's
> own identifier (this is usually id 7 on the SCSI parallel bus).
> For iSCSI it may be worthwhile to make the initiator port
> identifier visible in driverfs.
>
Agreed.
> There is also the case where you want a box to appear to
> the network as an iSCSI target. In this case once a iSCSI
> login is complete you might want to represent the initiator
> in the driverfs tree. For iSCSI, the initiator port identifier
> is a WWUI plus a 6 byte "inititator session id" for a total
> of 262 bytes.
>
Now this would be interesting, although I am not sure how useful
this would be if the user cannot see the entire iSCSI network or if this
would not be better left to userspace. But of course that is out of the
scope of driverfs.
> So the "target id" we put in driverfs could have one of
> these suggested formats:
> <number> - 0 to 1 for ATA
> <number> - 0 to 15 for SCSI parallel interface
> <number> - 24 bit number for fibre channel
> <EUI 64+discovery_id> - ieee1394
> <???> - usb (mass storage + scanner)
> <WWUI> ":" <num> - iSCSI [something better than ":"?]
>
What does the ":" <num> represent? Would not each <WWUI> directory
contain the devices which are currently in use from that iSCSI target
node?
>
> We should also be moving towards 8 byte luns which in one
> descriptor format are a 4 level hierarchy (2 bytes at each
> level).
<nod>
>
> Doug Gilbert
>
Thanks,
Nicholas Bellinger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/