Subject: Re: Cloning bdev/cdev devices, step one
To: Bill Studenmund <firstname.lastname@example.org>
From: Greywolf <email@example.com>
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,
# > 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,
BSD: the power to swerve (penguins, worse than cane toads).