On Jul 15, 2010, at 12:35 PM, Ben Chobot wrote:
> On Jul 15, 2010, at 9:30 AM, Scott Carey wrote:
>
>>> Many raid controllers are smart enough to always turn off write caching on the drives, and also disable the feature
ontheir own buffer without a BBU. Add a BBU, and the cache on the controller starts getting used, but *not* the cache
onthe drives.
>>
>> This does not make sense.
>> Write caching on all hard drives in the last decade are safe because they support a write cache flush command
properly. If the card is "smart" it would issue the drive's write cache flush command to fulfill an fsync() or barrier
requestwith no BBU.
>
> You're missing the point. If the power dies suddenly, there's no time to flush any cache anywhere. That's the entire
pointof the BBU - it keeps the RAM powered up on the raid card. It doesn't keep the disks spinning long enough to flush
caches.
If the power dies suddenly, then the data that is in the OS RAM will also be lost. What about that?
Well it doesn't matter because the DB is only relying on data being persisted to disk that it thinks has been persisted
todisk via fsync().
The data in the disk cache is the same thing as RAM. As long as fsync() works _properly_ which is true for any file
system+ disk combination with a damn (not HFS+ on OSX, not FAT, not a few other things), then it will tell the drive to
flushits cache _before_ fsync() returns. There is NO REASON for a raid card to turn off a drive cache unless it does
nottrust the drive cache. In write-through mode, it should not return to the OS with a fsync, direct write, or other
"theOS thinks this data is persisted now" call until it has flushed the disk cache. That does not mean it has to turn
offthe disk cache.
