[stgt] Late opening of the backing store

[FUJITA Tomonori]

On Wed, 18 Jan 2012 23:43:51 +0100
**UNKNOWN CHARSET** <me at moshe.nl> wrote:

> On Thu, 19 Jan 2012 07:17:21 +0900, FUJITA Tomonori
> <fujita.tomonori at lab.ntt.co.jp> wrote:
> > On Wed, 18 Jan 2012 23:06:36 +0100
> > **UNKNOWN CHARSET** <me at moshe.nl> wrote:
> > 
> >> For example, I want the ability to export all volumes in a LVM
> >> volumegroup automatically, this can easily be done with a udev script
> >> to
> >> add the LUN. The same could be done for removing the volume, only stgt
> >> prevents this by making LVM mark the device 'in use'. I would like a
> >> option so stgt only 'uses' the device, if there is a connection that
> >> _really_ uses the device.
> > 
> > Why you can't remove the device from tgt?
> 
> 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.
--
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