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

[FUJITA Tomonori]

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

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

Sorry I can't follow you. If sector 1 on both lun 1 and 128 was
modified, which data do you use?


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