On 5/11/2012 3:16 AM, Daniel Pocock wrote: > My understanding of BBWC: > > - for things like an NFS server, where the OS and disk hardware can't > cache write data very aggressively (due to the contract between NFS > client and server), the BBWC allows you to enable more aggressive > behavior (e.g. setting barrier=0 on the filesystem level) and gain a > speed boost RAID cache works just like CPU L2 cache. In this case it's a buffer between the system block layer and the physical storage. It can speed up reads and writes. In the case of writes, it can be configured to return success to the block layer before it actually writes the data to disk, speeding up random write IO tremendously in many cases. > - on the other hand, is BBWC universally effective? E.g. does it just > write to disk in a crash scenario, or only in the event of an outright > power failure? Does it depend on any hints from the OS or drivers to > know about system state? You're concentrating here specifically on the "B" aspect, which is the battery. It protects you from power failure and system crashes that cause a reset of the motherboard. When the card is back up, it's firmware being executed, it checks that the drives are all up, then writes the data in the cache to the target sectors of the drives. It's worked this way for over a decade. > This is my main point - the fact that md RAID is hardware independent, > e.g. I can swap from HP to IBM servers and use the same disks. > > If I wanted more than RAID1 (e.g. RAID6) maybe I would re-evaluate the > issue, but for RAID1, a software solution seems fine. That's the one scenario where I abhor using md raid, as I mentioned. At least, a boot raid 1 pair. Using layered md raid 1 + 0, or 1 + linear is a great solution for many workloads. Ask me why I say raid 1 + 0 instead of raid 10. -- Stan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
