On 5/26/07, Roland Smith <[EMAIL PROTECTED]> 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.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
