[no subject]

005.l1D05rpF034888@apollo.backplane.com> <20070213005941.GD68703@dmr.ath.cx>
From: "Matt Emmerton" <matt@gsicomp.on.ca>
Subject: Re: Plans for 1.8+ (2.0?)
Date: Mon, 12 Feb 2007 20:49:36 -0500
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:kernel@crater.dragonflybsd.org>
List-Subscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:kernel-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:kernel-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-kernel@crater.dragonflybsd.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 20
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1171331816 crater_reader.dragonflybsd.org 833 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:10586

> On Mon, Feb 12, 2007 at 04:05:53PM -0800, Matthew Dillon wrote:
> > [...]
> >
> > However, for robustness we would not mirror them in actual fact but
> > would instead assign dynamic block numbers (i.e. non-linear
> > addressing) every time a bit of data is flushed to physical storage,
> > allowing the data chunks to hold a complete historical record, which
> > in turn not only allows virtually infinite snapshots but also allows
> > just one of the redundant chunks to be written and for the other ones
> > to be updated asynchronously.
>
> With the infinite snapshots scheme, how does one reclaim space?

With virtually infinite drive space :)  Realistically, though, you'd have to
have some kind of mechanism to determine how many snapshots exist for a
particular file and then some kind of tool to remove old snapshot versions.

--
Matt Emmerton