Ross wrote: > Heh, that's kind of ironic. The flexibility of ZFS, and the ability to work > with large numbers of automatically created targets is what made these huge > iscsi and device names necessary, but in return they make it a nightmare to > work with large numbers of targets in ZFS. > > You have huge iqn names, and similarly huge device names. It's a nightmare > to track which ones are related to each other, and creating ZFS pool of any > size means using plenty of copying and pasting (crossing your fingers is also > recommended). >
The iqn names are huge, ugly, generally non-descriptive with respect to their underlying objects, but that comes with the territory when you are dealing with world wide uniqueness in identifiers. I think it is important to note that the iqn identifiers are target device identifiers, not logical unit (in this case the zvol maps directly to the logical unit) identifiers. The distinction is important for a number of reasons but specifically for COMSTAR, as described below, it's a key element in the design of that framework. > I don't know if the new iscsit provider of COMSTAR is going to be integrated > with the ZFS code (although I'd be amazed if it isn't), but what I'd really > like to see is ZFS, the iSCSI target and the iSCSI client working together in > one neat system something like this: > > - Within ZFS, have a parameter for setting the iqn > I don't believe this should be a ZFS property/parameter. The iqn is specific to iSCSI. It represents an iSCSI target, not a SCSI device that happens to be exposed via iSCSI. There could be other SCSI transport protocols that provide access to the zvol, such as fibre channel, SAS, etc. And each of those protocols have their own identifiers, although it's true that fibre channel and SAS use the same identifier format for their target ports. In COMSTAR, the logical units (again, in this case the zvol) are very much separated from the targets that expose those logical units to the initiators. This provides the ability to expose a logical unit via any SCSI capable transport that is supported without changing any of the properties on the logical unit. > - Have a second parameter to choose how inherited pool names are created, > with an option to have names as simple as zfs1, zfs2, zfs3, etc > - Have the iscsi initiator use these simple names when creating devices, > giving you drive names like: c2tzfs1, c2tzfs2, c2tzfs3 > > A naming convention like this would let you do things like use the server > name as part of the iqn. Because that passes to the drive name, that makes > it really easy to look at a zfs pool and understand at a glance where all the > targets are coming from, which would be a godsend for troubleshooting. > What we have done in COMSTAR is provided the ability to set a logical unit alias, although at the moment this is not available via the admin tools and is something set by the logical unit provider. But our thought was that this alias could serve as the more user friendly name that I believe would help ease the mapping pain that you are referring to here. We don't have all the pieces in place yet but I think we have the basics needed to achieve it. In the beginning, it might not be the case that those more user friendly names would be embedded in the device paths, but there would likely be tools available that would allow you to easily retrieve them from the host side. Again, these are early thoughts that we had and much is still to be done. But I do not think that iqns/eui, fibre channel WWNs, SAS WWNs, etc. need to be more more descriptive of the underlying objects they represent. Particularly since those identifiers must be guaranteed to be unique. But I do think that there absolutely needs to be better ways for administrators to easily identify the host devices as far as how they map to the devices present in and provisioned from the storage server. Additionally, each of those target identifiers generally have aliases that can also be used for better and friendlier representation. For iSCSI, there are target aliases, for fibre channel there are port symbolic names. Both of those aliases are currently exposed using host tools available today. - John > In addition, it should be possible to set the ZFS parameter for setting the > iqn to any volume, overriding existing or auto generated names. > > Ross > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
