No subject

Unknown Unknown
Mon Feb 12 17:55:23 PST 2007

005.l1D05rpF034888 at> <20070213005941.GD68703 at>
From: "Matt Emmerton" <matt at>
Subject: Re: Plans for 1.8+ (2.0?)
Date: Mon, 12 Feb 2007 20:49:36 -0500
List-Post: <mailto:kernel at>
List-Subscribe: <mailto:kernel-request at>
List-Unsubscribe: <mailto:kernel-request at>
List-Help: <mailto:kernel-request at>
List-Owner: <mailto:owner-kernel at>
MIME-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Sender: kernel-errors at
Errors-To: kernel-errors at
Lines: 20
X-Trace: 1171331816 833
Xref: 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

More information about the Kernel mailing list