Date: Fri, 24 Apr 2009 09:32:16 -0400 From: Graham Todd <gtodd@bellanet.org> To: freebsd-fs@freebsd.org Subject: Re: UFS2 metadata checksums Message-ID: <49F1BF60.10106@bellanet.org> In-Reply-To: <20090424103252.GC1494@garage.freebsd.pl> References: <49F048FB.6000401@bqinternet.com> <20090423195335.521db0a7@kan.dnsalias.net> <49F10660.201@modulus.org> <49F1618E.3080208@bqinternet.com> <20090424103252.GC1494@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49F1BF60.10106>