On Jul 14, 2010, at 7:50 PM, Ben Chobot wrote: > On Jul 14, 2010, at 6:57 PM, Scott Carey wrote: > >> But none of this explains why a 4-disk raid 10 is slower than a 1 disk system. If there is no write-back caching on the RAID, it should still be similar to the one disk setup. > > 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. > > Take away the controller, and most OS's by default enable the write cache on the drive. You can turn it off if you want, but if you know how to do that, then you're probably also the same kind of person that would have purchased a raid card with a BBU. Sure, or you can use an OS/File System combination that respects fsync() which will call the drive's write cache flush. There are some issues with certain file systems and barriers for file system metadata, but for the WAL log, we're only dalking about fdatasync() equivalency, which most file systems do just fine even with a drive's write cache on. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
