Subject: Work-in-progress "wedges" implementation
To: NetBSD tech-kern <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 09/22/2004 13:26:34
Content-Type: text/plain; charset=US-ASCII; format=flowed
Wedges are a new way of representing disk partitions in the NetBSD
The basic idea is to decouple the internal representation of disk
from the on-disk representation. Currently, the NetBSD kernel uses
disklabel" (a.k.a. BSD disklabel) for both in-core and on-disk
and operates on this structure exclusively.
The main problem is that some platforms use (by necessity) on-disk
representations other than the BSD disklabel. This is generally to
maintain compatibility with another OS on the platform (e.g. Mac OS on
a Macintosh), or because the system firmware understands a particular
format (e.g. Sun PROMs understand Sun disklabels).
In order to handle this "other format", individual platforms may support
an alternative on-disk representation. In the kernel, this is
by "struct cpu_disklabel". Unfortunately, there are drawbacks to this
- Cross-platform disk portability is basically non-existent.
- The BSD disklabel cannot represent all of the pertinent
information of some other on-disk representations, and
vice-versa. This includes number of partitions and
Another problem is the fact that the BSD disklabel uses 32-bit fields
for block numbers. This means that the largest disk that the BSD
can describe is 2TB, which is not terribly large by today's standards.
Finally, in a world with hot-plug busses where devices may appear and
disappear at any time, deterministic disk probe ordering does not exist.
The old-fashioned disk naming scheme is not very usable in this
Wedges solves these problems in the following ways:
- Disk partitions are represented in the kernel as separate
block devices, and there can be an arbitrary number of these
associated with a disk. Each wedge internally uses 64-bit
block numbers to support partitions > 2TB.
- Wedges includes a modular partition discovery framework,
different partition formats to be supported seamlessly on all
platforms. A module for the EFI GUID Partition Table (GPT)
format, which includes arbitrary numbers of partitions, 64-bit
block numbers, and Unicode partition names, is included.
- Wedges may also be configured using ioctls from user space,
allowing partition handling to be pushed out of the kernel,
- Wedges are "named". That is, each wedge has an associated
name encoded in UTF-8. This name can be used to create a
device node in /dev to decouple the wedge's identity from
its probe-order-dependent unit number. Duplicate names are
suppressed, and partition discovery modules can try alternate
names in the event of a collision. For example, the GPT
may try the Unicode name associated with the GPT partition,
of that already exists, it may try again using the string
representation of the partition's GUID.
- Wedges represent partition types as strings, allowing for
arbitrary partition types.
The wedges implementation is a work-in-progress at the moment, designed
to allow for the use of old-style disk naming while wedges are still
under development. Features of the current wedges implementation:
1. More items are moved from individual disk softc structures
into "struct disk". Among other things, this allows for
information sharing and better synchronization between
wedges and their parent disks.
2. I/O is enqueued on the wedge and a new buf allocated in order
to perform I/O on the parent. This is a transitional
I would like to eventually make it possible for disk drivers
operate directly on the buf provided to the wedge.
3. Once wedges are created on a disk, I/O to that disk may only
be performed through its wedges, or on the disk's RAW_PART.
Wedges may not be created on a disk if any partition other
than RAW_PART is open.
4. A minphys entry point is added to "struct dkdriver".
I would like to fully utilize "struct dkdriver" as the
to a disk from a wedge, rather than using a vnode. Once we
fully transitioned to wedges, I would like to see the
entry points to disk drivers go away, with the exception of
entry point for the raw disk, so that partitions may be
5. My patch includes modifications to make wedges work with the
driver. I will convert the other disk drivers over time. An
outstanding question: What should we do about floppy drives?
6. I have modified fsck and mount to use the partition type
that wedges provide. Conveniently, I have defined names that
match the fsck_* and mount_* names for the various partition
types that indicate file systems.
1. You can't currently newfs a wedge. This is because newfs
requires the old-style DIOCGDLABEL ioctl, which wedges do
not support. I am working on a means for exporting the
parent disk's geometry through the wedge, which is what
2. Related to (1), what to do about the block size / frag size
entries in "struct partition" (part of "struct disklabel",
and this antiquated and obsolete and not part of wedges)?
I would like to get "wedges" checked into the tree to allow for greater
collaboration on it. Since it does not interfere with the use of disks
through the traditional interface, I don't think it's necessary to put
this on a branch.
Diffs for review are at:
-- Jason R. Thorpe <firstname.lastname@example.org>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----