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

[ronnie sahlberg]

On Fri, Sep 12, 2008 at 7:43 PM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Fri, 12 Sep 2008 19:34:00 +1000
> "ronnie sahlberg" <ronniesahlberg at gmail.com> wrote:
>
>> This is a feature that all enterprise targets support.
>
> Can you tell me what feature you are talking about?
>
> Sounds like you are taking something like SnapMirror (in NetApp term).
>

I am talking about STD (pruduction lun) BCV (mirror)
and ESTABLISH (the operation to attach and sync the BCV to the STD)
and SPLIT (the operation to disconnect it again so it becomes a
"snapshot)
in emc terminology.


So a workflow for backup would be

1, ESTABLISH BCV to STD,
2, wait until the BCV is fully synchronized
3, SPLIT the BCV off the STD
4, export the BCV to a different host B
5, on host B, mount the BCV and do an incremental backup of the data
6, unmount the BCV from host B
7, goto 1


This is a normal sequence on how to do backups on a production system.
The purpose is so that the backups can be performed by a separate host
using separate spindles from the production lun  so that there is no
impact to performance to access the pruduction lun while performing
the backup.

The STD is always the master  so after the BCV has been ESTABLISHED to
the STD again, the BCV becomes an identical copy of the STD.
This means that all changes made to the STD since the last SPLIT will
have to be merged onto the BCV.
It also means that if there were changes done to the BCV after the
split, these changes must be discarded and these blocks must also be
merged from the
STD onto the BCV.

This is the normal mode. Where you always merge from STD onto BCV so
the BCV becomes identical to the STD.


If using a BCV as the actual backup itself,   in that case one also
need a mechanism to do a reverse merge, that is to ESTABLISH the BCV
with the STD again
but this time they are merged so that the STD becomes identical to the BCV.


In both cases both devices need to keep a bitmap to track which blocks
have changed since last SPLIT.  The only difference is just the
direction of the merge.
>From or to STD.


This would require a new backend for use with the sbc emulation but
would be useful.  I might hack on it in some future.
--
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