From owner-freebsd-hackers Thu Apr 8 17:27:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 6E612156CE for ; Thu, 8 Apr 1999 17:27:25 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA22797; Fri, 9 Apr 1999 09:55:24 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA24022; Fri, 9 Apr 1999 09:55:22 +0930 (CST) Message-ID: <19990409095522.O2142@lemis.com> Date: Fri, 9 Apr 1999 09:55:22 +0930 From: Greg Lehey To: Peter Jeremy , hackers@FreeBSD.ORG Subject: Re: Volume managers References: <99Apr8.151534est.40342@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <99Apr8.151534est.40342@border.alcanet.com.au>; from Peter Jeremy on Thu, Apr 08, 1999 at 03:28:40PM +1000 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 8 April 1999 at 15:28:40 +1000, Peter Jeremy wrote: > Whilst we're all making up wishlists for things we'd like to see > (someone else implement): The `clone filesystem' command supported by > Digital UNIX ADVfs is _very_ nice for `point-in-time' backups. > (Basically clonefset makes a read-only snapshot of the filesystem - > changes to the `active' filesystem are done using copy-on-write). > > Unfortunately, I suspect it couldn't be implemented within UFS > (because UFS relies on blocks being at particular physical locations > within a CG - ie superblock, array of inode blocks, data blocks - > which would make creating the copy-on-write blocks difficult). I've seen the follow-up to this, but I haven't analysed it yet. Anyway, this is one of the things that I have been planning, and it's pretty simple. I take a "snapshot" of a volume in a detached plex. This plex is so different in structure from other plexes that I might look for a different name, but I believe Veritas calls it a plex. Instead of the plex data, it is initially empty. Every time a block in the volume is updated, the before image is written to the snapshot plex. Reading the snapshot plex first checks to see if it contains a before image for the area. If it does, it supplies it; otherwise the data in the volume hasn't changed, so it supplies the data from the volume. Since this works at a block level, there's no problem with whatever data you want to freeze in this manner. And no, it hasn't been implemented; that's why I'm vague on some of the details. The main problem is yet another layer of "where do I get this byte from?". Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message