From owner-freebsd-arch@FreeBSD.ORG Thu Sep 25 21:24:54 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 190FD106568D for ; Thu, 25 Sep 2008 21:24:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 067558FC20 for ; Thu, 25 Sep 2008 21:24:53 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from alan-tablet.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0K7R00KN7STEOU30@asmtp015.mac.com> for arch@freebsd.org; Thu, 25 Sep 2008 14:24:53 -0700 (PDT) Message-id: <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com> From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <1896.1222371977@critter.freebsd.dk> Date: Thu, 25 Sep 2008 14:24:49 -0700 References: <1896.1222371977@critter.freebsd.dk> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2008 21:24:54 -0000 On Sep 25, 2008, at 12:46 PM, Poul-Henning Kamp wrote: > In message <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com>, Marcel > Moolenaar wri > tes: >> All, >> >> I'd like to switch all architectures to gpart for the reasons given >> below. > > I promised long time ago, that I would only use my 'GEOM Architect' > hat to interfere with what people do _to_ GEOM, not what people > do _with_ GEOM. > > The GEOM Architect therefore has only this comment: > > I would like to point out explicitly that Marcels proposal, to > switch to gpart by default, does not prevent the use of other GEOM > classes to interpret disk-layouts. Nod. You can freely mix and match. People are already doing that: GPT is handled by gpart, whereas MBR and BSD are handled by the MBR and BSD slicers. >> Rationale: >> 1. Having different utilities for different schemes, which are >> otherwise identical in functionality, is painful. > > On the other hand, trying to generalize widely different semantics > is also not a recipe for eternal youth: Not all the worlds > partitioning > metadata formats have type information, some have weird ass > restrictions and bootcode(-requirements) are generally magic. I have wondered about the "different semantics" and found that it's the semantics that are actually the same. No matter what the details, they all serve the same purpose: chopping up a disk in multiple (non-overlapping) regions. Granted, supporting all the details of a particular scheme may not be easy or even possible. But when we only look at the aspects that affect FreeBSD, the details end up not being that important in the end. > I didn't dare do what you've done now, but since you touched it > last, I'm not worried :-) :-) > My proposed solution was to try to get the BSD label discontinued > and rely entirely on the native partitioning on the relevant > platforms, but that meant dealing with FAT extended partitions and > going back to libdisk and I couldn't get myself to do that. Trying to use the native scheme is generally good. But I do expect that FreeBSD on platform X knows or recognizes a disk created on or used by FreeBSD on platform Y. > Granted, fsck's generally choke on each others filesystems > pretty conclusively, but fsck will happily trash a database > stored in partition that previously contained a filesystem, > provided enough magic bits survive near the start. That's why I believe we need to attach real meaning to the partition type. We should disallow a newfs_ufs on a partition that is not of type freebsd-ufs. We should disallow swapon for a partition that is not of type freebsd-swap. etc.. With gpart it's trivial to change the partition type, so it's no hassle. The protection and support this gives users certainly outweighs the hassle IMO. > Overall this is a fine point, but I'd hate to make it easier to > trash filesystems. I agree. Enforcing that partition types match the content (within reason) is a good start. Already gpart checks the partition type for the dumpon command and fails when it's an obvious mismatch. > Lacking a reliable mechanism to keep the out-of-band filesystem > type consistent with the partition content, think dd(1), g_mirror > movements of data etc, I'm not too thrilled about this. Keeping consistency can only be the responsibility of the user/admin. We give them too much power to do it for them. All we can do is enforce and/or promote consistency by taking the partition type seriously. >> 6. Not all "disk" devices have a geometry. Especially md(4) >> devices and USB mass storage devices. This is a problem >> for newfs_msdos. With gpart, there's always a geometry [...] > > I will argue this is wrong. It's not wrong. It's a consequence. As long as there are partitioning schemes and file systems that use sectors, track and/or cyclinders we need to provide it. Even under GPT do we need a geometry simply because the EFI file system is the MSDOS file system. True, GPT itself doesn't need it, but that's not the point. > For md(4), you an define a geometry if you want one, and if > your plan is to move the filesystem to real media later, > you had better do so correctly. True. Geometries create problems. > In many cases you can infer the geometry from a preexisting MBR, > but presently our code does not do this, and as we know from the > Dangerously Dedicated Disk Layout, that is a pretty error-prone > heuristic in the first place. gpart does take this into account. When the underlying provider has no geometry, gpart synthesizes one. This geometry is "soft" in the sense that it can later be adjusted to match what partitioning schemes say it is (or should be). In either case, there can be a real mismatch. If that happens gpart will let you know and it can even reject the partitioning scheme. Again, this is based on the philosophy that there's meaning. Recording a geometry without there being a meaning is pointless. > Dreaming up default geometries will just hide from the user that > they are about to make a mistake. It's not the user that can make a mistake in this case. They're merely burdened by the inconsistencies due to sloppiness and/or bad design. > I would be better to fix umass/cam/da (cross out your own code) > to get the correct geometry from the usb-sticks. I totally agree. >> 7. gpart breaks the 8-partition barrier for bsdlabel. > > We should discontinue the bsdlabel, it has too many problems > and limitations. I agree, but compatibility is not bad and NetBSD does support more than 8 partitions. >> With gpart default, tools like fdisk and bsdlabel continue to >> work on new disks and disks that have no mounted file systems. >> In that respect there's no difference. However, they cannot >> be used when file systems are mounted. > > This is going to break more scripts than you think. Likely. > I think you should have talked a bit about naming of the > partitions ? Good point. With gpart, partition types are abstracted so that the user and tools are presented with a fixed alias and not with whatever identification scheme is used for a particular partitioning scheme. For example the MBR type 165 is presented by gpart as type "freebsd". When the underlying scheme is GPT, the on-disk identification is the following UUID: 516e7cb4-6ecf-11d6-8ff8-00022d09712b Of course, gpart doesn't have aliases for all possible partition types. Just the ones that we care about in FreeBSD. For a UFS partition, the gpart type is "freebsd-ufs". For a swap partition it is "freebsd-swap". On my server (FreeBSD 7.x) "gpart show" gives: ns1% gpart show => 63 80293185 ad0 MBR (41.1GB) 63 80292807 1 freebsd [active] (41.1GB) 80292870 378 - free - (193.5KB) => 0 80292807 ad0s1 BSD (41.1GB) 0 2097152 1 freebsd-ufs (1073.7MB) 2097152 16777216 2 freebsd-swap (8.6GB) 18874368 16777216 4 freebsd-ufs (8.6GB) 35651584 44641223 5 freebsd-ufs (22.9GB) => 34 976773101 ad1 GPT (500.1GB) 34 97656250 1 freebsd-ufs (50.0GB) 97656284 879116851 2 freebsd-zfs (450.1GB) => 34 976773101 ad2 GPT (500.1GB) 34 97656250 1 freebsd-ufs (50.0GB) 97656284 879116851 2 freebsd-zfs (450.1GB) => 34 1953525101 ad3 GPT (1000.2GB) 34 1953525101 1 freebsd-zfs (1000.2GB) => 34 976773101 ad4 GPT (500.1GB) 34 976773101 1 freebsd-zfs (500.1GB) => 34 976773101 ad5 GPT (500.1GB) 34 976773101 1 freebsd-zfs (500.1GB) The actual partitioning scheme, while shown, has been made irrelevant. A UFS or ZFS partition has the same abstract type no matter how the disk is partitioning. Currently gpart has aliases the following aliases: efi freebsd freebsd-boot freebsd-swap freebsd-ufs freebsd-vinum freebsd-zfs mbr Partition types for which we don't have aliases are shown in their raw (i.e. partitioning scheme specific) repesentation (numbers, UUIDs or labels). > Are there any compatibility or transition concerns in that area ? These are the problem areas I can think of: o My amd64 had a broken/invalid BSD label and was rejected by gpart. It had to be fixed-up first. I expect that this may be more common than we'd like it to be. Thus: previously accepted BSD labels may not be accepted by gpart due to better checking. o The partition given to the dumpon command needs to be of the right type. When switching to gpart on sparc64, the dumpon command failed because there are no partition types in the current sunlabel support. Assigning the proper partition types on sparc64 after the switch to gpart did the trick. This also applies to PowerPC... o I do not have a pc98 machine. I've been testing on a memory disk and validated inter-operability, but I don't have FreeBSD booting a running on pc98. -- Marcel Moolenaar xcllnt@mac.com