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

Reply via email to