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 |