-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/02/12 11:35, Nico Williams wrote: > Indeed, but if you'd do integrity protection at the application layer > then surely you'd have have a backup/restore strategy to deal with > lower-layer corruption.
Only if you know about that corruption! It is perfectly possible for stray zeroes to be written into the btrees in such a way that they are still considered valid, but you have effectively amputated a row. > Yes, this tends to argue that if you want row-level checksums My point is that they are fairly useless since they only work if btrees and indices work perfectly. Anything that could affect rows could also affect the other pieces of information SQLite is storing. > However, if you're going to have SQLite3 do it Note that SQLite already has a way of reserving space on a per page basis. It is currently used by the encryption extension. It is possible to store a checksum there instead which would still be readable but not writeable by older versions of SQLite. Since the btree pages would also have checksums things should work in most scenarios. Any solution would be better than the current no solution, especially as checksums let you discover corruption early. > Well, one can hope. (I don't keep up with btrfs; perhaps it will > mature and become common on Android devices.) Approximately zero percent of SQLite databases will be on btrfs for the foreseeable future, even if you and I start using btrfs. Android 3 and above do support encrypting the filesystem which effectively gives you a lot of the checksumming, although filesystem implementations tend to care far more about metadata than file contents. Windows 8 server will be coming with a filesystem that does integrity checking. However again approximately zero percent of SQLite databases will be stored on that filesystem for the foreseeable future. http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx SQLite having its own checksumming will solve the integrity issues today, for hundreds of millions of users, especially when developers consider data very important. It will also solve some of the corruption issue finger pointing - if a page has a correct checksum but SQLite considers the contents corrupt then the most likely explanation is a bug in SQLite, while an invalid checksum points to the contents being different than what SQLite wrote hence points fingers at the operating system and storage. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8wN6oACgkQmOOfHg372QTDnACgmHiKBZ43TbYlVGPRxN5a9UF5 uGkAoIbjVsjuA7IuATyC/0M2IDDE6IJN =o4lD -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
