From owner-freebsd-fs@FreeBSD.ORG Fri Apr 24 13:57:12 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AFB01065672 for ; Fri, 24 Apr 2009 13:57:12 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.freebsd.org (Postfix) with SMTP id 06E718FC0A for ; Fri, 24 Apr 2009 13:57:11 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: (qmail 78033 invoked from network); 24 Apr 2009 13:30:31 -0000 Received: from unknown (HELO wawanesa.iciti.ca) (gtodd@99.246.61.82 with login) by smtp100.rog.mail.re2.yahoo.com with SMTP; 24 Apr 2009 13:30:31 -0000 X-YMail-OSG: 7AoG_NcVM1lhzf1CV_2PZmTu9e8gcYfmGKQvh2Z8G1e6WWrvRI9M2h7eRbg8SwbF0g-- X-Yahoo-Newman-Property: ymail-3 Received: from wawanesa.iciti.ca (wawanesa.iciti.ca [192.168.2.4]) by wawanesa.iciti.ca (Postfix) with ESMTP id C79EB5B for ; Fri, 24 Apr 2009 09:32:17 -0400 (EDT) Message-ID: <49F1BF60.10106@bellanet.org> Date: Fri, 24 Apr 2009 09:32:16 -0400 From: Graham Todd User-Agent: Thunderbird 2.0.0.19 (X11/20090116) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <49F048FB.6000401@bqinternet.com> <20090423195335.521db0a7@kan.dnsalias.net> <49F10660.201@modulus.org> <49F1618E.3080208@bqinternet.com> <20090424103252.GC1494@garage.freebsd.pl> In-Reply-To: <20090424103252.GC1494@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: UFS2 metadata checksums X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 13:57:12 -0000 Pawel Jakub Dawidek wrote: > On Fri, Apr 24, 2009 at 02:51:58AM -0400, Scott Burns wrote: >> Andrew Snow wrote: >>> Ideally you would implement complete disk checksumming as a GEOM device. >>> >>> Then you could layer geom_mirror on top of it, so that if the checksum >>> fails and returns EIO, geom_mirror can try the alternate device and >>> rebuild the one with the bad checksums. >>> >>> That will then complete the feature set implemented by ZFS, but for any >>> filesystem on top of GEOM. >>> >>> - Andrew >>> >> The geli(8) GEOM class is able to verify sectors (and I believe it >> returns EINVAL on ones that fail), but with a noticeable performance >> impact. I could certainly see the use for a GEOM class that just does >> simple checksumming. If gmirror can then be aware of it, that does >> provide functionality similar to a ZFS mirror. > > Geli uses strong cryptography for integrity verification, which is not > needed in this case. The class that does that still needs to use > the method I implemented in geli to provide atomicity. > > Gmirror is already "aware" of that - in case of an error on one half, it > will use the other half. What gmirror doesn't do (and ZFS does) is > self-healing. > > All in all, in my opinion GEOM class is much better for this - it will > protect everything (metadata and data) and will be file system > idenpendent. As a sysadmin one could imagine some useful monitoring, auditing, security, reporting and "ITIL compliant" scripts/utilities that could be built around a geom_checksum class and "/sbin/gchecksum status". >From a performance perspective how "fine grained" could the checksum detail on a filesystem be for it to be practical to use in that way? Could such a geom class function like a builtin "tripwire" layer?