Subject: Re: Work-in-progress "wedges" implementation
To: Jason Thorpe <firstname.lastname@example.org>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 09/23/2004 20:52:46
Date: Wed, 22 Sep 2004 13:26:34 -0700
From: Jason Thorpe <email@example.com>
| - Disk partitions are represented in the kernel as separate
| block devices, and there can be an arbitrary number of these
| associated with a disk.
When this happens, it is going to be even more important than it is
now to solve one of the current problems we have on NetBSD (maybe
other systems do as well).
That is, we need a way to relate the device names to the real underlying
hardware that implements the apparent "device" (zero or more real
underlying hardware identifiers).
It doesn't matter in the slightest what the underlying hardware identifier
"names" look like (just integers 1, 2, 3... would be adequate), but
there are applications (like "fsck -p" for one well known example) where
we really want to be able to find out what hardware device is going to
be accessed when we start accessing a higher level device.
An ioctl that takes a fd of an open device, and returns an array of
"names" for the underlying hardware is all that's needed - provided that
the ioctl passes "through" the pseudo-device layers (raid, ccd, cgd, etc)
to reach something that can be described as actually being hardware,
and returns the complete set.
All that's required of the names is that they be unique for any real
device on the system as it exists now - they don't have to be stable
across reboots, or meaningful in any intelligent way. What's needed is
a way to tell whether or not doing accesses on one wedge (or raid or
whatever else) will have any noticeable impact on doing accesses on
another one (sharing a bus isn't a significant enough effect, sharing
heads on a drive is). Where there's doubt (eg: an external raid box)
the whole thing should be assumed to be one hardware device, even if
there are a hundred drives in there...