Restore UFS snapshot

[Maxim Khitrov]

On 5/27/07, Roland Smith <rsmith at xs4all.nl> wrote:
> On Sat, May 26, 2007 at 07:08:31PM -0400, Maxim Khitrov wrote:
> >  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.
>
> More or less. You should read §8.7 of McKusick's book, or the paper he
> wrote about it;
> http://www.usenix.org/publications/library/proceedings/usenix99/mckusick.html
>
> For instance, every time you change a block on a filesystem that has a
> snapshot, the filesystem checks wether that block is in the snapshot
> already. If not it writes the old contents of that block to the snapshot
> before writing the new contents to the filesystem block.
>
> >  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.
>
> It's not just a question of references. You'll have to copy all the
> changed blocks back, and change the inodes, et cetera.
>
> >  This is different from simply
> >  copying the contents of the snapshot back to the disk via an md
> >  device.
>
> If you are using something like rsync it's not very much different.
>
> The point is that you're using established and debugged methods and code
> to change the filesystem, instead of writing new tools to do the same.
>
> >  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.
>
> You don't lose the snapshot untill you delete it. And even then there
> are situations where not all the used space can be reclaimed. If a
> subsequent snapshot was taken, for instance.
>
> The process of undoing the snapshot can't be O(1). Because the time
> needed to create the shapshot isn't either.

Wait a sec, when you mount a snapshot as a memory disk, does that
memory disk contain the snapshot as well? I haven't done this in a
while, but since the snapshot didn't exist when it was being created,
I don't see how it would. Now when you mount that snapshot, the
superblock is read and from there we find out all the necessary
information about the file-system. This is an O(1) operation is it
not?

I'm not seeing why this process can't be slightly modified to
roll-back the live file system. There shouldn't be a need to copy any
changed blocks or modify inodes because mounting the snapshot doesn't
require this. The data is already there, all the references to it are
there, these references are just not in the right place for the live
file system to use them. The snapshot superblock contains the same
information regarding the size of the file-system and all other
parameters, so if we were to overwrite the superblock why wouldn't
everything return to the same state you see it in when you mount that
same snapshot?

This is why I said that you lose the snapshot itself, because it's not
there when it was taken, and you lose the references to all the
changed blocks of the live file system. Through the data would still
be there on the disk, as far as the snapshot is concerned it's now
free space that can be overwritten. I mean I understand that there
could be some other updates that need to be done, but I don't see a
need to move or modify any inodes around because everything is already
in place to be used, the live file system just needs to be told how
and where everything is, in the same way the memory disk does this.

The only real problem I see is about how "filesystem checks whether
that block is in the snapshot already," as you put it. Is this a flag
stored in the inode, or does it involve reading through the snapshot's
superblock to see if some inode is referenced by it? In the former
case, I suppose the operation wouldn't be O(1) because you'd need to
clear all the flags, but you still wouldn't need to move anything
around. In the latter case it's even easier. What am I missing from
this picture that prevents something like this being done?

- Max