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

[ronnie sahlberg]

On Fri, Sep 12, 2008 at 7:20 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
>> 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?
>

If LUN 128 was writeable  it would also have to remember which blocks
were written to after it was split off LUN1.

So when we re-stablish LUN 128 back to LUN1   we would have to copy
all blocks changed on either LUN1 or LUN128 in order to resync.
This is more efficient than copying all blocks.


This is a feature that all enterprise targets support.


One application space to use this would be if you have a large LUN and
you want to do periodic backups of this LUN.

*
You "establish" the connection  so LUN128 is quickly in sync with LUN1 again.
Then you "split" LUN128 off LUN1 so it becomes a point in time snapshot.
(of course,  it is here important that LUN128 is configured to use
different spindles than LUN1)

Now you export LUN128 to a different host , host B.
Host B maps LUN128 and performs a filesystem scan and backup of the data.
While doing this, since LUN128 is using different spindles from LUN1,
there would not be any performance degradation  or impact on the
production I/O to LUN 1   the scan and backup is performed on the
snapshot LUN 128 !

When the backup is finished,   we re-establish LUN 128 back to LUN1
and let them re-sync.   Since we track all the blocks that have
changed, the re-establish is quick,    much much quicker than if we
had to copy all data from LUN1 to LUN128.


loop back to *



The same technology as is used for doing backups above is also useful
for handling things like remote replication. where you
*
split
replicate the deltas
re-establish
loop *
--
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