On Sat, 2002-06-22 at 13:41, Douglas Gilbert wrote:
> >
> > The interaction between iSCSI & driverfs does pose an interesting
> > problem:
> >
> > On one hand I tend to lead toward the view of a physical device.
> > The reason being that there will never be a distinction as far as the
> > kernel is concerned (other than driverfs of course) that a SCSI upper
> > level driver (hopefully soon to be a personality driver) using a iSCSI
> > Initiator low-level driver is not really a physical host.
> >
> > On the other hand there is the obvious fact that an iSCSI initiator
> > driver is not attached to a bus, and assuming /root/iSCSI.target/disk1
> > etc, is out of the question. There is a real need for a solution to
> > handle virtual devices (as stated your previous message) that are not
> > assoicated with any physical connectors.
> >
> > Not being too fimilar with driverfs, what are the options with regard
> > to virtual devices as things currently stand without tainting the
> > elegant tree that is provides?
>
> iSCSI introduces some other issues. The SCSI subsystem has
> a 4 byte target (port) identifier at the moment. However Annex A
> of the SAM-2 draft ( http://www.t10.org ) indicates that it should
> be 258 bytes for iSCSI (and 11 bytes for ieee1394). For iSCSI the
> target port identifier is a WWUI plus a 2 byte target portal group
> tag. A WWUI looks like:
> com.disk-vendor.diskarrays.sn.45678
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/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:26 EST