Date: Sun, 27 May 2007 11:01:53 -0400 From: "Maxim Khitrov" <mkhitrov@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: Restore UFS snapshot Message-ID: <26ddd1750705270801q7126f880q33f2c4a0fae4bfd0@mail.gmail.com> In-Reply-To: <20070527095635.GB57943@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> <26ddd1750705261608k68b2318ckca20be5889bc71fd@mail.gmail.com> <20070527095635.GB57943@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/27/07, Roland Smith <rsmith@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26ddd1750705270801q7126f880q33f2c4a0fae4bfd0>