From owner-freebsd-fs@FreeBSD.ORG Wed Jul 25 16:39:33 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B7C16A421 for ; Wed, 25 Jul 2007 16:39:33 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.freebsd.org (Postfix) with ESMTP id CA3DD13C4A3 for ; Wed, 25 Jul 2007 16:39:32 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [10.201.19.245] (doug02.dyn.qubesoft.com [10.201.19.245]) by mail.qubesoft.com (8.13.3/8.13.3) with ESMTP id l6PGdMX1015863; Wed, 25 Jul 2007 17:39:31 +0100 (BST) (envelope-from dfr@rabson.org) In-Reply-To: <20070725171343.M61339@rust.salford.ac.uk> References: <20070719102302.R1534@rust.salford.ac.uk> <20070719135510.GE1194@garage.freebsd.pl> <20070719181313.G4923@rust.salford.ac.uk> <20070721065204.GA2044@garage.freebsd.pl> <20070725095723.T57231@rust.salford.ac.uk> <1185355848.3698.7.camel@herring.rabson.org> <20070725103746.N57231@rust.salford.ac.uk> <3A5D89E1-A7B1-4B10-ADB8-F58332306691@rabson.org> <20070725120913.A57231@rust.salford.ac.uk> <6FF8729F-B449-4EFA-B3C6-8B9A9E6F6C4F@rabson.org> <20070725171343.M61339@rust.salford.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77814562-8B5E-4E3C-9018-59F7E8FBF8C8@rabson.org> Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Wed, 25 Jul 2007 17:39:22 +0100 To: Mark Powell X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.qubesoft.com X-Virus-Scanned: ClamAV 0.86.2/3763/Wed Jul 25 16:37:41 2007 on mail.qubesoft.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: ZfS & GEOM with many odd drive sizes X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 16:39:33 -0000 On 25 Jul 2007, at 17:20, Mark Powell wrote: > On Wed, 25 Jul 2007, Doug Rabson wrote: > >> On 25 Jul 2007, at 12:17, Mark Powell wrote: >>> Great work. That will be zfs mirror only right? >> >> The code is close to being able to support collections of mirrors. >> No raidz or raidz2 for now though. > > That's great news. > So that would mean, if a raidz vdev was required on a system > another pool would have to be created with only a mirror vdev in > it, to have / on zfs too? > Considering the work involved, is raidz / support really worth > it? Of course, it's fantastic if you plan to tackle it, but I don't > envy you the task :( In theory supporting raidz isn't that hard although the layout policy is undocumented. I've looked at the code and I could probably borrow some code from the 'real' zfs to figure out the layout and support non-degraded raidz and raidz2. Supported degraded configurations is more effort because of the extra code to re-generate the date from the parity. The biggest problem here is space. The wretched PC platform requires us to bootstrap the system starting from a single sector's worth of code (512 bytes). That code runs in stone-age 16bit mode and loads the second stage from a fixed disk location. To keep my sanity, I'm currently trying to limit the code size of the second stage to 16k. This second stage has to understand ZFS well enough to load the third stage /boot/loader code from the pool. I currently have exactly 171 bytes of free space in boot2. I could probably squeeze another 4k into the second stage bootstrap by re-writing boot1 again. I will probably have to do that to support collections of disks/mirrors anyway. Doing that will mean permanently giving up the idea of booting ZFS on systems that don't support LBA addressing. Tthis already disabled in my boot1 code but could be resurrected after some hair pulling - increasing the size of boot2 would make supporting legacy (>10hys old) BIOS machines impossible.