Restore UFS snapshot

[Ian Smith]

On Sun, 27 May 2007 11:01:53 -0400 Maxim Khitrov <mkhitrov at gmail.com> wrote:
 > 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

Interesting thread.  I've only read the PDF referred to there, namely
http://www.usenix.org/publications/library/proceedings/usenix99/full_papers/mckusick/mckusick.pdf
several times, and particularly the snapshot section from p.15 of that,
and I'm almost beginning to get it, but can't claim more than that ..

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

I share Roland's concern about the reliability of any new code designed
to accomplish the 'full rollback' desired, but of course anything would
have to undergo incredibly rigorous testing before it would be allowed
anywhere near even -CURRENT I'm sure, same as softupdates/snapshots has. 

That said, I think it is worthwhile finding out whether this is even
possible with the amount of data and metadata saved in snapshots to
accomplish their existing utility (which I still find pretty awesome,
and despite re-reading that section again several times, mysterious ..)

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

I guess contacting Marshall McKusick might be the quickest way to find
out whether there's sufficient metadata available to do that; he'd know
off the top of his head, I'm sure.  So should several other people, I
guess, but more likely those frequenting -fs, -hackers, maybe -arch? 
 
 > 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.

It may even be possible, assuming restoration of a filesystem to its
state in a snapshot is possible at all, to first save all subsequent
changes in its present state to another snapshot, or a snapshot-like
thing, to allow 'rollforward' again, perhaps .. that would be cute.

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

I don't know, which is why I suggest asking the bloke who would :)

Cheers, Ian