>>>>> "JW" == Joachim Werner <[EMAIL PROTECTED]> 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 ;-).
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -