From owner-freebsd-questions@FreeBSD.ORG Mon Nov 8 20:44:30 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E46D5106566B for ; Mon, 8 Nov 2010 20:44:30 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id C0AB58FC15 for ; Mon, 8 Nov 2010 20:44:30 +0000 (UTC) Received: by pxi1 with SMTP id 1so1233054pxi.13 for ; Mon, 08 Nov 2010 12:44:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.192.76 with SMTP id dp12mr5648056qcb.63.1289249069544; Mon, 08 Nov 2010 12:44:29 -0800 (PST) Received: by 10.229.41.68 with HTTP; Mon, 8 Nov 2010 12:44:29 -0800 (PST) X-Originating-IP: [93.203.53.39] In-Reply-To: <20101108183821.GA48373@slackbox.erewhon.net> References: <20101106203016.GB13095@guilt.hydra> <20101106213836.GA77198@slackbox.erewhon.net> <4CD8194D.7080208@qeng-ho.org> <4CD82081.50309@stillbilde.net> <20101108183821.GA48373@slackbox.erewhon.net> Date: Mon, 8 Nov 2010 21:44:29 +0100 Message-ID: From: "C. P. Ghost" To: Roland Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: "Svein Skogen \(Listmail account\)" , freebsd-questions@freebsd.org Subject: Re: ZFS License and Future X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 20:44:31 -0000 On Mon, Nov 8, 2010 at 7:38 PM, Roland Smith wrote: > On Mon, Nov 08, 2010 at 05:08:33PM +0100, Svein Skogen (Listmail account) wrote: >> But it's still not capable of true forward-error-correction. If we are >> to embark upon creating a new solution, using something that is cheap >> for "normal cases" but can still be used (albeit more expensively) for >> error recovery would (imho) be better. Even if that means we get less >> net storage out of the gross pool (it could perhaps be configurable?) > > I'm not sure what you mean by "true forward-error-correction". But if you want > to make _really sure_ that a spinning disk hasn't mangled the data you should: Maybe something like Reed-Solomon ECC in different blocks. Should a data block go bad, it could be rebuilt on-the-fly from those ECC blocks: http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction http://www.eccpage.com/ -cpghost. -- Cordula's Web. http://www.cordula.ws/