Re: New server: SSD/RAID recommendations?
От | Graeme B. Bell |
---|---|
Тема | Re: New server: SSD/RAID recommendations? |
Дата | |
Msg-id | D0185D2A-A218-47D8-A798-2B92ABDCF4CF@skogoglandskap.no обсуждение исходный текст |
Ответ на | Re: New server: SSD/RAID recommendations? (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: New server: SSD/RAID recommendations?
|
Список | pgsql-performance |
Cache flushing isn't an atomic operation though. Even if the ordering is right, you are likely to have a partial fsync onthe disk when the lights go out - isn't your FS still corrupt? On 07 Jul 2015, at 21:53, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > On 07/07/2015 09:01 PM, Wes Vaske (wvaske) wrote: > > Right, to be precise, the problem isn't the drive lies about fsync(). It lies about FLUSH CACHE instead. Search & replacefsync() with FLUSH CACHE, and the same question remains: When the drive breaks its promise wrt. FLUSH CACHE, doesit nevertheless guarantee that the order the data is eventually flushed to disk is consistent with the order in whichthe data and FLUSH CACHE were sent to the drive? That's an important distinction, because it makes the difference between"the most recent data the application saved might be lost even though the FLUSH CACHE command returned" and "yourfilesystem is corrupt". >
В списке pgsql-performance по дате отправления: