[ZODB-Dev] Use of fsync in FileStorage

[Neil Schemenauer]

On Mon, Jul 26, 2004 at 12:10:31PM +0100, Toby Dickenson wrote:
> [...] second fsync is covering a change to only a single byte, and
> all modern hardware can do that atomically.

I don't believe that.  Haven't you ever heard storage people say that
everything is a lie?

> > If you need reliability it's probably better to go with replicated
> > storage.
> 
> 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?

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.  However, since file
storage is append only, it should be possible to recover it.

If the damage is going to be undetectable then I don't see how
adding fsync calls is going to fix it so that it is detectable.

> 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.

FWIW, I've added an fsync() call to the Durus FileStorage
implementation.  It shouldn't hurt performance and might make people
feel better.

 Neil