Ben Rockwood wrote: > Thank you for the PDF with illustrations, it helped convey the concepts. > > While offhand I can't think of any advantages to have control via the > view layer I do like the flexibility to have that control if I see > fit. This is a feature commonly missing from iSCSI Target > implementations and I'm glad to see it. > > My concern would be with how it's managed, particularly via the CLI. > Managing these views, while more flexible, could become very confusing > and introduce significant human error and/or frustration. We hope that the CLI, stmfadm, is simple enough for managing view entries. You can take a look at the manpage that we currently have. It's stmfadm.pdf at the project website.
> > To that end, do you intent to bring forward the existing iSCSI Target > CLI interface? And if so, how to you intend to weave views into the > command structure? My only request would be that the interface would > not require you to manage views by default; a given I would think. In current iSCSI CLI terms, when a new target and logical unit is created, that logical unit is accessible by any initiator by default. Setting a target ACL changes that behavior. It is likely that for COMSTAR, the default will no longer be 'accessible by all' but rather 'accessible by none'. However, it is simple enough to get that 'accessible by all' behavior with one command on the logical unit: # stmfadm add-view <lu-name> This command would add a view entry indicating all initiators have access and the logical unit is to be exported via all target ports with the logical unit number being assigned by the system. So, in terms of managing views, if there are any requirements that go beyond 'accessible by all' for the logical unit, view entries would definitely need to be managed. The document on view entries explains some of that management via examples and illustrations. As for the existing iscsitadm, it will not have this concept of view entries or anything related to the logical unit for that matter. The thought is that the existing iscsitadm will be more of a set-and-forget tool rather than one that required frequent usage to manage your storage. In order for iscsitadm usage to decrease, there would have to be fewer targets created. For example, in our opinion there really shouldn't be much of a need to create more than a few targets from which the logical units are exported. In COMSTAR, for iSCSI at least, once the targets are created and tied to the IP addresses via the target portal group tags, the assignment to export the logical units via a given target would be done using stmfadm. And for fibre channel, excluding NPIV support, there will be 1 target for each fibre channel port WWN, so the ability to create a target for each logical unit will not be available. Even with NPIV, it's not likely that it would ever be used to have the target ports map to the logical units in a 1:1 relationship. And just to expand on the 'fewer targets' idea, in our view, more targets means more management complexity. Each target that gets added for iSCSI, as an example, requires discovery to be updated. When using SendTargets, I would agree there isn't much to do there if the IP address is already discovered, but enter iSNS and it means having to add each newly created target to the discovery domain. Additionally, consider the other benefits of having multiple logical units on a single target. If the target is already discovered by the initiator, there is a SCSI mechanism in place for discovering new logical units. Granted, it's not asynchronous, but providing there is some I/O going to one of the existing logical units on that target, the initiator will receive a check condition with sense data indicating that the REPORT LUN data has changed. And at least for the Solaris iSCSI initiator, your new device would automatically be onlined. If you were using SendTargets discovery and a new target was added, the discovery process would need to be initiated in order to discover the new target even if you had I/O going to an existing logical unit on another target. I'm sure there are benefits that could be realized in using 1 target for each logical unit and there is nothing COMSTAR is doing that will remove that ability. It's just our viewpoint that, in most environments, it creates more complexity than necessary. - John > > Great idea. I'm very excited about COMSTAR. > > benr. > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
