From: | Karl Denninger <karl(at)denninger(dot)net> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Scott Carey <scott(at)richrelevance(dot)com>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: SSD + RAID |
Date: | 2009-11-19 14:44:58 |
Message-ID: | 4B0559EA.3010209@denninger.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Greg Smith wrote:
> Scott Carey wrote:
>> For your database DATA disks, leaving the write cache on is 100%
>> acceptable,
>> even with power loss, and without a RAID controller. And even in
>> high write
>> environments.
>>
>> That is what the XLOG is for, isn't it? That is where this behavior is
>> critical. But that has completely different performance requirements
>> and
>> need not bee on the same volume, array, or drive.
>>
> At checkpoint time, writes to the main data files are done that are
> followed by fsync calls to make sure those blocks have been written to
> disk. Those writes have exactly the same consistency requirements as
> the more frequent pg_xlog writes. If the drive ACKs the write, but
> it's not on physical disk yet, it's possible for the checkpoint to
> finish and the underlying pg_xlog segments needed to recover from a
> crash at that point to be deleted. The end of the checkpoint can wipe
> out many WAL segments, presuming they're not needed anymore because
> the data blocks they were intended to fix during recovery are now
> guaranteed to be on disk.
Guys, read that again.
IF THE DISK OR DRIVER ACK'S A FSYNC CALL THE WAL ENTRY IS LIKELY GONE,
AND YOU ARE SCREWED IF THE DATA IS NOT REALLY ON THE DISK.
-- Karl
Attachment | Content-Type | Size |
---|---|---|
karl.vcf | text/x-vcard | 124 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-11-19 14:49:08 | Re: SSD + RAID |
Previous Message | Greg Smith | 2009-11-19 14:44:36 | Re: SSD + RAID |