From owner-freebsd-hackers Thu Apr 8 10:53:59 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133])
by hub.freebsd.org (Postfix) with ESMTP id 4FF7915AC4
for <hackers@FreeBSD.ORG>; Thu, 8 Apr 1999 10:53:33 -0700 (PDT)
(envelope-from bright@rush.net)
Received: from localhost (bright@localhost)
by cygnus.rush.net (8.9.3/8.9.3) with SMTP id NAA15266;
Thu, 8 Apr 1999 13:03:42 -0500 (EST)
Date: Thu, 8 Apr 1999 13:03:40 -0500 (EST)
From: Alfred Perlstein <bright@rush.net>
To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
Cc: hackers@FreeBSD.ORG
Subject: Re: Volume managers
In-Reply-To: <99Apr8.151534est.40342@border.alcanet.com.au>
Message-ID: <Pine.BSF.3.96.990408125020.4169i-100000@cygnus.rush.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Thu, 8 Apr 1999, 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).
If there was a way to stick a mapping vn under a FS it could be done.
Imagine a 'vn' device that was would start mapping blocks into itself
you configure said vn, enable it under ffs, ffs tried to write to
phys block 1000, the vn maps it into a file at location 1, then a
request comes in for block 100, the vn maps it to the underlying
block device, then a write comes in for it (block 100) it gets translated
to block 2. This would just be a MMU but for disks. When the vn is
"yanked out" it could just flush all blocks back the underlying real block
device.
in fact you don't really have to worry about shoving this vn between
FFs and the block device, you can make it a prereq that the admin set
it up beforehand.
other applications for this would be using it to do fast recoveries
if fsck can examine this log device and the log device was used for
a certain tolerance level until it overflowed and dumped back into
the real block device... you could examine the log and bring the
FS up COW asap. This would be a bit slow of course, but damn interesting
i think the original application for a FS snapshot is really cool though.
hmmmmm....
-Alfred
FFS FFS
| |
da0s1f mirvn
/ \
da0s1f logfile <- regular vn?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message