Richard L. Hamilton wrote:
[...]
But again, if you use a userland daemon, you won't
have that problem.
Plus, you can do some other tricky things. Like have
the destination
file located on an NFS or iSCSI filesystem or
somesuch. I doubt such
would work right through LDI.
Can't the existing iSCSI target support already emulate a tape device?
What need is there for any additional capability to do that? If there is
(performance reasons, for example) how does it fit into COMSTAR?
Why wouldn't a generic "local" iSCSI transport mechanism (very efficient)
be the best way to do this, allowing potentially any iSCSI device to be
locally emulated with maximum performance?
Not sure if it can given the text in the zfs(1) man page about shareiscsi:
shareiscsi=on | off
Like the "sharenfs" property, "shareiscsi" indicates
whether a ZFS volume is exported as an iSCSI target. The
acceptable values for this property are "on", "off", and
"type=disk". The default value is "off". In the future,
other target types might be supported. For example,
"tape".
But then that contradicts iscsitadm(1M):
create Options
The following are the options and objects for the create
subcommand:
target --size|-z lun_size [--lun number]
[--type disk|tape|raw] [--backing-store|-b pathname]
local_name
...
--lun specifies the logical unit number. --type speci-
fies which type of emulation will occur for the LUN.
disk and tape are the familiar devices. raw indicates
that the emulator will use the uSCSI interface and pass
the command blocks directly to and from the device.
I'd guess from that that iscsitadm does provide tape emulation.
--
Darren J Moffat
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code