[stgt] Late opening of the backing store

[ronnie sahlberg]

For "SBC device without media"

This is mentioned in the SBC standard :
---
4.3 Removable medium
4.3.1 Removable medium overview
The medium may be removable or non-removable. The removable medium may
be contained within a
cartridge or jacket to prevent damage to the recording surfaces.
A removable medium has an attribute of being mounted or unmounted on a
suitable transport mechanism in a
direct-access block device. A removable medium is mounted when the
direct-access block device is capable
of performing write, read, and verify operations to the medium. A
removable medium is unmounted at any
other time (e.g., during loading, unloading, or storage).
An application client may check whether a removable medium is mounted
by issuing a TEST UNIT READY
command (see SPC-4). A direct-access block device containing a
removable medium may not be accessible
for write, read, and verify operations until it receives a START STOP
UNIT command (see 5.19).
If the direct-access block device implements cache, either volatile or
non-volatile, it ensures that all logical
blocks of the medium contain the most recent user data and protection
information, if any, prior to permitting
unmounting of the removable medium.
The PREVENT ALLOW MEDIUM REMOVAL command (see SPC-4) allows an
application client to restrict the
unmounting of the removable medium. This is useful in maintaining
system integrity.
If the application client issues a START STOP UNIT command to eject
the removable medium, and the
direct-access block device is prevented from unmounting by the PREVENT
ALLOW MEDIUM REMOVAL
command, the START STOP UNIT command is rejected by the device server.
---


Most popular of these in the past I guess where these iOmega Jaz, but
there were others too.
Today this is probably rare in physical devices, but removable media
SBC can be very useful for
emulated devices, such as TGTD.

One usecase is for sophisticated targets where you have "snapshot" capability.
Usecase :
Once every xyz min/hour  you snapshot the production LUN.
The snapshot file is automagically named with a filename that
represents the time+date of the snapshot.
The last xyz snapshots are then also automatically made available via
a different LUN and a mediachanger,
so that you can then access any one of the last xyz snapshots via the changer.
Swapping which media is the current one in the reader thus needs that
SBC device used as the data transfer device to be online/offline
settable as media is loaded/removed.


Specific use case why people liked to do this was so that you could
run your production exchange server using the production LUN and never
take it offline.
When you had to access an old/backup/snapshot instead you have a
secondary exchange server you expose these
media-changer/snapshots-of-production-LUN.
This allows you then to access and extract exchange data and un-delete
emails from any of the old backups without having to take the
prodution server offline.


I think it would be very useful to have SBC emulation in TGTD support
removable media.
Then also update SBC and SMC to make sure we can build SBC-jukeboxes.

I can do that work to make sure it works and document how to set it up.


regards
ronnie sahlberg

On Thu, Jan 19, 2012 at 10:34 AM, Môshe van der Sterre <me at moshe.nl> wrote:
> On Thu, 19 Jan 2012 08:14:28 +0900, FUJITA Tomonori
> <fujita.tomonori at lab.ntt.co.jp> wrote:
>> On Wed, 18 Jan 2012 23:43:51 +0100
>>> Manually, this is possible, however, the administration tool (LVM for
>>> example) can't do this.
>>> This is the issue I am trying to solve. udev triggers would work great
>>> for this.
>>
>> Hmm, I guess that you can easily write your own administration tool
>> (that could call the existing tools).
>>
>>> >> Is short this means stgt should defer the open() call on the backing
>>> >> store until a connection is requested. Likewise, it should close() the
>>> >> backing store when the last connection closes.
>>> >> I am guessing such a feature does not yet exist (I couldn't find it),
>>> >
>>> > tgt supports such feature for MMC logical units. But what tgt should
>>> > return to initiators when the initiators try to access to devices that
>>> > are not available?
>>>
>>> I am not sure (I don't know that much about the internals of iSCSI), I
>>> suppose the same thing as would happen now if a backing store is
>>> unplugged/truncated while stgt has opened it?
>>> Is this an error condition that is not possible with iSCSI?
>>
>> It's not about iSCSI but SCSI. Ronnie gave some hints. If you give me
>> pointers in the SCSI specs that this behavior is ok and send patches,
>> then I'm not against merging them.
>
> Ok.
> I'll look into it some more (but it might be a while before I do).
> I think this is a more general solution than adding stgt specific hooks
> to other tools, but I'll take the consequences it has on SCSI into
> account.
>
> Thanks,
> Môshe van der Sterre
> --
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html