Subject: Re: Cloning bdev/cdev devices, step one
To: Chuck Silvers <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 07/10/2000 10:13:01
On Sun, 9 Jul 2000, Chuck Silvers wrote:
> On Fri, Jul 07, 2000 at 01:33:26PM -0700, Bill Studenmund wrote:
> > 99.9% of the time, the two are the same. But if we go to 64 partitions per
> > disk (using new major numbers), then they won't necessarily be the
> > same. I expect that what we will do is map the 8/16 partition devices to
> > the equivalent 64 partition device. So for things like sd0a, the inode
> > will still have the 8/16 partition major, while the vnode's v_rdev will
> > have the 64-partition major number. That way the right thing happens if
> > there's an sd0a on disk with the 64-partition major number.
> so how would you make a device node on disk to represent the 34th partition?
You'd use the 64-partition major number, and make it minor 34.
> btw, I would hope that we will get away from the current notion of a fixed
> number partitions per disk at some point and move to a more volume-oriented
> design. I imagine raidframe does something reasonable here but I haven't
> looked at it yet. clearly some environments (eg. embedded stuff) won't
> want the overhead of a volume-management system, but others (eg. ISPs)
> would gladly pay the price for the increased flexibility. I think what
> I mean here is that our default install should create filesystems in
> volumes (or whatever raidframe calls them) rather than directly in
> device partitions, or at least have an option to do this.
> but this is a separate discussion.
Raidframe makes a disk, which has the standard number of partitions on
it. It's a RAID disk, not an LVM. :-(
I can go into my big concern with LVMs off line.
> yes, I understood that the new field would really live in struct specinfo.
> my point is just that since the device info is available as
> vp->v_specinfo->si_foo, what's so great about referring to it as vp->v_foo?
> everything that would use vp->v_foo already has to make sure that it's
> operating on a device vnode, so why clutter the namespace?
Oh. I don't know. At one time, there probably was an advantage, but I
agree it's not really there now. :-)