Restore UFS snapshot

[Roland Smith]

On Sun, May 27, 2007 at 11:01:53AM -0400, Maxim Khitrov wrote:
> > 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? 

Depends of your definition of "contain". Technically, the snaphot is the
backing store for the memory disk.

>  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.

I don't know what you are saying here. You have to create a snapshot
before you can mount it.

>  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?

Mounting the snapshot might be O(1), I don't know.

>  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.

Mounting the snapshot and rolling back the changes in the snapshot are
completely different operations.

>  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?

A snapshot is basically a copy of the filesystem, without the blocks
that haven't changed since the snapshot was made. So overwriting the
superblock won't cut it. If you don't want to copy the blocks from the
snapshot, you'll have to rewire the inodes for all files that have been
changed since the snapshot to use the saved blocks from the snapshot.

IMHO it would be safer to copy those blocks then to rewire the fs to use
the blocks in the snapshot. A bug in this rewiring code could seriously
screw up the filesystem. And it could lead to increased fragmentation.

>  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.

And how do you "tell the live filesystem where everything is" without
modifying inodes?

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20070527/deea1988/attachment.pgp