Date: Thu, 25 Sep 2008 19:46:17 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Marcel Moolenaar <xcllnt@mac.com> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: RFC: making gpart default Message-ID: <1896.1222371977@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 25 Sep 2008 10:59:31 MST." <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I know there are users out there who use GEOM for backup and forensic purposes, who have such private geom classes, and these will not be affected by Marcels proposal in any way, except that you may need to grab a copy of geom_slice.* if Marcel obsoletes them. The following comments are my personal comments, and they may or may not be shared by the GEOM Architect, who is free to grind his teeth as he reads them: >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 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. >3. fsck and newfs contain some logic to find out what kind of > file system they're working on and invoke the appropriate > back-end executable. I have always found it scary that they did this based on the out-of-band information. 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. I would prefer a scheme where fsck, like g_label, poked around a bit to find out what the partition content looked like, and started the then backend fsck_foofs with a "I *think* this is yours, but it might not be" flag. On the other hand, if fsck_foofs is explicitly started (for instance based on /etc/fstab) it has license to kill. Overall this is a fine point, but I'd hate to make it easier to trash filesystems. 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. >4. Like the above, but for mount. By checking the partition > type, it's possible to have mount DTRT much more often. Same argument, same code should be used, probably also for g_label(). >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. 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. For usb-sticks, the problem is that we do not even ask them about their geometry, but treat them as SCSI disks that are one-dimensional. 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. We know from NanoBSD users that this is not a theoretical issue, I have countless emails where people put NanoBSD on a USB stick but find it unbootable because it presents a different geometry to the BIOS than the one we used. Dreaming up default geometries will just hide from the user that they are about to make a mistake. I don't recommend it. I would be better to fix umass/cam/da (cross out your own code) to get the correct geometry from the usb-sticks. >7. gpart breaks the 8-partition barrier for bsdlabel. We should discontinue the bsdlabel, it has too many problems and limitations. The best way is to not install more of them once sysinstall knows how to avoid it. >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. I think you should have talked a bit about naming of the partitions ? Are there any compatibility or transition concerns in that area ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1896.1222371977>