From owner-freebsd-hackers Thu Jan 26 10:49:52 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA00852 for hackers-outgoing; Thu, 26 Jan 1995 10:49:52 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA00831 for ; Thu, 26 Jan 1995 10:49:43 -0800 Received: (dufault@localhost) by hda.com (8.6.9/8.3) id JAA04537; Thu, 26 Jan 1995 09:06:57 -0500 From: Peter Dufault Message-Id: <199501261406.JAA04537@hda.com> Subject: Re: kern/189: sd renames disks To: hsu@fx7.cs.hut.fi Date: Thu, 26 Jan 1995 09:06:56 -0500 (EST) Cc: freebsd-hackers@freefall.cdrom.com In-Reply-To: <199501260150.RAA10377@freefall.cdrom.com> from "Heikki Suonsivu" at Jan 25, 95 05:50:01 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3628 Sender: hackers-owner@FreeBSD.org Precedence: bulk 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: > 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 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 > hda.com# mknod /dev/scsi/sd/rsd3 c 18 458758 > hda.com# mknod /dev/scsi/sd/sd3 b 18 458758 > 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) 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. 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. Some thoughts: 1. Keep the current "auto counting" devices exactly as they are. 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 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 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. 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. Any thoughts? P.S.: I use the fixed devices to access my tape drives. I don't mount my disks on them (mostly because I then can't boot old kernels) and thus don't consider that facility adequately tested. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 -- Formerly hd@world.std.com. E-mail problems? Tell hdslip@iii.net