[stgt] [PATCH 1/2] tgt-admin: check if direct-device exists before allocating it

[FUJITA Tomonori]

On Fri, 12 Sep 2008 19:08:52 +1000
"ronnie sahlberg" <ronniesahlberg at gmail.com> wrote:

> On Fri, Sep 12, 2008 at 6:33 PM, FUJITA Tomonori
> <fujita.tomonori at lab.ntt.co.jp> wrote:
> > On Fri, 12 Sep 2008 18:18:34 +1000
> > "ronnie sahlberg" <ronniesahlberg at gmail.com> wrote:
> >
> >> If in the future STGT gets the ability to snapshot a lun or a set of
> >> luns,
> >
> > You mean adding a snapshot feature to stgt (something like qcow
> > file support)?
> 
> I was thinking about it.   It would be similar to, but not quite the
> same as, qcow.
> 
> 
> To match enterprise storage systems it is often useful to have
> a production device LUN 1 then you associate to this device a "mirror"
> device LUN128.
> 
> 
> This association can be in two states,   connected or detached.
> 
> 
> While in the connected state,  the "mirror" LUN 128 is identical to LUN1.
> So everytime I/O is performed to LUN1  this is immediately visible in
> LUN 128. They are in sync.
> In this mode it is similar to a mirror like in normal disk mirroring.
> 
> When it is in detached state it becomes a point in time copy of  the
> production lun. It is no longer mirroring the production disk and
> instead is like a
> point in time snapshot of the production LUN.

Sounds that you can do this with a writable snapshot feature, which
dm-snapshot supports.


> The extra stuff now that makes this not just a copy on write
> implementation is that once we have split/detached LUN128 so it
> becomes a snapshot,
> the backend for LUN1 still knows that there is a relation to LUN128
> and thus keeps track (bitmap) of  which blocks have been modified
> since we split off LUN128.
> The purpose of this is to allow you to efficiently re-attach LUN128
> back to LUN1 again so that it once again become a mirror and while
> doing so, since LUN1 knows which blocks have changed we can re-sync
> the data efficiently (at least more efficiently that copying all
> data).

I'm not sure re-attach thing. For example, lun1 and lun128 have
different data on sector 1 (either (or both) was modified after the
detatch). So after the re-attach, if an initiator tries to update
sector 1, the new data will be stored to both lun1 and lun128?

what can we use this feature for?
--
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