From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phillip Susi Subject: Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems Date: Wed, 13 Dec 2006 14:02:20 -0500 Message-ID: <45804E3C.9020105@cfl.rr.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, unionfs@filer.fsl.cs.sunysb.edu, fistgen@filer.fsl.cs.sunysb.edu Return-path: Received: from iriserv.iradimed.com ([69.44.168.233]:8963 "EHLO iradimed.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S965088AbWLMTQA (ORCPT ); Wed, 13 Dec 2006 14:16:00 -0500 To: Nikolai Joukov In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Nikolai Joukov wrote: > replication. In case of RAID4 and RAID5-like configurations, RAIF performed > about two times *better* than software RAID and even better than an Adaptec > 2120S RAID5 controller. This is because RAIF is located above file system > caches and can cache parity as normal data when needed. We have more > performance details in a technical report, if anyone is interested. This doesn't make sense to me. You do not want to cache the parity data. It only needs to be used to validate the data blocks when the stripe is read, and after that, you only want to cache the data, and throw out the parity. Caching the parity as well will pollute the cache and thus, should lower performance due to more important data being thrown out.