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@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
