Re: no universally correct setting for fsync

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Tharp <gxti(at)partiallystapled(dot)com>, pgsql-hackers(at)postgresql(dot)org, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Subject: Re: no universally correct setting for fsync
Date: 2010-05-10 17:46:53
Message-ID: u2n407d949e1005101046weac382a6g99a5c932d4c5b736@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

On Mon, May 10, 2010 at 4:55 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> 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

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Joshua D. Drake 2010-05-10 18:42:57 Re: no universally correct setting for fsync
Previous Message Kevin Grittner 2010-05-10 15:55:40 Re: no universally correct setting for fsync

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-05-10 17:56:54 Re: "SET search_path" clause ignored during function creation
Previous Message Tom Lane 2010-05-10 16:49:43 Re: make install fails due to "/bin/mkdir: missing operand"