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

[Toby Dickenson]

On Wednesday 11 August 2004 10:21, shan sverige wrote:
> > [shan sverige]
> > > running 'fstest -v' gives only 1 error:
> > > time-stamp reduction at 31906881: 0x03537a82059cf1cc <= 
0x0355bcc95b5ace33
> 
> I ran fstest (including commenting out the lines Tim suggested) 
> and fsrefs and the above error was the ONLY one.
> Is there a way to resolve this ? even if it means converting
> to Directorystorage

My first thought was that expecting DirectoryStorage to fix this is as crazy 
as expecting 'packing' to fix anything.... but maybe its not.....

DirectoryStorage enforces ascending timestamps, but only really for 
FileStorage compatibility reasons.  It doesnt rely on that invariant for any 
purposes of its own.  You would need to remove the 'descending serial numbers 
in _begin' check in BaseDirectoryStorage.py during that conversion from 
FileStorage to DirectoryStorage.

Assuming you *want* to get back to FileStorage, you have two options:

1. Ensure that the rogue transactions all contain old revisions of all 
relevant objects, so that they will get removed by packing. Then convert the 
storage back to FileStorage. All should be well. (before that conversion back 
to FileStorage, run checkds.... it will report 'transaction file with 
backwards next-transaction pointer' if the damage has not been all removed.)

Its not pretty, but I cant see why it shouldnt work.

or,

2. Recently Ive been thinking about DirectoryStorage to 'arbitrary storage' 
conversion options when for use when the DirectoryStorage has mild damage. 
(DirectoryStorage's fault tolerance features mean it can usually carry on 
working mostly normally after some types of corruption). One nice option is 
to scrape out the current revision of every object into a fresh new storage. 
You lose all the history, but purge all historic corruption too. No 
implementation yet, but Im open to sponsorship or patches.

A third option of course is to stick with DirectoryStorage at that point. 
checkds will give you the 'transaction file with backwards next-transaction 
pointer' warning, but you can ignore that. (Waaah - its a hard error not a 
warning at the moment. To be fixed in the next version)

> converting to reiserFS

Shouldnt be necessary, provided you have enough free disk space that you dont 
need its space efficiency advantages.


-- 
Toby Dickenson