From owner-freebsd-geom@FreeBSD.ORG Fri Dec 12 15:50:27 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 342D410656A9 for ; Fri, 12 Dec 2008 15:50:27 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id BA5C58FC45 for ; Fri, 12 Dec 2008 15:50:26 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 82749 invoked by uid 2001); 12 Dec 2008 15:50:23 -0000 Date: Fri, 12 Dec 2008 09:50:23 -0600 From: "Rick C. Petty" To: Ulf Lilleengen Message-ID: <20081212155023.GA82667@keira.kiwi-computer.com> References: <4940FF0F.2020404@field.hu> <20081211205659.GA72478@keira.kiwi-computer.com> <49419680.4010003@field.hu> <20081212040137.GA76422@keira.kiwi-computer.com> <20081212083708.GA1455@carrot.studby.ntnu.no> <20081212130848.GB39875@carrot.studby.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212130848.GB39875@carrot.studby.ntnu.no> User-Agent: Mutt/1.4.2.3i Cc: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Encrypting raid5 volume with geli X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2008 15:50:27 -0000 On Fri, Dec 12, 2008 at 02:08:49PM +0100, Ulf Lilleengen wrote: > > > > It doesn't have to be "weird" behaviour, depending on whether gvinum > > checks parity on reads (does it?). If it does, it will only have to > > ignore checksum errors in this case. > It does check parity on reads. But I think it doesn't matter, since no sane data > has been written in that block anyway. > > But as you say, one way to handle it is to ignore the checksums if the data > is known to not be initialized, but then wouldn't one have to keep track of > which blocks have a valid parity and which who does not? IMO, trying to read a block that hasn't been initialized is perfectly acceptable as an "error". I would just mark the volume as up. Chances are a sane admin would be writing to the blocks before reading the same blocks (except in the disk test scenario, in which case why are they bothering with a raid5?). If a read happens on a block that hasn't been written to, it is a parity error. The real question is what happens when parity errors happen. I guess I suggest allowing you to force the plex up (via setstate) if you are pretty confident reads will only happen after writes (which is the case after newfs-ing the volume). In either case, always mark the volume as up.. the plex can be in a degraded state, meaning the parity has failed but reads can still happen. It sounds perfect to me; the states reflect the actual state of things. -- Rick C. Petty