Thanks for the reply John, replying in line: On Sat, Dec 6, 2008 at 8:02 PM, John Forte <[EMAIL PROTECTED]> wrote: > 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.
Is there any downside to relaxing this slightly though? > 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. While there may be other protocols providing access to the zvol, does that matter? Both NFS and CIFS have the ability to set share names as part of the ZFS pool, and there's nothing that stops you setting both properties on a single pool. While you say that the current implementation makes it possible to expose a logical unit via any SCSI transport without changing parameters, I don't see how adding names hurts that. While it might be possible to expose it via many protocols now, but can you easily tell that it's the same target? I don't see that custom names for each transport exposed as ZFS properties causes any problems exposing it via other transports, but it does make identification simpler (even across multiple protocols) if people want to make use of it. It would be really handy to know that should a server die, you can take your disks and fit them to any standard working Solaris server and have all your shares and targets available. >> >> - 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. Cool,if I ever do persuade you that supporting names in ZFS is a good idea, aliases sound perfect for it. :-) Could I suggest that if aliases are possible, you add an option to the iSCSI initiator, allowing the alias to be used as the basis for the device identifier? I can appreciate that they have to be unique, but am I right in thinking that would be per server? Could you simply display a warning, or add a suffix if a clash is detected? I appreciate that all these aliases are exposed, and you can find the information you need with just a few of the tools in Solaris, but I'm a big fan of keeping things simple. I think it's a lot easier to have an alias that's then used as the device name, because then you don't need a whole bunch of tools to work out your configuration, a simple ZFS status tells you everything you need. What I would say is that if you have aliases, why shouldn't they be more descriptive of the objects they represent? Is an iscsi target ever going to be moved to point to a new storage volume? Each target is simply a way of accessing that object over a particular protocol. Apart from the uniqueness requirements, you could have automatic names provisioning a ZFS pool called 'mypool' over iscsi as 'server-mypool-iscsi', over fibre as 'server-mypool-fc', etc. The way I see it, these long names are needed if you want to *automatically* guarantee uniqueness. They're not needed if you have a human there capable of picking appropriate names. I'm guessing that the uniqueness needs to be present on both the server and client side, but I would also guess that there's code to check this uniqueness already, and in that case, is there any harm done by allowing human readable names? If a name doesn't meet the uniqueness requirement, a simple error message is all the administrator needs to change it to something else. Ross _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
