UFS2 metadata checksums

[Graham Todd]

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?