On Fri, Apr 4, 2014 at 1:18 PM, John R Pierce <pierce@xxxxxxxxxxxx> wrote: > On 4/4/2014 12:08 PM, Scott Marlowe wrote: >> >> You don't technically need the BBU / flashback memory IF the >> controller is in write through. > > > if you HAVE the BBU/flash why would you put the controller in write > through?? the whole POINT of bbu/flashback is that you can safely enable > writeback caching. > > my testing with postgresql OLTP benchmarks on Linux, I've found virtually > identical performance using mdraid vs hardware raid in the same caching > mode. its the writeback cache that gives raid cards like the LSI Megaraid > SAS2 series, or HP P420, or whatever, their big advantage vs a straight JBOD > configuration. I'm not sure you read / got the whole conversation. The OP was asking if he COULD use a RAID controller with no BBU in write through with SSDs. It's a valid question. My main point was in answer to this response: On Fri, Apr 4, 2014 at 11:15 AM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Fri, Apr 4, 2014 at 11:04 AM, Steve Crawford >> 2. Do I need both BBU on the RAID *and* capacitor on the SSD or just on one? >> Which one? I'm suspecting capacitor on the SSD and write-through on the >> RAID. > > You need both. The capacitor protects the drive, the BBU protects the > raid controller. Context is king here. You do not have to have a BBU as long as you are in write through as the OP mentioned. With no BBU, in write-through, with supercaps, you should be safe. It's not a sensible configuration for most applications. OTOH, most HW RAIDs have auto spare promotion and easy swap out of dead drives with auto-rebuild. So if you're building 1000 units for the government that just plug in and work, you want the poor guy on the other end to just unplug bad drives and replace them. The cost of a service call could be way more than a HW RAID card. So, there are plenty of reasons you might want to test or even run without a BBU. That wasn't my point. My point was you're SAFE (or should be) with a HW RAID no BBU and supercapped SSDs. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
