Fixed - Re: Versions problem in 2.6.1
This is in relation to the thread referred to in the subject: http://mail.zope.org/pipermail/zope/2003-February/131336.html We recently came across this same problem, and after a bit of digging I've got it fixed (for us at least). What I did was comment out the break at around line 576 in ZODB/FileStorage.py. This break was added between versions 2.6.0 and 2.6.1. For grepping purposes, here's a copy of the break and its preceeding comment: # Once we've found the data we are looking for, # we can stop chasing backpointers. break Just comment out that break and all should be good to go. I've attached a Hotfix style patch for the lazy. :) -- John Eikenberry [jae@kavi.com] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
Forgot to mention. I added this to the Zope bugtracker. Number 817. http://collector.zope.org/Zope/817 -- John Eikenberry [jae@kavi.com] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
John Eikenberry wrote:
This is in relation to the thread referred to in the subject:
http://mail.zope.org/pipermail/zope/2003-February/131336.html
We recently came across this same problem, and after a bit of digging I've got it fixed (for us at least).
What I did was comment out the break at around line 576 in ZODB/FileStorage.py. This break was added between versions 2.6.0 and 2.6.1. For grepping purposes, here's a copy of the break and its preceeding comment:
# Once we've found the data we are looking for, # we can stop chasing backpointers. break
Just comment out that break and all should be good to go.
Hi John, I've tried your fix, but unfortunately it didn't fix my problems with versions. After some time using versions my Data.fs gets corrupt (happens with Zope 2.5.1 and Zope 2.6.1). So just one question, did you ever try to run lib/python/ZODB/fsrecover.py on your Data.fs (be aware of overwriting your Data.fs if you haven't used fsrecover.py before)? Even if I only do one change to a DTML Document using a version and save the version afterwards, I always get a: ZODB.POSException.VersionLockError: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x00T'", '/Test Version') from fsrecover.py. I only get rid of this kind of error by packing the database in the database control panel or by exporting and importing my application. Thanks, Stefan -- Stefan Loidl Phone: +49 89 289 28882 Leibniz Supercomputing Center Fax: +49 89 2809460 Barer Str. 21 mailto:loidl@lrz.de 80333 Munich, Germany http://www.lrz.de
Stefan Loidl wrote:
I've tried your fix, but unfortunately it didn't fix my problems with versions. After some time using versions my Data.fs gets corrupt (happens with Zope 2.5.1 and Zope 2.6.1).
We didn't see the problem with versions until we ran into the problem of the versions not being saved in 2.6.1. My "fix" made it so that they do get saved, but you're right it doesn't fix the corruption problem you note below. You don't mention (but you've probably seen it) that after the first appearance of this corruption additional version based changes not only give this error, but also result in multiple 'bad transaction length' errors. Eg. __main__.ErrorFound: bad transaction length at 5095413 Have you experienced any problems with actually using the site after this corruption occurs? So far I only see that its happened by running fsrecover.py, otherwise the sites work as they should. I'm going to look into it some, as would be quite bad if it interfears with content delivery. We don't use versions internally, but use them in our custom client content editing code. Its a feature that several of our clients use, so we can't just disable it. :P Are you still looking into this and/or have you submitted it to the bugtracker?
So just one question, did you ever try to run lib/python/ZODB/fsrecover.py on your Data.fs (be aware of overwriting your Data.fs if you haven't used fsrecover.py before)? Even if I only do one change to a DTML Document using a version and save the version afterwards, I always get a: ZODB.POSException.VersionLockError: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x00T'", '/Test Version') from fsrecover.py.
I only get rid of this kind of error by packing the database in the database control panel or by exporting and importing my application.
Note that this is only of limited help as it only works when all versions have been committed. If you pack with open versions it also currupts the database. We've seen this internally, and its been mentioned on zodb-dev: http://mail.zope.org/pipermail/zodb-dev/2002-April/002540.html -- John Eikenberry [jae@kavi.com] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin
John Eikenberry wrote:
Stefan Loidl wrote:
I've tried your fix, but unfortunately it didn't fix my problems with versions. After some time using versions my Data.fs gets corrupt (happens with Zope 2.5.1 and Zope 2.6.1).
We didn't see the problem with versions until we ran into the problem of the versions not being saved in 2.6.1. My "fix" made it so that they do get saved, but you're right it doesn't fix the corruption problem you note below.
You don't mention (but you've probably seen it) that after the first appearance of this corruption additional version based changes not only give this error, but also result in multiple 'bad transaction length' errors. Eg.
__main__.ErrorFound: bad transaction length at 5095413
Have you experienced any problems with actually using the site after this corruption occurs? So far I only see that its happened by running fsrecover.py, otherwise the sites work as they should
Yes, two times so far. Each time after I had done quite a lot of changes in a version (don't know the exact number, but may be more than 30 changes in different Zope objects) over a longer period of time (> 1 month). One time it was no more possible to access a folder (even in the ZMI) in which changed objects were. I was only able to repair the problem by using a backup of Data.fs an exporting/importing the application.
I'm going to look into it some, as would be quite bad if it interfears with content delivery. We don't use versions internally, but use them in our custom client content editing code. Its a feature that several of our clients use, so we can't just disable it. :P
Are you still looking into this and/or have you submitted it to the bugtracker?
I'm currently not looking into this, I just don't use versions any more because we are only two developers, so working versions would be useful for us but not essential. We have currently restrained to using production and development instances of zope. I haven't submitted this to bugtracker yet.
So just one question, did you ever try to run lib/python/ZODB/fsrecover.py on your Data.fs (be aware of overwriting your Data.fs if you haven't used fsrecover.py before)? Even if I only do one change to a DTML Document using a version and save the version afterwards, I always get a: ZODB.POSException.VersionLockError: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x00T'", '/Test Version') from fsrecover.py.
I only get rid of this kind of error by packing the database in the database control panel or by exporting and importing my application.
Note that this is only of limited help as it only works when all versions have been committed. If you pack with open versions it also currupts the database. We've seen this internally, and its been mentioned on zodb-dev:
http://mail.zope.org/pipermail/zodb-dev/2002-April/002540.html
Thanks for the hint. Stefan -- Stefan Loidl Phone: +49 89 289 28882 Leibniz Supercomputing Center Fax: +49 89 2809460 Barer Str. 21 mailto:loidl@lrz.de 80333 Munich, Germany http://www.lrz.de
On Mon, Feb 24, 2003 at 10:58:44AM +0100, Stefan Loidl wrote:
You don't mention (but you've probably seen it) that after the first appearance of this corruption additional version based changes not only give this error, but also result in multiple 'bad transaction length' errors. Eg.
__main__.ErrorFound: bad transaction length at 5095413
REALLY now. that is very interesting. i have a zodb that suffered *thousands* of "bad transaction length" and we have never determined the root cause. However, I know that before I was hired: * some work was done in versions * there was some big data-loss disaster related to versions * somebody managed to recover what they needed * it was decreed "we will use no more versions" ;-) * the zodb was never packed ... they just didn't know to do that :-\ I was only able to fix the problems by using fsrecover.py with the -P -t 0 options. I wonder now if there was some lingering version corruption... -- Paul Winkler http://www.slinkp.com
participants (3)
-
John Eikenberry -
Paul Winkler -
Stefan Loidl