On Thu, 4 Sep 2008, Thomas Finneid wrote:
> I am unsure if I need a journal in the fs or if the db covers that problem.
There are some theoretical cases where the guarantees of ext3 seems a
little weak unless you've turned the full journal on even in a database
context (we just had a long thread on this last month; see
http://archives.postgresql.org/pgsql-performance/2008-08/msg00136.php for
the part that dives into this subject). In practice, the "ordered" mode
(the default for ext3) seems sufficient to prevent database corruption.
There is a substantial performance hit to running in full journal mode
like you're doing;
http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/
shows ordered mode as nearly 3X faster.
You should always do your own stress testing on your hardware anyway,
including a few rounds of powering off the server abruptly and making sure
it recovers from that.
> With regards to that, do I then need to set some linux setting to force inode
> syncing (dont rememver the name for the filesystem structure in unix memory).
> The same question can be asked about the async option.
In the default mode, the database speaks to the filesystem in terms of
writes followed by fsync, which forces both the data and associated
metadata out. It works similarly if you switch to sync writes.
PostgreSQL is very precise about what data really needs to be written to
disk and what can sit in the cache until later, you shouldn't need to
worry about the sync parts at the filesystem level (as long as said
filesystem implementation is sane).
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
