From owner-freebsd-current@FreeBSD.ORG Fri Sep 24 00:48:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80B0416A4CE for ; Fri, 24 Sep 2004 00:48:32 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41AEE43D49 for ; Fri, 24 Sep 2004 00:48:32 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i8O0mVvA065052; Thu, 23 Sep 2004 17:48:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i8O0mVLk065051; Thu, 23 Sep 2004 17:48:31 -0700 (PDT) (envelope-from dillon) Date: Thu, 23 Sep 2004 17:48:31 -0700 (PDT) From: Matthew Dillon Message-Id: <200409240048.i8O0mVLk065051@apollo.backplane.com> To: Brooks Davis References: <408F11C5.5030403@freebsd.org> <20040428033948.GA7603@dhcp01.pn.xcllnt.net> <20040921221631.GA14566@odin.ac.hmc.edu> cc: freebsd-current@freebsd.org cc: Garance A Drosihn Subject: Re: Default support for GPT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2004 00:48:32 -0000 :> Question 1: :> Since David's comments in April, Matt has changed Dragonfly (based :> on FreeBSD 4.x) to support 16 partitions in the standard BSD label. :> How hard would it be to install those changes in 6.x-current? :> Brooks mentioned the boot-blocks, and I recall that Matt had to :> move them up. Is there any reason to *not* move the boot blocks? :> (not in 5.x, certainly, but in 6.x-current) : :I believe PHK has a reason, but I don't know what it is. The location of the boot2 code used to be offset sufficiently from the partition table that the partition table could be extended, and I even considered doing this a few years ago (but got hung up on available minor device bits). However, at some point someone moved the boot2 code so it sits right up against the 8-partition partition table, presumably in order to make room for the UFS1+UFS2 support. For DragonFly I shifted it back to its old location and then extended the partition table to 16 partitions, but DragonFly does not support UFS2 so there's room. Eventually DFly is going to redo the entire partition table mechanism, probably moving to a dynamic [offset,size] for the boot2 area and [offset,size] for the partition table area, stored in the first sector of boot2 (remember it has to be simple enough for boot1 to be able to load boot2, and boot1 has < 512 bytes to work with). This will be a pre-req for any support for booting off non UFS1 filesystems and will, of course, require the disk to be freshly partitioned. I considered GPT but I want to have much more control over the DragonFly 'partitions' then I believe GPT offers. e.g. we need to be able to uniquely identify partitions in a WAN environment, store the core RAID topology, and so on and so forth... everything you need to operate in a clustered environment really has to be made part of the partition table. :an appropriatly named parition. Note that if Intel follows through on :their plans to make EFI standard on IA32 servers, we won't have a choice :about using GPT as the native partition table. I expect there will be a few years where both will be supported by BIOSes, simply because otherwise existing Windoz systems might not work. However, even in a native GPT environment I don't think I would want to use it to specify BSD partitions. :There's a post from marcel on this topic, I can't remember where. It :might have been on developers. IIRC the big things a boot block that :understands enough GPT to find a root partition and boot. It's worth :noting that GPT labels look just like MBR labels except that normally :they reserve the whole disk (or at least the addressable 2TB) as a :single partition for them selves and store the real data elsewhere. It :may be possiable to build GPTs that have some MBR slices as well, I'm :not sure what the standard says. : :-- Brooks Oh ick. Just what I expect from Intel and MS, though. -Matt Matthew Dillon