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@xxxxxxxx> wrote: > On Thu, 19 Jan 2012 08:14:28 +0900, FUJITA Tomonori > <fujita.tomonori@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
