From: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Understanding fsync |
Date: | 2008-06-19 11:11:34 |
Message-ID: | 20080619111134.GO2572@frubble.xen.chris-lamb.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Jun 19, 2008 at 08:56:20AM +0800, Craig Ringer 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.
Hum that's a fun one! I've also just realized my original statement
was wrong---I combined device and filesystem snapshotting together
inappropriately.
I think users should care about fsync precisely when they care about the
underlying block device being in a consistent state. This applies to
the normal case that people worry about of power loss, as well as the
case of block level backups and modern filesystems that maintain a lot
of state independently of the OS's buffer cache. To summarize, fsync
can be turned off when the user is unconcerned with power loss and when
backups are always performed at the filesystem level.
Sam
From | Date | Subject | |
---|---|---|---|
Next Message | Volkan YAZICI | 2008-06-19 11:27:03 | Logging Parameter Values |
Previous Message | Karsten Hilbert | 2008-06-19 10:26:09 | Re: Inter-app communication via DB |