[ZODB-Dev] Use of fsync in FileStorage

[Tim Peters]

[Shane Hathaway]
> I would expect fsync to make a big difference.  fsync waits for the disk
> to write everything currently pending to disk.  Disks without a battery
> backup have to seek in order to sync reliably, and since seek time is a
> few milliseconds, it's easy to see why a box would be limited to 100-200
> fsyncs per second, regardless of the processor speed.

Indeed, 5ms seek time is very good.  Jeremy and I ran seek timing tests a
year ago (or a decade, or last week -- it's hard to remember), and 5ms was
the best real-life sustainable seek time we found on any disk tested.  Most
were closer to 10ms, some worse.  There was some reason to suspect that seek
times degrade as files grow to many GB too.  On NTFS I can pin this on
fragmentation (.fs files fragment quickly on NTFS -- the small 7MB .fs
created by my last test driver run is sprayed across 24 fragments, and this
on a disk with 58GB free and that was wholly defragmented just yesterday!).

> I don't like the way Zope behaves with respect to the disk.  It churns
> the disk before responding to the browser; no other program I use is so
> paranoid. Why bother?  When I actually care about the data Zope is
> storing, I use a UPS.  Does fsync provide any benefit that a UPS doesn't?

Frequent use of fsync() probably cuts the time you have to wait until your
disk fails, and there's nothing as effective as the resulting crisis to pry
some upgrade money loose from your management <wink>.

OK, as Toby said, a UPS can also fail.  I'm more of a "life is full of murky
tradeoffs" guy.  But from this tension is born an endless list of config
options nobody understands, so it's not all bad ...