Re: [Zope] HELP - POSKeyError 000000000001efcd - Data.fs corruption
BZ wrote:
Any pointers on getting rid of said corruption? Tools? Fixes? Potions?
Did you try re-indexing everything your ZCatalog as I suggested? cheers, Chris
Hey Chris, Thanks for helping me on on this one. I looked all over and I know how to reindex a catalog, but how do you reindex an entire site or zope installation? BZ On Thursday, March 20, 2003, at 04:46 AM, Chris Withers wrote:
BZ wrote:
Any pointers on getting rid of said corruption? Tools? Fixes? Potions?
Did you try re-indexing everything your ZCatalog as I suggested?
cheers,
Chris
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Do we want this crossposted to zope@ and zodb-dev@ ?] On Thursday 20 March 2003 12:21 pm, BZ wrote:
Hey Chris,
Thanks for helping me on on this one.
I looked all over and I know how to reindex a catalog, but how do you reindex an entire site or zope installation?
I think chris is guessing that your zodb corruption is limited to a dangling reference inside the zcatalog btree, so that reindexing the *catalog* followed by a pack will purge all traces of the corruption. Chris, can you share how you reached this? He might be correct. good luck. ;-) You also reported:
119583146L object serialno 0x034aab9e4b7e624c does not matchtransaction id 0x034ac5e367948900
That sounds like more than a single dangling reference :-( It raises one question for me - did this data start out in this FileStorage? Or, has it been passed through a copyTransactionsFrom function, or something else that call the restore() storage method? Tracking down corruption in FileStorage is hard - both tracking down the type of corruption so you can repair it, and tracking down the bug that caused it initially. Doing anything more scientific than following Chris' guess will require you to go through a debugging process. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
[I posted to zodb-dev as I was told they were the GURUs and could help since this is in the ZODB). What I have tried: 1) Using fsrecover.py (with and without -p and before and after packing) This has removed data but along with it a lot of data that I need. If you don't use the -p it removes nothing and I am stuck with the POSKeyError 2) Exporting the folder I think is corrupt (/Members/) and importing it into a new CMF. It imports, but the POSKeyError comes with (in a new location) 3) Deleting things out of the folder that could be causing the problem Gives me lots of errors about not being able to "unindex" the items followed by a POSKeyError in debug mode: "ERROR(200) PathIndex Attempt to unindex document with id xxxxxxxxx failed" Any new direction would be appreciated. The problem with hosing the darn /Members/ folder is that it has Members stuff in it. BZ
[Do we want this crossposted to zope@ and zodb-dev@ ?]
On Thursday 20 March 2003 12:21 pm, BZ wrote:
Hey Chris,
Thanks for helping me on on this one.
I looked all over and I know how to reindex a catalog, but how do you reindex an entire site or zope installation?
I think chris is guessing that your zodb corruption is limited to a dangling reference inside the zcatalog btree, so that reindexing the *catalog* followed by a pack will purge all traces of the corruption. Chris, can you share how you reached this?
He might be correct. good luck. ;-)
You also reported:
119583146L object serialno 0x034aab9e4b7e624c does not matchtransaction id 0x034ac5e367948900
That sounds like more than a single dangling reference :-(
It raises one question for me - did this data start out in this FileStorage? Or, has it been passed through a copyTransactionsFrom function, or something else that call the restore() storage method?
Tracking down corruption in FileStorage is hard - both tracking down the type of corruption so you can repair it, and tracking down the bug that caused it initially. Doing anything more scientific than following Chris' guess will require you to go through a debugging process.
-- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
_______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
On Thursday 20 March 2003 1:38 pm, BZ wrote:
[I posted to zodb-dev as I was told they were the GURUs and could help since this is in the ZODB).
What I have tried: 1) Using fsrecover.py (with and without -p and before and after packing)
This has removed data but along with it a lot of data that I need. If you don't use the -p it removes nothing and I am stuck with the POSKeyError
fsrecover works on the FileStorage record structure. It wont do anything to mitigate POSKeyErrors, but you shouldnt see errors like this one after running it. Please shout if this is not the case for you.
You also reported:
119583146L object serialno 0x034aab9e4b7e624c does not matchtransaction id 0x034ac5e367948900
2) Exporting the folder I think is corrupt (/Members/) and importing it into a new CMF.
It imports, but the POSKeyError comes with (in a new location)
Dont think that this means it is creating more corruption. Things stop when it hits the first POSKeyError, so you *might* just have two missing objects and they are being hit in a different order. Do you get most of the /Members content working with this process? If so, your problem is not as hard as it could be. You just need to find the objects that have dangling references, then either reconstruct the referenced object, or delete the object that contains the dangling reference. There is an fsrefs.py script that might help. (Ive never used it, but it looks good.)
Any new direction would be appreciated. The problem with hosing the darn /Members/ folder is that it has Members stuff in it.
When this immediate problem is resolved you may want to look at DirectoryStorage. I developed it after suffering this kind of debuggability problems in other storages. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Toby Dickenson wrote:
I think chris is guessing that your zodb corruption is limited to a dangling reference inside the zcatalog btree, so that reindexing the *catalog* followed by a pack will purge all traces of the corruption. Chris, can you share how you reached this?
Past experience with edge-case BTree bugs. rebuilding the BTree seemed to clear the problem sometimes. No real evidence, mind :-S cheers, Chris
participants (3)
-
BZ -
Chris Withers -
Toby Dickenson