Re: Understanding fsync - Mailing list pgsql-general

From Craig Ringer
Subject Re: Understanding fsync
Date
Msg-id 4859AEB4.7070406@postnewspapers.com.au
Whole thread Raw
In response to Re: Understanding fsync (was: Need Help Recovering from Botched Upgrade Attempt)  (Sam Mason <sam@samason.me.uk>)
Responses Re: Understanding fsync  (Sam Mason <sam@samason.me.uk>)
List pgsql-general
Sam Mason wrote:

> My original note was mainly in response to Craig's comment that implied
> fsync doing far more than it actually does.  I remember seeing a few
> comments recently saying similar things about fsync, so sorry for
> picking specifically on you Craig.  Device/filesystem level snapshotting
> is exactly what's needed and is independent of any fsync settings.

Good point. I guess fsync would only matter for certain if you were
using snapshots on shared storage (a SAN or similar) where the current
host's view of the yet-to-be-flushed-to-storage FS state is not known.

The main snapshot system I use is LVM, which takes a snapshot of the
block device underlying the file system. It's not actually filesystem
level at all, but volume/block level. I'm just not sure whether
filesystems like ext3 and the underlying Linux VFS will always pass
blocks written by applications through to the block layer immediately
and in order. After all, they do have tricks like delayed allocation
that I'd expect to result in data not being passed to the file system.
If they don't always pass writes to the block layer in the order they're
issued then fsync would also be significant for LVM snapshots. Any idea?

ext3's data=ordered refers to data being written before metadata, not
the order in which different data write requests are processed, so
that's no help.

--
Craig Ringer

pgsql-general by date:

Previous
From: "Albretch Mueller"
Date:
Subject: HA best pratices with postgreSQL
Next
From: Tom Lane
Date:
Subject: Re: migrating from mysql: need to convert empty string to null