[ZODB-Dev] Use of fsync in FileStorage
Toby Dickenson
tdickenson at devmail.geminidataloggers.co.uk
Mon Jul 26 16:07:41 EDT 2004
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
More information about the ZODB-Dev
mailing list