RFC: making gpart default

[Poul-Henning Kamp]

In message <57809A37-B81C-4F50-A418-CD9303F06B72 at 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 at 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.