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). 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 - 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. 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 -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
