Re: file system and raid performance

mark@mark.mielke.cc

From: Mark Mielke <mark@mark.mielke.cc>
To: Greg Smith <gsmith@gregsmith.com>
Cc: Bruce Momjian <bruce@momjian.us>, Mark Wong <markwkm@gmail.com>, pgsql-performance@postgresql.org
Date: 2008-08-16T15:01:31Z
Lists: pgsql-performance
Greg Smith wrote:
> On Fri, 15 Aug 2008, Bruce Momjian wrote:
>> 'data=writeback' is the recommended mount method for that file 
>> system, though I see that is not mentioned in our official 
>> documentation.
> While writeback has good performance characteristics, I don't know 
> that I'd go so far as to support making that an official 
> recommendation.  The integrity guarantees of that journaling mode are 
> pretty weak.  Sure the database itself should be fine; it's got the 
> WAL as a backup if the filesytem loses some recently written bits.  
> But I'd hate to see somebody switch to that mount option on this 
> project's recommendation only to find some other files got corrupted 
> on a power loss because of writeback's limited journalling.  ext3 has 
> plenty of problem already without picking its least safe mode, and 
> recommending writeback would need a carefully written warning to that 
> effect.

To contrast - not recommending it means that most people unaware will be 
running with a less effective mode, and they will base their performance 
measurements on this less effective mode.

Perhaps the documentation should only state that "With ext3, 
data=writeback is the recommended mode for PostgreSQL. PostgreSQL 
performs its own journalling of data and does not require the additional 
guarantees provided by the more conservative ext3 modes. However, if the 
file system is used for any purpose other than PostregSQL database 
storage, the data integrity requirements of these other purposes must be 
considered on their own."

Personally, I use data=writeback for most purposes, but use data=journal 
for /mail and /home. In these cases, I find even the default ext3 mode 
to be fewer guarantees than I am comfortable with. :-)

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>