Re: file system and raid performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bruce Momjian wrote:
> Mark Mielke wrote:
>> 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. :-)
> 
> I have documented this in the WAL section of the manual, which seemed
> like the most logical location.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 

Ah, but shouldn't a PostgreSQL (or any other database, for that matter)
have its own set of filesystems tuned to the application's I/O patterns?
Sure, there are some people who need to have all of their eggs in one
basket because they can't afford multiple baskets. For them, maybe the
OS defaults are the right choice. But if you're building a
database-specific server, you can optimize the I/O for that.

-- 
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM

"A mathematician is a device for turning coffee into theorems." --
Alfréd Rényi via Paul Erdős


-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux