[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinf9Ww8hA+i2pxJLwx-zzPdvN-t=UWrEe3CogAm@mail.gmail.com>
Date: Thu, 2 Dec 2010 12:03:31 +0200
From: Amir Goldstein <amir73il@...il.com>
To: Lukas Czerner <lczerner@...hat.com>
Cc: tytso@....edu, adilger@...ger.ca, sandeen@...hat.com,
linux-ext4@...r.kernel.org
Subject: Re: [PARCH 0/1 RFC] e2image: Add support for QCOW2 image format
On Thu, Dec 2, 2010 at 10:23 AM, Lukas Czerner <lczerner@...hat.com> wrote:
> On Wed, 1 Dec 2010, Amir Goldstein wrote:
>
>> On Wed, Dec 1, 2010 at 7:41 PM, Lukas Czerner <lczerner@...hat.com> wrote:
>> >
>> > QCOW2 format supports other neat features like compression, encryption and
>> > snapshots. None of those feature are supported in this patch and the question
>> > is, do we need it ? I can imagine for example snapshots to be useful for
>> > roll-back changes made by e2fsck, but this is hardly problem of e2image itself.
>> >
>> > So, please look at the patch, try it and let me know what else you thing is
>> > useful to implement, or what would you like to change.
>> >
>>
>> Hi Lukas,
>>
>> This is very cool :-)
>> My wish is to export next3/ext4 snapshots as qcow2 snapshots.
>> I actually thought of implementing e2image -x <snapid> as a way to
>> export a snapshot image,
>> but using qcow2, file system can be exported with all of it's snapshots.
>> It should be quite trivial since next3 snapshots contain a map of changed blocks
>> and I suppose qcow2 snapshots should be the same.
>> Now I only need to find the time to do it...
>>
>> Amir.
>
> Hi Amir,
>
> I seems like a cool feature, so when QCOW2 infrastructure is in place
> adding snapshots to it should not be a big deal (not that QCOW2
> infrastructure is :)), however I was wondering are you planning to
> export only metadata, or even data itself ?
>
There are 2 applications I can think of for exporting snapshots.
One needs only the metadata and the other requires the data as well.
1. Rollback to snapshot (metadata only)
----------------------------------------------------------
Unlike ZFS/Btrfs, there is no inherent way to "rollback to snapshot"
with Ext4 snapshots.
Instead, all changed metadata needs to be copied over from snapshot.
The only plausible way to do this is to un-mount the file system (or
re-mount read-only),
use e2image to export a metadata image of a snapshot to a different
location and then
overwrite the filesystem with snapshot metadata (data blocks are
already in-place).
This method can be applied today, even without qcow2 support, but with
qcow2 snapshots,
you can generate a single e2image, which can be used to rollback to
any snapshot and to
restore the original filesystem (as long as the rolled back version
wasn't modifed).
2. Filesystem replication (data + metadata)
--------------------------------------------------------------
This application is inspired by ZFS replication:
http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html
The idea is to start with a remote replica by transferring a full copy
of snapshot N1
and then push incremental differences N1..N2 to roll the replica to snapshot N2.
So if e2image has the ability to export a full snapshot image (including data)
and the capability to export incremental qcow2 snapshots, those could
be transferred
to the remote location and be used to create and update the replicated
filesystem.
So to answer your original question ("what else you thing is useful to
implement"),
e2image -d would be nice (export data blocks).
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists