Date: Fri, 27 Jan 1995 12:08:58 -0800 (PST) From: julian@tfs.com (Julian Elischer) To: dufault@hda.com (Peter Dufault) Cc: hsu@fx7.cs.hut.fi, freebsd-hackers@freefall.cdrom.com, freebsd-scsi@freefall.cdrom.com Subject: SCSI device configuring.. (was scsi renames devices) Message-ID: <m0rXwyY-0003vpC@TFS.COM> In-Reply-To: <199501261406.JAA04537@hda.com> from "Peter Dufault" at Jan 26, 95 09:06:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
>
> Heikki Suonsivu writes:
> >
> >
> > >Number: 189
> > >Category: kern
> > >Synopsis: sd renames disks
> > >Confidential: no
> > >Severity: serious
> (...)
> >
> > sd thinks it is smarter than you on id's you want your disks have. Install
> > three disks, sd1a is /tmp and sd2a is users. Guess what happens if sd1
> > breaks down, controller misses it by the phase of the moon, or you forget
> > to power it up if it is in an external box.
> >
> > I wouldn't be happy about editing fstab every time disk configuration changes,
> > but that is a minor problem compared to potential dangers this brings us.
> >
> > (I already complained, but maybe it is a good idea to gnats it so that it
> > won't be forgotten)
> >
> > >How-To-Repeat:
> >
>
This came about because there was no way to specify a target and LUN
in the config.. if you looked in the original SCSI stuff, there was
support for nailing down a particular device to a particular address. however
it required editing a file.. (scsiconf.c .. look for the word "predefined")
The following comment from the file describes it:
/*
* The structure of pre-configured devices that might be turned
* off and therefore may not show up
*/
It was a hack then and it still is..
there are several ways around the problem..
1/ The NetBSD approach.. NetBSD have changed their config code almost entirely,
to use the same system as (I believe) BSDI.. wherever it came from, it allows
the scsi-IDs to be defined into the kernel.. it first assigns all the
fixed units that you have defined and then moves onto the variable scheme
for any extra devices.
2/ the /DEVFS approach.. the kernel creates the devices purely as it finds them
and assignes names that are descriptive of WHERE it found them.
Needs devfs, and I've just scrapped my 3rd try at it..
3/ the /dev/scsi approach (aka the 'Peter (dufault) Principle' :)
looks promising but unfortunatly, doesn't allow vnode locking between
(say) /dev/rsd0d and /dev/scsi/dev3-lun0-part4 (for want of a better name).
because they are different vnodes..
> Some of this is present in sys/scsi/su.c, but there are a few things
> that have to be decided before it is complete.
>
> For example, ID 3 is a fujitsu drive:
>
> > hda.com# ls -lt /dev/rsd2d
> > crw-r----- 1 root operator 13, 19 Sep 26 00:01 /dev/rsd2d
> > hda.com#
> > hda.com# scsi -f /dev/rsd2d -c "12 0 0 0 64 0" -i 64 "s8 z8 z16"
> > FUJITSU M2654S-512
(neat!)
>
> and I can access it through a fixed device with the SCSI ID
> embedded in the minor number (no, the man page isn't
> checked in on how the minor number format):
>
> > hda.com# mknod /dev/scsi/id3 c 18 458755
> > hda.com# scsi -f /dev/scsi/id3 -c "12 0 0 0 64 0" -i 64 "s8 z8 z16"
> FUJITSU M2654S-512
>
yeah I read your code... sneaky....
> > hda.com# mknod /dev/scsi/sd/rsd3 c 18 458758
> > hda.com# mknod /dev/scsi/sd/sd3 b 18 458758
major 18 for both blk and char?
> > hda.com# fsck -n /dev/scsi/sd/rsd3
> > ** /dev/scsi/sd/rsd3 (NO WRITE)
> > ** Last Mounted on /mnt2
> > ** Phase 1 - Check Blocks and Sizes
> > ^Chda.com#
>
> However, this does it through the minor numbers and not config.
>
> If you look in scsi/su.c (an unfortunate name that should be changed to
> fx.c for "fixed devices" before 2.1)
well, things change.. I'm not sure about fx.. (hmm we need a better name..
dscsi? (direct scsi) or ds? or ....?
> you'll see that you can go from
> (BUS,ID,LUN) to
> underlying device, so if config is modified to build up a mapping
> table then you are almost done.
>
> However, we have to consider the problem of booting an old kernel
> and having the same problem Heikki mentions, namely, the new sd0
> is scsi id3 or something and we mount on top of it and trash the
> disk.
how many really old kernels do people run? particularly after
a revision upgrade?
>
> The same problem exists with the multiple host adapters: Currently
> they are "counting" host adapters also, and adding a host adapter
> with a disk will potentially trash your system.
>
we could assign scsi-bus numbers to specific devices same as Net BSD
assigns devices to TARG..
e.g.
bus scbus0 at bt0
bus scbus1 at bt1
bus scbus2 at aha0
> Some thoughts:
>
> 1. Keep the current "auto counting" devices exactly as they are.
auto counting is really good for many cases.. particularly when first
setting up the system, and we don't know what's going to be where.....
(or for quickly adding a new drive that we didn't know we were going to get,)
etc.
> 2. Add "config'd" devices as a new facility, almost
> as Garrett proposed once before except they need new names:
>
> controller scbus0 at aha0
> controller scbus1 at ncr0
yes! but if we leave these out, it get's 'auto-added' (as in NetBSD)
> disk ssd0 at scbus0 target 0 unit 0
> disk ssd1 at scbus1 target 0 unit 0
ah-ha! yes.. looks good, now how do we impliment it?
> tape sst0 at scbus0 target 5
> device sch0 at scbus1 target 4
> disk scd0 at scbus1 target 5
and as netBSD have.....
disk ssd0 at scbus ? target ? lun ?
remember we may find more devices than those preconfigured..
Might I also add the following suggestion..
under OSF/1 on the PC. the boot code, has been modified to load
2 files, rather than just the kernel..
it loads a kernel, yes, but it also loads a configuration file.
the configuration file is an ascii text file, that contains such things
as MAXUSERs etc... I don't see why we couldn't do similar..
that way we could have file called /config
with:
> controller scbus0 at aha0
> controller scbus1 at ncr0
> disk ssd0 at scbus0 target 0 unit 0
> disk ssd1 at scbus1 target 0 unit 0
> tape sst0 at scbus0 target 5
> device sch0 at scbus1 target 4
> disk scd0 at scbus1 target 5
(or something similar)
if the other file doesn't exist, the scsi code could just default to
autocounting.. that way the kernel wouldn't need to know in advance
about such things.... sort of the best of both worlds, and if we could make the kernel dump out it's config (lsdev?) in teh same format, then we could freeze
a config by simply doing
scsi -r (reprobe scsi bus for new devices)
lsdev -c >/config
>
> These have to be new devconf entries to avoid the "reboot old kernel
> and trash your system" problem, and can have new device entry points
> such as /dev/scsi/sd and so on.
not sure what you mean by this
>
> This will mean there will be three ways to get at a single scsi device:
>
> 1. Current "auto counting" devices;
> 2. Current "fixed" devices with target embedded in the minor number
> 3. Completely new conf'd devices.
sure..
>
> Any thoughts?
yep, see above..
>
>
+----------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / On assignment
| / \ julian@tfs.com +------>x USA \ in a very strange
| ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country !
+- X_.---._/ USA+(510) 645-3137(wk) \_/ \\
v
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0rXwyY-0003vpC>