Hi hackers,
> > Can't we add some extra fork that stores this extra per-page
> > information, and contains this extra metadata
> >
> +1 for this approach. I had observed some painful corruption cases where block storage simply returned stale version
ofa rage of blocks. This is only possible because checksum is stored on the page itself.
That's very interesting, Andrey. Thanks for sharing.
> One of my questions is what algorithm(s) we'd want to support.
Should it necessarily be a fixed list? Why not support plugable algorithms?
An extension implementing a checksum algorithm is going to need:
- several hooks: check_page_after_reading, calc_checksum_before_writing
- register_checksum()/deregister_checksum()
- an API to save the checksums to a seperate fork
By knowing the block number and the hash size the extension knows
exactly where to look for the checksum in the fork.
--
Best regards,
Aleksander Alekseev
