Well, in reply to that I think all I can say is that you understand all this an awful lot better than I do, and it sounds like you know exactly where we're coming from.
I'll sit back and look forward to whatever features you guys can shoehorn in :) all the best, Ross On Sat, Dec 6, 2008 at 10:56 PM, John Forte <[EMAIL PROTECTED]> wrote: > 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
