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 of a 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
