On Thu, Dec 2, 2010 at 2:23 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Thu, Dec 2, 2010 at 1:11 PM, Lukas Czerner <lczerner@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
