Date: Sun, 27 May 2007 18:19:02 +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: <20070527161902.GA70148@slackbox.xs4all.nl> In-Reply-To: <26ddd1750705270801q7126f880q33f2c4a0fae4bfd0@mail.gmail.com> References: <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> <26ddd1750705270801q7126f880q33f2c4a0fae4bfd0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > Wait a sec, when you mount a snapshot as a memory disk, does that > memory disk contain the snapshot as well?=20 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 --=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) --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFGWa92EnfvsMMhpyURAg65AJ0UJZhOVVJ+YS5l37rzSYjjBTR4vgCgmaeC fo2enHUJ1xD5UgaQSxwnN2I= =Zrlw -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070527161902.GA70148>