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. 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)
Description: PGP signature