Re: Understanding fsync

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Understanding fsync
Date: 2008-06-19 00:56:20
Message-ID: 4859AEB4.7070406@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2008-06-19 01:30:17 Re: migrating from mysql: need to convert empty string to null
Previous Message Albretch Mueller 2008-06-19 00:44:17 HA best pratices with postgreSQL