pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Greg Smith <greg@2ndquadrant.com>
To: Jesper Krogh <jesper@krogh.cc>
Cc: pgsql-performance@postgresql.org
Subject: Re: 3ware vs. MegaRAID
Date: Fri, 09 Apr 2010 14:22:20 -0400
Message-ID: <4BBF705C.6060601@2ndquadrant.com> (raw)
In-Reply-To: <4BBF51B6.8070307@krogh.cc>
References: <4BB1FAAF.7050406@wp.pl>
	<4BB23254.2040109@2ndquadrant.com>
	<4BBB662C.8030102@wp.pl>
	<23D26E38-9852-4EB6-9DF9-FCB2EAE1EE6C@richrelevance.com>
	<x2jca24673e1004072044hac4475e8g3a3fefdcda6ebefe@mail.gmail.com>
	<4BBECA06.40602@krogh.cc>
	<4BBF477A.4080701@2ndquadrant.com>
	<4BBF51B6.8070307@krogh.cc>

Jesper Krogh wrote:
> I've spent quite some hours googling today. Am I totally wrong if the:
> HP MSA-20/30/70 and Sun Oracle J4200's:
> https://shop.sun.com/store/product/53a01251-2fce-11dc-9482-080020a9ed93
> are of the same type just from "major" vendors.

Yes, those are the same type of implementation.  Every vendor has their 
own preferred way to handle port expansion, and most are somewhat scared 
about discussing the whole thing now because EMC has a ridiculous patent 
on the whole idea[1].  They all work the same from the user perspective, 
albeit sometimes with their own particular daisy chaining rules.

> That would enable me to reuse the existing server and moving to something
> like Intel's X25-M 160GB disks with just a higher amount (25) in a 
> MSA-70.

I guess, but note that several of us here consider Intel's SSDs 
unsuitable for critical database use.  There are some rare but not 
impossible to encounter problems with its write caching implementation 
that leave you exposed to database corruption if there's a nasty power 
interruption.  Can't get rid of the problem without destroying both 
performance and longevity of the drive[2][3].  If you're going to deploy 
something using those drives, please make sure you're using an 
aggressive real-time backup scheme such as log shipping in order to 
minimize your chance of catastrophic data loss.

[1] http://www.freepatentsonline.com/7624206.html
[2] 
http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-fsync-write-cache-barrier-and-lost-transa...
[3] 
http://petereisentraut.blogspot.com/2009/07/solid-state-drive-benchmarks-and-write.html

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us




view thread (16+ messages)  latest in thread

Message-ID: <4BBF705C.6060601@2ndquadrant.com>
Permalink:  ../4BBF705C.6060601@2ndquadrant.com/
Also on:    postgresql.org/message-id/4BBF705C.6060601@2ndquadrant.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: greg@2ndquadrant.com, jesper@krogh.cc
  Subject: Re: 3ware vs. MegaRAID
  In-Reply-To: <4BBF705C.6060601@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox