Subject: Re: Another changer, another changer problem
To: NetBSD-current Discussion List <current-users@netbsd.org>
From: Robert Elz <kre@munnari.OZ.AU>
List: current-users
Date: 10/05/1998 17:37:54
Date: Mon, 5 Oct 1998 01:11:00 -0400 (EDT)
From: woods@most.weird.com (Greg A. Woods)
Message-ID: <m0zQ2vE-0009MEC@most.weird.com>
I hadn't gone this far in my thinking yet. This is more in tune with
big professional mainframe systems than simple minicomputers and such,
I'm not sure I agree - back when everyone used removable packs, then
perhaps. These days, I think your average big site can manage its
physical drives, including having good standby backup systems all set up
(different root which uses different swap, different usr, etc) all ready.
The big use of this is the no-admin medium size sites - the ones where
the relationship between the hardware and the filesystem that lives on it
is much more mysterious than to professional admins. This is where you
want to be able to tell people "put the emergency CD (jazz, zip) in a drive
and reboot" after which the system will come back to a state where it can
be contacted over the net to be properly fixed.
Hmmm.... I'd rather not throw away the potential of the "last mounted
on" field.
I wasn't intending that - the idea is just that usually (almost always)
where you want to mount a filesystem is the same place it was mounted
last time. If that is what happens by default, and there are other
meshanisms to cause something different to occur, I think we could
survive without adding new fields. Of course, if a new field will cause
no problems, then nor would it hurt this.
kre