Date: Sun, 27 May 2007 11:56:35 +0200 From: Roland Smith <rsmith@xs4all.nl> To: Maxim Khitrov <mkhitrov@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Restore UFS snapshot Message-ID: <20070527095635.GB57943@slackbox.xs4all.nl> In-Reply-To: <26ddd1750705261608k68b2318ckca20be5889bc71fd@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 =A78.7 of McKusick's book, or the paper he wrote about it; http://www.usenix.org/publications/library/proceedings/usenix99/mckusick.ht= ml=20 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.=20 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.=20 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.=20 > 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 --=20 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) --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGWVXTEnfvsMMhpyURAmo3AJ9bJHI4sxQ21Ce/Q8iYzet/ljflBwCfZL2m PpjYvooEo9UQlfbHwoQVMeE= =aoVR -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070527095635.GB57943>