[Zope-dev] Corrupt Data.fs: Is there a way of fixing transaction ids?

[Jeremy Hylton]

>>>>> "JW" == Joachim Werner <joe@iuveno.de> writes:

  JW> Hi!  I have a really large Data.fs file (1.3 GB) that has a
  JW> number of errors.  When I run the fstest.py script, I get this:

  JW> Problem: 109963117 object serialno 0x034573c4b6a2cb6e does not
  JW> match transaction id 0x034573c55c8c0dbb

  JW> How can I fix the Data.fs file? It should be possible to scan
  JW> the Data.fs and create correct serialnos or transaction ids for
  JW> the broken entries. But how exactly would I do that?

  JW> I'd also like to identify the corrupt entries (i.e. find out the
  JW> Zope object they belong to) to be able to eliminate them.

I'd start by running fsdump.py and identifying what transaction and
objects are affected by this problem.  fsdump will display transaction
metadata (like time) and oid & class for each object.

  JW> My ultimate question is how these corrupt entries can exist at
  JW> all. The Data.fs hit the 2 GB border once. So that could be a
  JW> reason. But even then it would be really nice for the ZODB to
  JW> not write corrupt entries ...

I agree that ZODB should not write the corrupt entries.  It's
possible, of course, that it didn't.  It's certainly possible for
bit-rot to strike a Data.fs, although it seems odd that the only
manifestation of a disk failure would be a mismatch between object
serialno and transaction id.

I might be able to help more by looking at the actual Data.fs.  Are
you in a position to share it?  (I can be discrete ;-).

Jeremy