Date: Wed, 25 Jun 2008 15:59:59 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: "Peter T. Breuer" <ptb@inv.it.uc3m.es>
cc: Matthew Wakeling <matthew@flymine.org>, pgsql-performance@postgresql.org
Subject: Re: Hardware vs Software RAID
In-Reply-To: <200806251605.m5PG5Il07546@inv.it.uc3m.es>
Message-ID: <Pine.GSO.4.64.0806251222450.24017@westnet.com>
References: <200806251605.m5PG5Il07546@inv.it.uc3m.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 25 Jun 2008, Peter T. Breuer wrote:

> I refrained from saying in my reply that I would set up a firewire-based
> link to ram in a spare old portable (which comes with a battery) if I
> wanted to do this cheaply.

Maybe, but this is kind of a weird setup.  Not many people are going to 
run a production database that way and us wandering into the details too 
much risks confusing everybody else.

> The log is sync. Therefore it doesn't matter what the guarantees are, or 
> at least I assume you are worrying about acks coming back before the 
> write has been sent, etc.  Only an actual net write will be acked by the 
> firewire transport as far as I know.

That's exactly the issue; it's critical for database use that a disk not 
lie to you about writes being done if they're actually sitting in a cache 
somewhere.  (S)ATA disks do that, so you have to turn that off for them to 
be safe to use.  Since the firewire enclosure is a black box, it's 
difficult to know exactly what it's doing here, and history here says that 
every type (S)ATA disk does the wrong in the default case.  I expect that 
for any Firewire/USB device, if I write to the disk, then issue a fsync, 
it will return success from that once the data has been written to the 
disk's cache--which is crippling behavior from the database's perspective 
one day when you get a crash.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD