Subject: Re: Cloning bdev/cdev devices, step one
To: Bill Studenmund <wrstuden@zembu.com>
From: Greywolf <greywolf@starwolf.com>
List: tech-kern
Date: 07/10/2000 10:34:43
On Mon, 10 Jul 2000, Bill Studenmund wrote:

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

I suppose, with the faster processors/disks, that this wouldn't be a
problem, but unless it gets read into the kernel somewhere for lookups,
wouldn't multiple layers of indirection be ... well, not prohibitive,
exactly, but, excessive?

# Raidframe makes a disk, which has the standard number of partitions on
# it. It's a RAID disk, not an LVM. :-(

Ditto CCD, which is a nice cheap alternative to Raidframe if all you're
looking for is concatenation or striping (which is really just concatenation
with an interleave).

# 
# I can go into my big concern with LVMs off line.

LVMs have their place.  I don't think this place is in a common environment,
though.

# > 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. :-)

Um, shorthand for anyone who has to write code that uses vp->v_foo? :-)

[anonymous struct/union tags would have been a boon for cases like this;
 could have done something like vp->.v_foo]

# Take care,
# 
# Bill

				--*greywolf;
--
BSD: the power to swerve (penguins, worse than cane toads).