Hello Anthony,
Anthony Edward Cooper wrote:
One question I was asked at work yesterday... What happens if a
database gets corrupted due to an underlying hardware failure and the
user, not knowing this, syncs his database? Not such a stupid
question as I have had situations where drivers don't report disk
errors, you just get weird behaviour (e.g. IDE disks under Solaris).
We are not bothered about the one corrupted database - just that
corruption spreading.
Monotone is pretty strong in ensuring consistency. Most probably, the
user on the box with disk failures would notice way before syncing.
AFAICT mtn does not do excessive checks on 'mtn status' for
performance reasons. But at least on commit, it quite certainly checks
for validity of the parent revision.
A quick example, which does not prove anything:
address@hidden:/home/markus# mtn -d test.db setup test -b test
address@hidden:/home/markus# cd test
address@hidden:/home/markus/test# mtn add fileA
mtn: adding fileA to workspace manifest
address@hidden:/home/markus/test# mtn commit -m "initial import"
mtn: beginning commit on branch 'test'
mtn: committed revision 072fe56e02d71c686e9ff1139004497b370b40ea
address@hidden:/home/markus/test# mtn status
Current branch: test
Changes against parent 072fe56e02d71c686e9ff1139004497b370b40ea
no changes
address@hidden:/home/markus/test# ls -lha ../test.db
-rw-r--r-- 1 markus markus 288K 2007-09-20 11:18 ../test.db
# okay, at that point I've set up a quick test repository, which
# weights 288kb. I'm now going to manually 'corrupt' one single
# byte somewhere in the middle of the file:
address@hidden:/home/markus/test# dd if=/dev/random of=../test.db
seek=144000 bs=1 count=1
1+0 records in
1+0 records out
1 byte (1 B) copied, 6.6073e-05 seconds, 15.1 kB/s
address@hidden:/home/markus/test# mtn status
Current branch: test
Changes against parent 072fe56e02d71c686e9ff1139004497b370b40ea
no changes
# 'mtn status' didn't notice. Now let's try to change a test
# file and commit a new revision.
address@hidden:/home/markus/test# echo "aoeu" >> fileA
address@hidden:/home/markus/test# mtn status
Current branch: test
Changes against parent 072fe56e02d71c686e9ff1139004497b370b40ea
patched fileA
# 'mtn status' still didn't notice, it simply sees the modification
address@hidden:/home/markus/test# mtn commit
mtn: error: sqlite error: SQL logic error or missing database
mtn: error: make sure database and containing directory are writeable
mtn: error: and you have not run out of disk space
# 'mtn commit' clearly failed. While this looks like SQLite already
# complains, because I have corrupted it's internal data structures,
# and not real monotone data, I'm pretty sure monotone would notice
# other corruptions as well.
However, rest assured that during a sync, both nodes re-check the
revisions they get from the other one. This is absolutely necessary in
such a distributed system, so that corruptions aren't propagated around.
Regards
Markus