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 |