Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Date
Msg-id 20180417211953.GA13097@momjian.us
Whole thread Raw
In response to Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS  (Greg Stark <stark@mit.edu>)
Responses Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
List pgsql-hackers
On Tue, Apr 10, 2018 at 05:54:40PM +0100, Greg Stark wrote:
> On 10 April 2018 at 02:59, Craig Ringer <craig@2ndquadrant.com> wrote:
> 
> > Nitpick: In most cases the kernel reserves disk space immediately,
> > before returning from write(). NFS seems to be the main exception
> > here.
> 
> I'm kind of puzzled by this. Surely NFS servers store the data in the
> filesystem using write(2) or the in-kernel equivalent? So if the
> server is backed by a filesystem where write(2) preallocates space
> surely the NFS server must behave as if it'spreallocating as well? I
> would expect NFS to provide basically the same set of possible
> failures as the underlying filesystem (as long as you don't enable
> nosync of course).

I don't think the write is _sent_ to the NFS at the time of the write,
so while the NFS side would reserve the space, it might get the write
request until after we return write success to the process.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


pgsql-hackers by date:

Previous
From: Jonathan Rudenberg
Date:
Subject: Re: [sqlsmith] Unpinning error in parallel worker
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS