Subject: Re: Another changer, another changer problem
To: NetBSD-current Discussion List <current-users@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 10/05/1998 01:11:00
[ On Mon, October 5, 1998 at 12:53:40 (+1000), Robert Elz wrote: ]
> Subject: Re: Another changer, another changer problem
>
> It is one of my greater regrets that back in the days when essentially all
> discs were on removable packs (ie: before everyone switched to using Eagles
> and similar) that I didn't add support for sane use of pack labels.
Me and my ancient RL02s, RK05s, RP03 and CDC9762 thank you for reminding
everyone what I thought should have been still painfully obvious. How
soon they seem to forget! ;-)
I too wish you or someone had improved the tools in Unix to better
handle removable packs back in the days when they were still common.
Of course I can rear SysV's ugly head here again and remind everyone
that they kept support for volume and slice names and did print warnings
when a partition was mounted on a location different from where it
claimed it should be, etc. and if I remember correctly when you
re-mounted it on the "right" place you'd still be able to see that it
had been mounted on some other place previously, etc. (remember tools
named labelit, fsname, volcopy, etc.?)
> Perhave fortunately, with Zip drives, and Jazz drives, and cdroms (and DVD
> to come) all becoming much more popular, the demand for fixing this will
> soon be overwhealming, and it will get done.
.... but they might yet learn and remember again! ;-)
> To handle multiple filesystems with the same label we just allow the
> admin to specify resolution rules (for each filesystem). Those might allow
> something like "prefer fixed drive read/write media, if that isn't available
> prefer any read/write media, even if dismountable, and if that isn't available
> either, allow any read only media (cdrom etc)". Then to disambiguate
> between equal cost cases of those, prefer the newer (newest if more than 2)
> (where that indicates most recently modified). Of if the admin prefers,
> bitch and halt, and allow the admin resolve the duplication by pulling
> devices. Whatever...
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,
especially back when multiple partitions, even on an RK05, was a silly
idea. I really like these ideas -- makes me want to go out and buy a
jazz drive and try re-defining some data structures!
> Note that it is the filesystems (data sets) that need to be labelled, not
> the physical devices - that would be better than we now have, but data sets
> move around amongst physical devices, that relationship isn't fixed, and
> we ought not be assuming that it is. Fortunately there's an ideal place
> to stick the relevant label ... the "last mounted on" field that already
> exists (at least in ufs filesystems, cdroms have other labels, etc) and which
> turns out to have almost the ideal semantics. There's also already a "last
> modified time" field in the superblock, so in practice everything we need
> exists already. Add a tool to allow the "last mounted on" field of an
> unmounted filesystem to be altered, and all that's needed after that is the
> "find the best filesystem with this label and mount it" magic.
Hmmm.... I'd rather not throw away the potential of the "last mounted
on" field. I'd rather instead expand the structure a wee bit and
provide a proper "partition name". Then you could do things like check
that the "last mounted on" field matches the "partition name" field.
Which reminds me.... the "last mounted on" field has given me headaches
ever since the day I mounted a filesystem on /usr/local/var/spool/news
and then another on /var/spool/news and wondered why I could no longer
tell the difference between the two filesystems when they were
unmounted. To date though I've not come up with any better ideas than
just increasing the field's length to something more sane for BSD
systems.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>