From owner-p4-projects@FreeBSD.ORG Mon Jul 23 10:44:26 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 828A316A468; Mon, 23 Jul 2007 10:44:26 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F88816A419; Mon, 23 Jul 2007 10:44:26 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from signal.itea.ntnu.no (signal.itea.ntnu.no [129.241.190.231]) by mx1.freebsd.org (Postfix) with ESMTP id C8A1713C469; Mon, 23 Jul 2007 10:44:25 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by signal.itea.ntnu.no (Postfix) with ESMTP id 697D3401AF; Mon, 23 Jul 2007 12:44:24 +0200 (CEST) Received: from gaupe.stud.ntnu.no (gaupe.stud.ntnu.no [129.241.56.184]) by signal.itea.ntnu.no (Postfix) with ESMTP; Mon, 23 Jul 2007 12:44:24 +0200 (CEST) Received: by gaupe.stud.ntnu.no (Postfix, from userid 2312) id 01BC0D0034; Mon, 23 Jul 2007 12:44:32 +0200 (CEST) Date: Mon, 23 Jul 2007 12:44:32 +0200 From: Ulf Lilleengen To: Pawel Jakub Dawidek Message-ID: <20070723104432.GA557@stud.ntnu.no> References: <200707172109.l6HL9PMJ078780@repoman.freebsd.org> <46A03390.3030602@freebsd.org> <20070720123524.GA71360@twoflower.idi.ntnu.no> <20070720150716.77d2636a@deskjail> <20070723103651.GD5456@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070723103651.GD5456@garage.freebsd.pl> User-Agent: Mutt/1.5.9i X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: Alexander Leidinger , perforce@freebsd.org, Eric Anderson Subject: Re: PERFORCE change 123662 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2007 10:44:26 -0000 On Mon, Jul 23, 2007 at 12:36:51PM +0200, Pawel Jakub Dawidek wrote: > On Fri, Jul 20, 2007 at 03:07:16PM +0200, Alexander Leidinger wrote: > > Quoting Ulf Lilleengen (Fri, 20 Jul 2007 14:35:24 +0200): > > > > [growing RAID-5] > > > Well, what I do is to attach/create the new subdisk as usual, but since it's a > > > RAID-5 array that I know is operational, I give the subdisk a flag, and sets the > > > plex in a resize state. Then, In the raid-5 code, I modify gv_raid5_offset > > > (which basically computes offsets within a subdisk based on the number of > > > subdisks and stripesize). However, what I do, is that instead of taking all > > > subdisks in the calculation, I only take those who does not have the GROW flag > > > (when reading), and I take all subdisks into calculation when it's a write. > > > > > > This means, that if a create a gv_grow_plex function that reads (stripesize x > > > sdcount) bytes (from the subdisks that do not have the GROW flag), and writes > > > that data to the plex (including all subdisks). This way, i sort of overwrite > > > the old data, but the data is spread out over the new subdisks. I'm sorry if > > > this might seem a bit complex, but just ask more questions if you didn't > > > understand. > > > > Do you use the additional drive(s) only to write checksums to them, or > > do you write real data to it? If the later, how do you make sure you > > read the right data in case you read data again, which was just written > > there a moment before (how do you know to read from all subdisks and > > not only from a subset in this case)? > > You only need to move offset while you synchronize new disk. > > When you start you have: > > Disk0 Disk1 Disk2 NewDisk > > D0 D1 P0 U > D2 P1 D3 U > P2 D4 D5 U > D6 D7 P3 U > D8 P4 D9 U > P5 D10 D11 U > > After some time you have: > > Disk0 Disk1 Disk2 NewDisk > > D0 D1 D2 NP0 > D3 D4 NP1 D5 > U U U U > --> D6 D7 P3 U > D8 P4 D9 U > P5 D10 D11 U > > And at the end you have: > > Disk0 Disk1 Disk2 NewDisk > > D0 D1 D2 NP0 > D3 D4 NP1 D5 > D6 NP2 D7 D8 > NP3 D9 D10 D11 > U U U U > U U U U > > Where: > D - data block > P - parity block > NP - new parity block > U - unused > --> - if offset in I/O request is below that point, you use four disks, > if it is above that point you use only three disks EXACTLY! You're 100 times better than me to explain how it works :) Thanks. -- Ulf Lilleengen