[ZODB-Dev] Use of fsync in FileStorage

[Toby Dickenson]

On Monday 26 July 2004 19:20, Neil Schemenauer wrote:

> > Replication alone wont help you here.... the damage caused by this defect 
> > might be undectable until its too late.
> 
> Huh?  As I understand it, ZODB does replication at the transaction
> level.  It's not simply synchronizing the underlying file.  Why
> doesn't that help?

The original poster argued that a power loss at the wrong time can corrupt a 
recent FileStorage transaction. When FileStorage next starts up it thinks 
that all the data is on disk and carries on as normal, yet the data is 
corrupt.

The presence of a replica doesnt prevent the application relying on that 
corrupt data.


> Also, why do you say the damage will be undetectable?  Unless there
> is a hardware failure, fsync has no visible effect.  If there is a
> hardware failure, then all bets are off anyhow. 

Unexpected power loss is a 'hardware failure' that I think most ZODB users 
would expect their storage to be able to survive. 

> > It was designed with a "zero safety compromises" policy - if you
> > need to never lose data then this may be a better option that
> > FileStorage.
> 
> If you need to never lose data then fsync() is not going to save
> you.  If you really care then you should have redundant hardware and
> replication.

Sure. fsync *alone* is not sufficient, and I didnt mean to imply that it was. 
But it is necessary.

-- 
Toby Dickenson