From owner-p4-projects@FreeBSD.ORG Tue Jul 17 21:09:26 2007 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 48B2216A417; Tue, 17 Jul 2007 21:09:26 +0000 (UTC) X-Original-To: perforce@FreeBSD.org Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1397C16A414 for ; Tue, 17 Jul 2007 21:09:26 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [69.147.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id EC7B913C4CA for ; Tue, 17 Jul 2007 21:09:25 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id l6HL9PuV078790 for ; Tue, 17 Jul 2007 21:09:25 GMT (envelope-from lulf@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.1/8.14.1/Submit) id l6HL9P4N078787 for perforce@freebsd.org; Tue, 17 Jul 2007 21:09:25 GMT (envelope-from lulf@FreeBSD.org) Date: Tue, 17 Jul 2007 21:09:25 GMT Message-Id: <200707172109.l6HL9P4N078787@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to lulf@FreeBSD.org using -f From: Ulf Lilleengen To: Perforce Change Reviews Cc: Subject: PERFORCE change 123663 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: Tue, 17 Jul 2007 21:09:26 -0000 http://perforce.freebsd.org/chv.cgi?CH=123663 Change 123663 by lulf@lulf_carrot on 2007/07/17 21:09:07 - Add more to my TODO. Affected files ... .. //depot/projects/soc2007/lulf/TODO#6 edit Differences ... ==== //depot/projects/soc2007/lulf/TODO#6 (text+ko) ==== @@ -149,13 +149,45 @@ 20. Make sync/rebuild requests also get delayed due to rebuild requests? -20. When to trondheim. Write papers for status report. +20. When to trondheim. Write papers for status report. Done. -21. Updateman-page +21. Updateman-page. Done 22. Add a raid5 command to create a raid5 array the same way that is done with -concat/mirror/stripe +concat/mirror/stripe. Done + +23. Make sure unequal plexes cannot be mirrored. Done + +23. Create patches. Done. + +24. Grow RAID-5 arrays. +How should it be done? +The way to do this can be by duplicating existing subdisks, add a new one Other +than that, I'm having plans to make it possible to resize RAID-5 arrays. There +are two ways I thought of doing this: If the old array had three drives, and the +new one four, one would create a new plex with subdisks where three of them +referenced the same drives as the old plex, but also had a new subdisk for the +new disk. Then, reading X Bytes from the old plex, and then write it to the new +plex, which should prevent it from overwriting old data, right (At least if X +bytes is #disks x stripesize). Could this work, or does it just seem too +complex? If the stripesize is large and there are many disks, one could perhaps +run out of memory. + +The problem is that it's hard to clone everything. We could +modify the gv_plex structure to have a added subdisks field, where all new +writes would go until the GV_PLEX_GROW flag is gone, but reads still would only be +served from the normal subdisk list. One would need to modify gv_plexbuffer and +code in the raid5 config to use this list actively. We can use only one list if +we assure that we get the correct sdno and psdno. + +Where and when should it be done? +It should be done if sdcount is increased in gv_sd_to_plex, the plex is not +newborn, and the plexorg is raid-5 + +Or + +The subdisk is added to the plex as normal, but the subdisk carries a special +flag which tells the system to expand the array when 'init' is run. Should there +be a grow command perhaps? -23. Make sure unequal plexes cannot be mirrored. -23. Create patches.