From owner-freebsd-geom@FreeBSD.ORG Wed Jul 5 21:58:44 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E94516A4E0 for ; Wed, 5 Jul 2006 21:58:44 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E77643D49 for ; Wed, 5 Jul 2006 21:58:41 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id C468211446; Wed, 5 Jul 2006 17:58:08 -0400 (EDT) Message-ID: <44AC3618.80600@rogers.com> Date: Wed, 05 Jul 2006 17:58:48 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "R. B. Riddick" References: <20060705211453.47043.qmail@web30308.mail.mud.yahoo.com> In-Reply-To: <20060705211453.47043.qmail@web30308.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No Cc: freebsd-geom@freebsd.org Subject: Re: new class / geom_cache / request for comments X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 21:58:44 -0000 R. B. Riddick wrote: > Yes, I think so... > But geom_cache is just useful, when file system's buffer cache cannot help. > > E. g.: > A degraded RAID5 on 4 consumers (3 good plus 1 failed). > When we want to get a data block, that resides on the failed consumer, we have > to read all corresponding blocks (2+1) in order to rebuild the missing block. > When we do a sequential read, we would have to read the consumers, that hold > the data blocks twice (2 x 2). > So the geom_cache could help here (2+1 real reads plus 2 from the cache), if > the provider is not too busy. > Wouldn't it make more sense to modify geom_raid5 to include this behavior, instead of writing a new and separate geom class that has only one useful function?