public inbox for [email protected]  

help / color / mirror / Atom feed

From: Greg Stark <[email protected]>
To: Kevin Grittner <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Michael Tharp <[email protected]>
Cc: [email protected]
Cc: Craig Ringer <[email protected]>
Subject: Re: no universally correct setting for fsync
Date: Mon, 10 May 2010 18:46:53 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Mon, May 10, 2010 at 4:55 PM, Kevin Grittner
<[email protected]> wrote:
> Robert Haas <[email protected]> wrote:
>
>> "It might be safe" is a bit of a waffle.  It would be nice if we
>> could provide some more clear guidance as to whether it is or is
>> not, or how someone could go about testing their hardware to find
>> out.
>
> I think that the issue is that you could have corruption if some,
> but not all, disk sectors from a page were written from OS cache to
> controller cache when a failure occurred.  The window would be small
> for a RAM-to-RAM write, but it wouldn't be entirely *safe* unless
> there's some OS/driver environment where you could count on all the
> sectors making it or none of them making it for every single page.
> Does such an environment exist?

The reason for the waffle is that the following sentence describes a
whole set of environments based the following description:

> > ? ? ? ?if you have hardware (such as a battery-backed
> > ? ? ? ?disk controller) or file-system software that reduces the risk
> > ? ? ? ?of partial page writes to an acceptably low level

Depending on which set of hardware and how low the risk is it might be safe.

I think with WAFL or ZFS it's entirely safe. There may be other
filesystems with similar guarantees. With a BBU the risk might be very
low -- but it might not, it would be hard to determine without a
detailed analysis of the entire stack from the buffer cache,
filesystem, lvm, hardware drivers, BBU design, etc.

-- 
greg

view thread (35+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: no universally correct setting for fsync
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox