RFC: making gpart default

Thu Sep 25 21:24:54 UTC 2008

On Sep 25, 2008, at 12:46 PM, Poul-Henning Kamp wrote:

> 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.

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 at mac.com