On Sat, 4 Dec 2010, Amir Goldstein wrote: > 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. Fair enough :). -Lukas > > 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
