Re: Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery - Mailing list pgsql-general

From Greg Smith
Subject Re: Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery
Date
Msg-id Pine.GSO.4.64.0708221613130.26829@westnet.com
Whole thread Raw
In response to Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery  ("Dmitry Koterov" <dmitry@koterov.ru>)
Responses Re: Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery  ("Dmitry Koterov" <dmitry@koterov.ru>)
List pgsql-general
On Wed, 22 Aug 2007, Dmitry Koterov wrote:

> I have written a small perl script to check how slow is fsync for Smart
> Array E200i controller. Theoretically, because of write cache, fsync MUST
> cost nothing, but in practice it is not true

That theory is fundamentally flawed; you don't know what else is in the
operating system write cache in front of what you're trying to fsync, and
you also don't know exactly what's in the controller's cache when you
start.  For all you know, the controller might be filled with cached reads
and refuse to kick all of them out.  This is a complicated area where
tests are much more useful than trying to predict the behavior.

You haven't mentioned any details yet about the operating system you're
running on; Solaris?  Guessing from the device name.  There have been some
comments passing by lately about the write caching behavior not being
turned on by default in that operating system.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

pgsql-general by date:

Previous
From: "Ivan Zolotukhin"
Date:
Subject: Re: How to switch off Snowball stemmer for tsearch2?
Next
From: Matthew
Date:
Subject: Geographic High-Availability/Replication