[ZODB-Dev] Re: Can't pack ZODB anymore

[aku at europe.com]

tried copyTransactionsFrom() method Tim suggested, started with an empty Data.fs (good)
and copied all the transactions from my existing Data.fs (bad). Full of hope I ran fstest
on the new Undamaged.fs, but unfortunately: time-stamp error :(
I looked at the code in copyTransactionsFrom(), but don't know enough about ZODB to check
whether that code is correct.

BTW: The reason for the system clock going backwards is simple: I ran an old trial version of
Vmware that was expired. I therefore had to set the clock backwards a couple of months. 
After a day or so, I restored the system clock.

I guess I could try fsrecover.py now, even though I loose (hopefully only a few days) of data ?

Shan


----- Original Message -----
From: "Tim Peters" <tim at zope.com>
Date: Thu, 12 Aug 2004 17:03:03 -0400
To: "'Dieter Maurer'" <dieter at handshake.de>,"'shan sverige'" <aku at europe.com>
Subject: RE: [ZODB-Dev] Re: Can't pack ZODB anymore

> [shan sverige, with at least one out-of-order tid]
> 
> [Dieter Maurer]
> > Maybe, its "fsrecover" does?
> 
> I strongly recommend he try that only if the copyTransactionsFrom() method I
> explained before doesn't work for him.  fsrecover "repairs" out-of-order
> tids, but does so by throwing away transactions until it finds a larger tid
> again.  That's extreme.  Since Shan's system clock disagreed with reality by
> months, there's no guessing how much data that will throw away.  The
> copyTransactionsFrom() gimmick doesn't throw any transactions away; instead
> it "makes up" new tids for the out-of-order ones.
> 
> The only clear use for fsrecover I've heard of so far is to truncate a
> FileStorage after a system crash -- but ZODB will usually do that by magic
> when you next open the .fs file anyway.
> 
> Dieter, have you used fsrecover successfully for something fancier than just
> that?  I've been asking around informally, and "truncate after crash" is all
> I've heard.  In cases of bad-HW-induced .fs corruption, fsrecover never
> seems to help in reality (for good reason:  it may need to throw away most
> of the file, and doesn't have a chance of repairing corrupt bytes inside
> object pickles anyway -- there's no substitute for good backups!).
> 

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm