From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolai Joukov Subject: Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems Date: Wed, 13 Dec 2006 14:32:17 -0500 (EST) Message-ID: References: <45804E3C.9020105@cfl.rr.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: Received: from sbcs.sunysb.edu ([130.245.1.15]:59679 "EHLO sbcs.cs.sunysb.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932667AbWLMTc3 (ORCPT ); Wed, 13 Dec 2006 14:32:29 -0500 To: Phillip Susi 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. > > This happens automatically: unused parity pages are treated as unused > pages and get reused to cache something else. Also, the parity > never gets cached if you do not write the data (or recover the data). > However, if you use the same parity page over and over you do not need to > fetch it from the disk again. To avoid confusion here: data recovery is not the only situation when it is necessary to read the parity. Existing parity is also necessary for writes that are smaller than the page size. Nikolai. --------------------- Nikolai Joukov, Ph.D. Filesystems and Storage Laboratory Stony Brook University