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

ronnie sahlberg ronniesahlberg at gmail.com
Fri Sep 12 11:08:52 CEST 2008


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.



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).


This would require a new backend   but would not be rocket science.
When I get time to play with it i might start hacking on it.
--
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



More information about the stgt mailing list