Skip site navigation (1) Skip section navigation (2)

Re: File Systems Compared

From: Jim Nasby <decibel(at)decibel(dot)org>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>, Brian Wipf <brian(at)clickspace(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: File Systems Compared
Date: 2006-12-14 06:39:00
Message-ID: FB83EA45-E67F-45EA-9F90-F1F075FA93A6@decibel.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Dec 11, 2006, at 12:54 PM, Bruno Wolff III wrote:
> On Wed, Dec 06, 2006 at 08:55:14 -0800,
>   Mark Lewis <mark(dot)lewis(at)mir3(dot)com> wrote:
>>> Anyone run their RAIDs with disk caches enabled, or is this akin to
>>> having fsync off?
>>
>> Disk write caches are basically always akin to having fsync off.  The
>> only time a write-cache is (more or less) safe to enable is when  
>> it is
>> backed by a battery or in some other way made non-volatile.
>>
>> So a RAID controller with a battery-backed write cache can enable its
>> own write cache, but can't safely enable the write-caches on the disk
>> drives it manages.
>
> This appears to be changing under Linux. Recent kernels have write  
> barriers
> implemented using cache flush commands (which some drives ignore,  
> so you
> need to be careful). In very recent kernels, software raid using  
> raid 1
> will also handle write barriers. To get this feature, you are  
> supposed to
> mount ext3 file systems with the barrier=1 option. For other file  
> systems,
> the parameter may need to be different.

But would that actually provide a meaningful benefit? When you  
COMMIT, the WAL data must hit non-volatile storage of some kind,  
which without a BBU or something similar, means hitting the platter.  
So I don't see how enabling the disk cache will help, unless of  
course it's ignoring fsync.

Now, I have heard something about drives using their stored  
rotational energy to flush out the cache... but I tend to suspect  
urban legend there...
--
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)



In response to

Responses

pgsql-performance by date

Next:From: RonDate: 2006-12-14 06:45:29
Subject: Re: New to PostgreSQL, performance considerations
Previous:From: Michael GlaesemannDate: 2006-12-14 06:11:11
Subject: Re: New to PostgreSQL, performance considerations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group