From owner-freebsd-questions@FreeBSD.ORG Sat May 26 23:08:32 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E685016A468 for ; Sat, 26 May 2007 23:08:32 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by mx1.freebsd.org (Postfix) with ESMTP id A495D13C45B for ; Sat, 26 May 2007 23:08:32 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: by nz-out-0506.google.com with SMTP id 14so121945nzn for ; Sat, 26 May 2007 16:08:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F9iomretPeJMRCFAMcfmOe/DbhchewfYVfO6yJFXn4AdE8iQqV1xWKW1I/sIEawJH/IeYh5vZnFDGmQ5cea9PgvaRuYkuDQjdeD4lXy3sNBEubTSWEKVNbuHqa9j6/JAQevFOfAiZlePQu/H7NyEKwfUM+oQqeeJI6DeGpBSJ8Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jItjF8XkV9vvCQRtEKVHY8V3K7WvDcaxDj32EINF69gpniAToiPSamRuebl7xsXbFmnJ03KGrgonaqG1KDnJIdQtHolbggfMZ/Dp7gt0imIOCIOrLnwqV61QmosiTZy6WjDQhwEm35nILSMRq/UJloUAMbsRjonNzeI7s2pM7UM= Received: by 10.143.31.4 with SMTP id i4mr118554wfj.1180220911604; Sat, 26 May 2007 16:08:31 -0700 (PDT) Received: by 10.143.37.14 with HTTP; Sat, 26 May 2007 16:08:31 -0700 (PDT) Message-ID: <26ddd1750705261608k68b2318ckca20be5889bc71fd@mail.gmail.com> Date: Sat, 26 May 2007 19:08:31 -0400 From: "Maxim Khitrov" To: freebsd-questions@freebsd.org In-Reply-To: <20070526223143.GA42141@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Subject: Re: Restore UFS snapshot X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2007 23:08:33 -0000 On 5/26/07, Roland Smith wrote: > On Sat, May 26, 2007 at 11:59:13PM +0200, Svein Halvor Halvorsen wrote: > > Roland Smith wrote: > > > You could use rsync instead of tar. That would save time. > > > > I'm not talking about saving time. But saving CPU time and HDD > > stress. However, the disk space issue is a bigger one: > > rsync would do much less writing than tar. So it would save on "HDD > stress", whatever that is. > > > >> (b) Undo all the bit flipping I have done, since I made the snapshot. > > > > > > This is what the procedure above does if you replace the tar commands > > > with rsync. > > > > No, because the snapshot will still be in use, and hence all its > > bits will be kept intact and read-only. When I use rsync/tar/cpio or > > whatever to "undo" changes to a file system, I will in reality copy > > these bits to different places on the disk. And until I release the > > snapshot (which I very well could, since it would defunct after the > > restore process), I will use twice the amount of disk space. > > You can't restore a previous situation _unless you saved it in some > form_. So if you want a possibility to restore stuff, you'll have to > keep a copy of it somewhere. Maybe in compressed form, and maybe you can > clump changes together in a smart way, but you have to save the bits > that you change. > > Every revision control system (which is effectively what you ask for) uses > storage space to keep previous versions of data, although the precise > method used for this varies. 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. 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. This is different from simply copying the contents of the snapshot back to the disk via an md device. 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. Personally, I think this an entirely reasonable thing to do, and I myself would like to see this kind of functionality. Right now, however, I don't think that it is possible.