Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 00C95633750 for ; Wed, 24 Feb 2010 04:32:54 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 66290-03 for ; Wed, 24 Feb 2010 08:32:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ww0-f46.google.com (mail-ww0-f46.google.com [74.125.82.46]) by mail.postgresql.org (Postfix) with ESMTP id 1813C6332E2 for ; Wed, 24 Feb 2010 04:32:41 -0400 (AST) Received: by wwf26 with SMTP id 26so1178179wwf.19 for ; Wed, 24 Feb 2010 00:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2yVyOkPE887jL5PJZpfZLUOLHpxucDpZ4mjUqW/aSMg=; b=Ki60eEfObcR+tqmA9BvRPT3kHm7Mky8C9TSv25dawYth5x87UMPHpXcEFWSJFJqiNt xj76zg4kUUZSeNO0qfm5r8OqZ/mpIgkICD/6MB/ReWsCQ63cW8fzq5uEft+AnidkwlcH 2Vi4KnoejyF1N9xZCHDGSmh42xuti177BJSAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dXIWzf0RvsvvTHHj/AGZYd7SvB5OkWx04goiFS3WTemQvWcn7fgQWXnbLgs02pQfHG Q4n9Gx218MRxSB4ziAT7kq9SRy8zUvUq9oyFgzbcQJtaVJPR79Qsus8Rjqz9wVOdreaH u3cA50ZFV3jR200+WsBAOC+H1SNxtrw0Ja2R8= MIME-Version: 1.0 Received: by 10.216.89.80 with SMTP id b58mr2642515wef.73.1267000360701; Wed, 24 Feb 2010 00:32:40 -0800 (PST) In-Reply-To: References: <201002221437.o1MEbDJ13005@momjian.us> <4B82C642.8020409@cheapcomplexdevices.com> <20100223203435.GV14128@oak.highrise.ca> Date: Wed, 24 Feb 2010 02:32:40 -0600 Message-ID: Subject: Re: SSD + RAID From: Dave Crooke To: david@lang.hm Cc: Aidan Van Dyk , Ron Mayer , Bruce Momjian , Greg Smith , pgsql-performance Content-Type: multipart/alternative; boundary=0016e6dab0346e0ed00480548284 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201002/339 X-Sequence-Number: 37760 --0016e6dab0346e0ed00480548284 Content-Type: text/plain; charset=ISO-8859-1 It's always possible to rebuild into a consistent configuration by assigning a precedence order; for parity RAID, the data drives take precedence over parity drives, and for RAID-1 sets it assigns an arbitrary master. You *should* never lose a whole stripe ... for example, RAID-5 updates do "read old data / parity, write new data, write new parity" ... there is no need to touch any other data disks, so they will be preserved through the rebuild. Similarly, if only one block is being updated there is no need to update the entire stripe. David - what caused /dev/md to decide to take an array offline? Cheers Dave On Tue, Feb 23, 2010 at 3:22 PM, wrote: > On Tue, 23 Feb 2010, Aidan Van Dyk wrote: > > * david@lang.hm [100223 15:05]: >> >> However, one thing that you do not get protection against with software >>> raid is the potential for the writes to hit some drives but not others. >>> If this happens the software raid cannot know what the correct contents >>> of the raid stripe are, and so you could loose everything in that stripe >>> (including contents of other files that are not being modified that >>> happened to be in the wrong place on the array) >>> >> >> That's for stripe-based raid. Mirror sets like raid-1 should give you >> either the old data, or the new data, both acceptable responses since >> the fsync/barreir hasn't "completed". >> >> Or have I missed another subtle interaction? >> > > one problem is that when the system comes back up and attempts to check the > raid array, it is not going to know which drive has valid data. I don't know > exactly what it does in that situation, but this type of error in other > conditions causes the system to take the array offline. > > > David Lang > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > --0016e6dab0346e0ed00480548284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's always possible to rebuild into a consistent configuration by assi= gning a precedence order; for parity RAID, the data drives take precedence = over parity drives, and for RAID-1 sets it assigns an arbitrary master.

You *should* never lose a whole stripe ... for example, RAID-5 updates = do "read old data / parity, write new data, write new parity" ...= there is no need to touch any other data disks, so they will be preserved = through the rebuild. Similarly, if only one block is being updated there is= no need to update the entire stripe.

David - what caused /dev/md to decide to take an array offline?
Cheers
Dave

On Tue, Feb 23, 2010 at 3= :22 PM, <david@lang.= hm> wrote:
On Tue, 23 Feb 2010, Aidan Van Dyk wrote:

* david@lang.hm <= david@lang.hm> [1= 00223 15:05]:

However, one thing that you do not get protection against with software
raid is the potential for the writes to hit some drives but not others.
If this happens the software raid cannot know what the correct contents
of the raid stripe are, and so you could loose everything in that stripe (including contents of other files that are not being modified that
happened to be in the wrong place on the array)

That's for stripe-based raid. =A0Mirror sets like raid-1 should give yo= u
either the old data, or the new data, both acceptable responses since
the fsync/barreir hasn't "completed".

Or have I missed another subtle interaction?

one problem is that when the system comes back up and attempts to check the= raid array, it is not going to know which drive has valid data. I don'= t know exactly what it does in that situation, but this type of error in ot= her conditions causes the system to take the array offline.


David Lang

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

--0016e6dab0346e0ed00480548284--