Ross Smith wrote: > 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. > But the iqn name is a target name. The method that was chosen for shareiscsi was to leverage the iSCSI target name as the identifier for the zvol used as an iSCSI SCSI logical unit but the fact of that matter is that the zvol, in this context, is a SCSI logical unit, which has its own identifier, which is based on one of the many SCSI device identifiers defined by the SCSI standard, and frankly is even uglier than the iqn. And for COMSTAR, there can and will be more than one SCSI logical unit associated with a given target, whether that target is iSCSI or fibre channel or something else. And while having a 1:1 relationship between the iSCSI target and the logical unit allows the iscsitgtd based zvols to have iqn names associated with them, that is definitely not practical for all SCSI transport protocols. > 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? The target exposes the SCSI logical unit, which is ultimately the usable device on the host, it's not the 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. > I agree, and I feel that we both want the same thing. All I am saying is that modification of the iqn (or other SCSI transport port identifiers) in order to treat it like a user friendlier name for the SCSI device is not the way to get there. An alias for the SCSI device would would work across any protocol. > 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. :-) > I didn't state that this alias I was referring to wouldn't be a ZFS property, I was attempting to, albeit poorly, imply that it would be :) At least for zvols that were used for COMSTAR, the alias would end up as a property, likely, but that has yet to be hammered out. It is currently a property on the COMSTAR logical unit. > 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? Well, iSCSI target names, as per the standard, have to be world wide unique. > 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, I agree that it's easier, but there are still going to be uniqueness issues in the /dev namespace. > 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? That was what I was implying as well. The alias for the COMSTAR logical units allow for 255 characters that let the admin be as descriptive as they want or need. > 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 > There really is no code to check uniqueness of SCSI target identifiers. From an initiator's perspective, two SCSI target port identifiers that are identical for a given protocol, are the same target, regardless of whether the objects that they represent are different.
- John > 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
