From: | Shane Wright <shane(dot)wright(at)edigitalresearch(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | mount -o async - is it safe? |
Date: | 2006-01-19 09:42:59 |
Message-ID: | 200601190942.59864.shane.wright@edigitalresearch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
We've recently set up our database (7.4.9) with our new hosting provider.
We have two database servers running RHEL 4 in a cluster; one active and
one hot-spare. They share a [fibre-channel connected] SAN partition; the
active server has it mounted.
Now my question is this; the provider has, by default, mounted it with -o
sync; so all reads/writes are synchronous. This doesn't result in the
greatest of performance, and indeed remounting -o async is significantly
faster.
They tell me this is so mySQL databases don't get corrupted in the event of
a crash. which is fine...
But as Postgres uses fsync() to force committed transactions to disk, then
this shouldn't be necessary, right?
(I know this is based on the assumption the SAN doesn't lie about its syncs,
but then surely it would lie to the kernel with -o sync anyway?)
If we turn sync off, surely PostgreSQL keeps the data consistent, ext3
journalling keeps the filesystem clean [assuming other mount options left at
defaults], and then everything should be ok with either a server crash, power
failure, storage failure, whatever. right?
I've googled and come up with some info; the most relevant of
which is here:
http://archives.postgresql.org/pgsql-general/2003-11/msg01515.php
http://archives.postgresql.org/pgsql-general/2003-11/msg01592.php
If anyone can confirm either way that'd be great - or even just point me in
the direction of enough firm info to work it out myself ;)
Thanks,
Shane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-01-19 09:58:44 | Re: mount -o async - is it safe? |
Previous Message | Martijn van Oosterhout | 2006-01-19 09:05:14 | Re: Surrogate keys (Was: enums) |