Whit Armstrong wrote:
> But there is no such risk to turning off write barriers?
Supposedly not:
http://xfs.org/index.php/XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.3F
> Did you get a substantial performace boost from disabling write
> barriers?
Thanks.
But there is no such risk to turning off write barriers?
I'm only specifying noatime for xfs at the moment.
Did you get a substantial performace boost from disabling write
barriers? like 10x or more like 2x?
Thanks,
Whit
On Tue, Jul 27, 2010 at 1:19 PM, Kevin Grittner
wrote:
> "Kev
"Kevin Grittner" wrote:
> Basically, you should never use fsync unless you are OK with
> losing everything in the database server if you have an OS or
> hardware failure.
s/use/disable/
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
Whit Armstrong wrote:
> While we're on the topic, do you also diable fsync?
We only disable fsync during bulk loads, where we would be starting
over anyway if there was a failure. Basically, you should never use
fsync unless you are OK with losing everything in the database
server if you have
Kevin,
While we're on the topic, do you also diable fsync?
We use xfs with battery-backed raid as well. We have had no issues with xfs.
I'm curious whether anyone can comment on his experience (good or bad)
using xfs/battery-backed-cache/fsync=off.
Thanks,
Whit
On Tue, Jul 27, 2010 at 9:48 A
Mark Kirkwood wrote:
> Also xfs has seen quite a bit of development in these later
> kernels, any thoughts on that?
We've been using xfs for a few years now with good performance and
no problems other than needing to disable write barriers to get good
performance out of our battery-backed RAID
