Am 14.04.2010, 14:45 Uhr, schrieb Hanno Schlichting <>:

> Usually you will only loose the last transaction and not a days of
> work. The Data.fs is an append-only file, with one transaction
> appended after another. If there's a garbled or incomplete write,
> you'll typically loose the last transaction. The ZODB is smart enough
> to detect broken transactions and skip them on restart.
> I have witnessed one ZEO installation myself, where the physical
> machine hosting the ZEO server restarted multiple times a day, over a
> period of months. Nobody noticed for a long time, as the application
> was accessible all the time and no data had been lost. Obviously this
> wasn't a very write-intense application. But it still showed me how
> stable the ZODB really is.

Yes, I agree with your opinion in general.

There's still a chance that broken transactions are written IIUC (see ):

>> Doesn't this mean that if the system suddenly crashes in the middle of
>> os.fsync, the Data.fs on disk will contain an incomplete transaction,  
>> but
>> the transaction status byte would claim that the transaction is  
>> complete.
>> Wouldn't that be bad?
> If that happened, perhaps.

The chance exists because fsync does not work as advertised on many  
systems. On the systems where it seems to work, the slowdown is massive.  
So I am doubting the usefulness of using fsync in current ZODB at all.

As your observations seem to hint, it's probably very unlikely to  
encounter this problem in practice. And I doubt Tim finally got Jim to pay  
him for a 48 hour pull-the-plug session :-) That's why I am not going to  
dig further into this and am satisfied with the current reliability.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to