Date: Sat, 26 May 2007 19:08:31 -0400 From: "Maxim Khitrov" <mkhitrov@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: Restore UFS snapshot Message-ID: <26ddd1750705261608k68b2318ckca20be5889bc71fd@mail.gmail.com> In-Reply-To: <20070526223143.GA42141@slackbox.xs4all.nl> References: <465864F4.7060500@lvor.halvorsen.cc> <20070526180336.GB34660@slackbox.xs4all.nl> <465884E3.5000500@lvor.halvorsen.cc> <20070526194342.GA37130@slackbox.xs4all.nl> <465898D5.7080607@lvor.halvorsen.cc> <20070526211201.GA40139@slackbox.xs4all.nl> <4658ADB1.3050807@lvor.halvorsen.cc> <20070526223143.GA42141@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/26/07, Roland Smith <rsmith@xs4all.nl> wrote: > On Sat, May 26, 2007 at 11:59:13PM +0200, Svein Halvor Halvorsen wrote: > > Roland Smith wrote: > > > You could use rsync instead of tar. That would save time. > > > > I'm not talking about saving time. But saving CPU time and HDD > > stress. However, the disk space issue is a bigger one: > > rsync would do much less writing than tar. So it would save on "HDD > stress", whatever that is. > > > >> (b) Undo all the bit flipping I have done, since I made the snapshot. > > > > > > This is what the procedure above does if you replace the tar commands > > > with rsync. > > > > No, because the snapshot will still be in use, and hence all its > > bits will be kept intact and read-only. When I use rsync/tar/cpio or > > whatever to "undo" changes to a file system, I will in reality copy > > these bits to different places on the disk. And until I release the > > snapshot (which I very well could, since it would defunct after the > > restore process), I will use twice the amount of disk space. > > You can't restore a previous situation _unless you saved it in some > form_. So if you want a possibility to restore stuff, you'll have to > keep a copy of it somewhere. Maybe in compressed form, and maybe you can > clump changes together in a smart way, but you have to save the bits > that you change. > > Every revision control system (which is effectively what you ask for) uses > storage space to keep previous versions of data, although the precise > method used for this varies. I don't think he is talking about that. From what I understand about the snapshot system (correct me if I'm wrong) is that a snapshot creates it's own file system by remembering, for example, what the superblock was at the time of the snapshot. After that, the live file system continues on its way keeping track of the snapshot, but modifying its own blocks to account for the changes afterwards. I think what Svein wants to do is essentially overwrite a few blocks on the live file system, loosing all references to the changes that have been made and in effect returning the file system to the state it was in when the snapshot was taken. This is different from simply copying the contents of the snapshot back to the disk via an md device. This way he would restore the snapshot and lose it at the same time, but the operation should be O(1) in theory (time and space), as opposed to O(n) which any normal back-up/restore is. Personally, I think this an entirely reasonable thing to do, and I myself would like to see this kind of functionality. Right now, however, I don't think that it is possible.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26ddd1750705261608k68b2318ckca20be5889bc71fd>