From: | "Graeme B(dot) Bell" <graeme(dot)bell(at)nibio(dot)no> |
---|---|
To: | "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi> |
Cc: | "Wes Vaske (wvaske)" <wvaske(at)micron(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: New server: SSD/RAID recommendations? |
Date: | 2015-07-07 19:59:54 |
Message-ID: | D0185D2A-A218-47D8-A798-2B92ABDCF4CF@skogoglandskap.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Cache flushing isn't an atomic operation though. Even if the ordering is right, you are likely to have a partial fsync on the disk when the lights go out - isn't your FS still corrupt?
On 07 Jul 2015, at 21:53, Heikki Linnakangas <hlinnaka(at)iki(dot)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 & replace fsync() with FLUSH CACHE, and the same question remains: When the drive breaks its promise wrt. FLUSH CACHE, does it nevertheless guarantee that the order the data is eventually flushed to disk is consistent with the order in which the 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 "your filesystem is corrupt".
>
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2015-07-07 20:05:06 | Re: New server: SSD/RAID recommendations? |
Previous Message | Heikki Linnakangas | 2015-07-07 19:53:21 | Re: New server: SSD/RAID recommendations? |