after crash: abort: 00changelog.i at ...: no mode

[Hudes, Dana]

 you don't have this filesystem consistency problem with ZFS. It's a
database that thinks it's a filesystem. If a transaction to the FS
doesn't completely commit, its rolled back. No fsck, ever. Hardware
failures (esp. when the SAN teams does stuff to the Fiber channel switch
so that you lose connection to your storage even though it's still
running) can require a zfs scrub to resynch RAID plexes and get the
uncompleted transactions rolled back but this is at the zpool level not
an individual filesystem.

-----Original Message-----
From: mercurial-bounces at selenic.com
[mailto:mercurial-bounces at selenic.com] On Behalf Of Lasse Kliemann
Sent: Sunday, August 16, 2009 10:33 AM
To: mercurial at selenic.com
Subject: after crash: abort: 00changelog.i at ...: no mode

I did some crash tests running 'hg ci' on a large changeset and pulling
the plug or switching off the computer during the process. Then I power
the system back on, replay the log or run fsck and then see in which
state the repository is. The goal was mainly to compare JFS to EXT3 on
Linux.

So far, EXT3 is clearly my favorite. (See last comment on this
below.)

With JFS, for instance, I am once again at a point where the repository
seems to be dysfunctional beyond repair. It says:

$ hg ci
abort: 00changelog.i at f79dae14506d: no mode!

$ hg st
about: working directory has unknown parent 'f79dae14506d'!

$ hg recover
no interrupted transaction available

What do you think? Can this only be the result of a filesystem bug, or
could it be that Mercurial is doing something wrong or did do something
wrong? 

Can this condition be resolved manually?

(With EXT3, on most occasions, 'hg recover' gives back a working
repository. In a few cases, also with EXT3 I got damaged repositories
comparable to the condition shown above; but that was with Mercurial
1.3.0, now I use 1.3.1. I has no problems to recover from a crash with
EXT3 and Mercurial 1.3.1. so far.)