On 23 Sep 1999, Johan Danielsson wrote:

# Ignatios Souvatzis <ignatios@cs.uni-bonn.de> writes:
# 
# > > Disks really *should* have unique ids.
# > 
# > No. File systems should have.
# 
# I don't think I completely agree. The operating system shouldn't care
# if I have filesystem, a raw device database, or swap on my partition,
# and it should work just the same if I move disks (partitions)
# around. If I have a mirrored partition the application using it
# shouldn't have to care that there are more copies of the information.

I think we're trying to make the system more intelligent than the
person, here -- is this *really* what we want?

What is our _real_ goal here?  Do we want a system that's going to
dance whizzy-bang circles or do we want a system that's ultimately
going to be usable?  (Hint: we have the latter now.)

In my experiences as an SA (which, I'm sure, pale in comparison
to those of some of you co-dinosaurs), everything which was meant
as an assistance by some means of magic has proven only marginally
easier in setup and running, but significantly more of a PITA when
it came to recovery.  For example, SunOS deciding that / and /usr
needed to be mounted in single-user mode.  If you lost /usr, you
were really really screwed and had to use install media to even
consider recovering your system.  For example, System V's
"simplified" device naming scheme.  The only reason it worked
as long as it did was because for a long time, you could only run
real System V on a 3b*, and they didn't *have* any other types
of controllers (don'tcha just love proprietary hardware?).

Now, I'm not your average case (or, perhaps among NetBSD types,
I am.  I don't know), but the *very first thing* I'm gonna do after
getting a GENERIC kernel up and running is to import the distro's
kernel sources (if I don't have them already), cp GENERIC to $MYKERNEL
and *wire* *down* *my* *current* *config*, with some allowances for
expansion depending on my architecture, budget and anticipated
hardware acquisitions.  And this is, of course, because I, like
several others, don't like surprises when I plug in a new
device.

Like most, I also do not (usually) wire down the controller, because
the chances of me obtaining another controller, let alone another
disk, right now are exactly three:  slim, fat and none.

Had I the possibility of serious expansion, I'd probably wire things
down a bit more.

# 
# On the other hand a filesystem might also want to keep information
# about where to find alternative sources for a filesystem, whether it
# is on an other disk or another host (let's say you have a multihomed
# disk where my end of the scsi-chain is broken but I still can mount
# the filesystem via some other network). The kernel disk can't and
# shouldn't know anything about this.

You've got your feet in two canoes, it would seem.

The kernel disk doesn't need to know anything.  Period.  It's
just a disk which serves data.

The kernel, however, does need to know partitioning information,
and should probably know how to get it, or at least allow it to
be set.

Curiously, to rephrase and restate my question above:
Just how unreal are we going to get about all this?  We're talking
about adding some serious bloat if we're going to start doing any
serious abstractions.  We're about to embark on a journey which
is about to violate both KISS and the PLS.

# 
# /Johan
# 


				--*greywolf;
--
Microsoft:
	"Just click on the START button and your journey to the Dark Side
	 will be complete!"