Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 974B92E2DB8 for ; Wed, 26 Dec 2007 18:36:24 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 00866-09-2 for ; Wed, 26 Dec 2007 18:36:09 -0400 (AST) Received: from ironport2-out.pppoe.ca (ironport2-out.pppoe.ca [206.248.154.182]) by postgresql.org (Postfix) with ESMTP id 0EA192E2DD7 for ; Wed, 26 Dec 2007 18:36:14 -0400 (AST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJZmckfO+Igp/2dsb2JhbACpRQ X-IronPort-AV: E=Sophos;i="4.24,209,1196658000"; d="scan'208";a="11990060" Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 26 Dec 2007 17:36:13 -0500 Received: from [206.248.136.41] ([206.248.136.41]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id FIK75713; Wed, 26 Dec 2007 17:36:13 -0500 Message-ID: <4772D6A3.2040208@mark.mielke.cc> Date: Wed, 26 Dec 2007 17:33:07 -0500 From: Mark Mielke User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: david@lang.hm CC: Fernando Hevia , 'pgsql-performance' Subject: Re: With 4 disks should I go for RAID 5 or RAID 10 References: <0f9701c84801$399dcff0$8f01010a@iptel.com.ar> <4772CD78.4010302@mark.mielke.cc> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/392 X-Sequence-Number: 28208 david@lang.hm wrote: > however I was addressing the point that for reads you can't do any > checking until you have read in all the blocks. > if you never check the consistency, how will it ever be proven otherwise. A scheme often used is to mark the disk/slice as "clean" during clean system shutdown (or RAID device shutdown). When it comes back up, it is assumed clean. Why wouldn't it be clean? However, if it comes up "unclean", this does indeed require an EXPENSIVE resynchronization process. Note, however, that resynchronization usually reads or writes all disks, whether RAID 1, RAID 5, RAID 6, or RAID 1+0. My RAID 1+0 does a full resynchronization if shut down uncleanly. There is nothing specific about RAID 5 here. Now, technically - none of these RAID levels requires a full resynchronization, even though it is almost always recommended and performed by default. There is an option in Linux software RAID (mdadm) to "skip" the resynchronization process. The danger here is that you could read one of the blocks this minute and get one block, and read the same block a different minute, and get a different block. This would occur in RAID 1 if it did round-robin or disk with the nearest head to the desired block, or whatever, and it made a different decision before and after the minute. What is the worst that can happen though? Any system that does careful journalling / synchronization should usually be fine. The "risk" is similar to write caching without battery backing, in that if the drive tells the system "write complete", and the system goes on to perform other work, but the write is not complete, then corruption becomes a possibility. Anyways - point is again that RAID 5 is not special here. > but for your application, the fact that you are doing lots of fsyncs > is what's killing you, becouse the fsync forces a lot of data to be > written out, swamping the caches involved, and requiring that you wait > for seeks. nothing other then a battery backed disk cache of some sort > (either on the controller or a solid-state drive on a journaled > filesystem would work) Yep. :-) Cheers, mark -- Mark Mielke