[no subject]

005.l1D05rpF034888@apollo.backplane.com>
From: Emil Mikulic <emikulic@dmr.ath.cx>
Subject: Re: Plans for 1.8+ (2.0?)
Date: Tue, 13 Feb 2007 11:59:41 +1100
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=us-ascii
Content-Disposition: inline
In-Reply-To: <200702130005.l1D05rpF034888@apollo.backplane.com>
Sender: kernel-errors@crater.dragonflybsd.org
Errors-To: kernel-errors@crater.dragonflybsd.org
Lines: 12
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1171328605 crater_reader.dragonflybsd.org 832 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:10583

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?