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 on their own buffer without a BBU. Add a BBU, and the cache on the controller starts getting used, but *not* the cache on the 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 request with 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 point of 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 to disk 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 flush its cache _before_ fsync() returns. There is NO REASON for a raid card to turn off a drive cache unless it does not trust the drive cache. In write-through mode, it should not return to the OS with a fsync, direct write, or other "the OS thinks this data is persisted now" call until it has flushed the disk cache. That does not mean it has to turn off the disk cache. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
