Re: File Systems Compared
От | Jim Nasby |
---|---|
Тема | Re: File Systems Compared |
Дата | |
Msg-id | FB83EA45-E67F-45EA-9F90-F1F075FA93A6@decibel.org обсуждение исходный текст |
Ответ на | Re: File Systems Compared (Bruno Wolff III <bruno@wolff.to>) |
Ответы |
Re: File Systems Compared
|
Список | 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.lewis@mir3.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@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
В списке pgsql-performance по дате отправления: