Date: Thu, 25 Sep 2008 10:59:31 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: FreeBSD Arch <arch@freebsd.org> Subject: RFC: making gpart default Message-ID: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com>
next in thread | raw e-mail | index | archive | help
All,
I'd like to switch all architectures to gpart for the reasons given
below. All current partitioning schemes are supported by gpart and
work on all platforms. On top of that, ia64 and powerpc are using
gpart exclusively already.
Rationale:
1. Having different utilities for different schemes, which are
otherwise identical in functionality, is painful. Especially
since they all provide a different user interface. While this
is a non-issue for the old geezers among us (we don't know any
better), it is something that the younger crowd perceives as
"low-quality", especially when compared to Linux' parted.
However, the fact that some allow scripting while others
don't is important even for the old geezers. gpart(8) is the
answer.
2. We currently have multiple GEOMs in the kernel that do not
provide a unified, common and/or standard interface. This is
especially problematic for unified tools like the installer.
In fact, we don't have unified tools that use the ctlreq
interface at all, because it's virtually impossible. The
fact that we have sade, is an indication that we do want a
unified tool for partitioning, but without using the GEOM I/F
the tool is useless to modify partitions on a disk with
mounted file systems. The gpart GEOM provides a unified I/F
usable by any tool for creating and modifying any kind of
partitioning scheme.
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. This is good functionality, but only
works for BSD labels. With GPT being used more often and
non-PC hardware using different partitioning schemes, this
means that the functionality isn't working in most cases.
There's fundamentally no reason why newfs or fsck cannot
automatically detect a partition that uses the MSDOS file
system and DTRT. With gpart, we can make that functionality
working across all partitioning schemes.
4. Like the above, but for mount. By checking the partition
type, it's possible to have mount DTRT much more often.
5. The gpart show command can give you a unified list of disks
with their partitions, irrespective of the partitioning
scheme used. For the first time a single command gives us
the overview we're lacking.
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
that processes can query for so that newfs_msdos et al
will work without any additional options.
7. gpart breaks the 8-partition barrier for bsdlabel.
8. gpart adds VTOC information to sunlabel.
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. In those cases gpart
needs to be used. As such, the impact is limited and makes the
switch much more manageable.
In short: gpart is the first step towards a unified set of
tools and interfaces and provides the basis for extending
file system related tools by allowing us to attach real
meaning to partition types. With the commit and undo feature,
gpart is ready for use by next generation installers that
allow us to use any partitioning scheme on any platforms.
Thoughts?
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57809A37-B81C-4F50-A418-CD9303F06B72>