Hi Tom,
> > If we turn sync off, surely PostgreSQL keeps the data consistent, ext3
> > journalling keeps the filesystem clean [assuming other mount options
> > left at defaults], and then everything should be ok with either a server
> > crash, power failure, storage failure, whatever. right?
>
> I checked around with some of Red Hat's kernel folk, and the bottom line
> seems to be that it's OK as long as you trust the hardware:
fabulous, thanks :)
> :> Question is, can fsync(2) be trusted to behave properly, ie, not return
> :> until all writes are down to disk, if the SAN is mounted -o async ?
> :
> : async is the default, which is the whole point of having things like
> : fsync, fdatasync, O_DIRECT, etc. You can trust fsync as far as you can
> : trust the hardware. The call will not return until the SAN says the
> : data has been written.
> :
> : In reality, the SAN is probably buffering these writes (possibly into
> : SRAM or battery-backed RAM), and the disks are probably buffering them
> : again, but you've got redundant power supplies and UPSs, right?
that sounds true (and it has) - but presumably this is the case whether we
mount -o sync or not? I.e. if its going to buffer, then its going to do so
whether its postgres or the kernel sync'ing the writes?
(specifically that the SAN likely buffers anyway - IMO having to trust the
hardware to some degree is a given ;)
Cheers
Shane