Message-ID: <AANLkTinmykTQPzHhQQ-gk2wP0XhuqmgY3wZ2Chq2mkgf@mail.gmail.com>
Date:	Sat, 4 Dec 2010 09:37:20 +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 2:23 PM, Amir Goldstein <amir73il@...il.com> wrote:
> On Thu, Dec 2, 2010 at 1:11 PM, Lukas Czerner <lczerner@...hat.com> wrote:
>>
>> You can export just the diff between some snapshots as you mentioned and
>> then, when installing it on another filesystem the utility doing the job
>> (e2image probably) would know what to do even without qcow2 snapshots,
>> since all the data needed are in the image anyway, qcow2 snapshot is just
>> useless abstraction we do not need in this case.
>
> I agree. I was forcing my problem over this solution, trying to squeeze every
> last drop of coolness from qcow2 snapshots. it doesn't fit in here.
>
> Still for the first problem (rollback) I think that qcow2 snapshots can be a
> perfect and simple solution.
>
> e2image starts with exporting filesystem to full qcow2 image, then takes
> a qcow2 snapshot and proceeds writing blocks modified by latest snapshot
> and so forth until the oldest snapshot.
>
> The resulting qcow2 snapshot list is an inversion of the Ext4 snapshots list
> and it gives you both the ability to rollback to any older snapshot and to
> undo all rollbacks by restoring the base image.
>

Hi Lukas,

I think I may have failed to explain my reasoning for using qcow2
snapshots properly and I understand your confusion.

Of course, if e2image would produce a full image of the filesystem,
Ext4 snapshots information would be a part of the information
encoded in the image.

For rollback to snapshot application, at some point, either on image
creation or on image install, the snapshot diff patches
(which are stored in the snapshot inodes) need to be decoded.

If the snapshot diffs are decoded on e2image install, there is no need
for qcow2 snapshots, like you said.

My suggestion to decode the snapshot diffs on e2image create and to
store them in qcow2 snapshots format
has 2 advantages over decoding on e2image install:

1. Should we want to implement create of snapshot image using e2image
-x <snapid>,
the easiest implementation would involve creating a full filesystem image
and then applying snapshot diffs on top of it. With this implementation,
we can get the full filesystem image and an image of every snapshot on the way
to <snapid> with no extra cost, if we just start a qcow2 snapshot before
applying every snapshot diff.

2. At the moment, the only way to access next3 snapshots is to mount
the filesystem
and then mount the snapshot via a loop device. Now if there is a
problem to mount the filesystem
the snapshots are not accessible as well, which is a shame if you want
to backup some data
before attempting to fix the filesystem.
Using the qcow2 exported image (with snapshots converted to qcow2
snapshots), it is possible
to mount every one of the snapshots, directly from the qcow2 image,
and recover some files,
without the need to rollback the entire filesystem.

When the qcow2 infrastructure is ready, I will rebase my e2fsprogs
snapshot patches,
implement e2image -x and consult you about using qcow2 snapshots.

Cheers,
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