os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Overhaul some bitrot in the SCSI section:

Browse source 
- shiny new drives are a bit bigger than 2GB these days
- move from st and sd devices to sa and da
- change a few stale references to files in /sys/scsi with /sys/cam/scsi
- bump typical rotational speeds by one generation; introduce 15,000RPM
- mention Ultra160 and Ultra320
- Make the reference to the SCSI-FAQ a true hyper link

There still is a lot to do, like describing CAM in the "SCSI subsystem
design" chapter, fixing some wording about "rogue" devices, which I
think are requiring "quirk" entries. I'm no expert in this field, so
leave it for a SCSI guru.

Discussed with and "go ahead" by:	wilko
This commit is contained in:
Jens Schweikhardt 2002-06-09 12:25:29 +00:00
parent a42324fb16
commit 88c2d34a1d
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=13348
1 changed files with 60 additions and 48 deletions
Download patch file Download diff file Expand all files Collapse all files

108
en_US.ISO8859-1/articles/storage-devices/article.sgml
View file

@ -534,11 +534,13 @@ disk wd3 at wdc1 drive 1</programlisting>
<para>Generally speaking, the chances of getting a working set of
devices on a single bus is better when all the devices are SCSI-2 or
newer. This implies that you do not have to dump all your old stuff
when you get that shiny 2GB disk: I own a system on which a pre-SCSI-1
when you get that shiny 80GB disk: I own a system on which a pre-SCSI-1
disk, a SCSI-2 QIC tape unit, a SCSI-1 helical scan tape unit and 2
SCSI-1 disks work together quite happily. From a performance
standpoint you might want to separate your older and newer (=faster)
devices however.</para>
devices however. This is especially advantageous if you have an
Ultra160 host adapter where you should separate your U160 devices
from the Fast and Wide SCSI-2 devices.</para>
<sect2>
<title>Components of SCSI</title>
@ -968,13 +970,13 @@ disk wd3 at wdc1 drive 1</programlisting>
when booting. An example from one of my systems:</para>
<screen>aha0 targ 0 lun 0: &lt;MICROP 1588-15MB1057404HSP4&gt;
sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512</screen>
da0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512</screen>
<para>Newer kernels usually do not report this information.
e.g.</para>
<screen>(bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2
sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)</screen>
da0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)</screen>
<para>Why has this changed?</para>
@ -1003,9 +1005,10 @@ sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)</screen>
<para>On top of the card drivers there are a number of more generic
drivers for a class of devices. More specific: a driver for tape
devices (abbreviation: st), magnetic disks (sd), CDROMs (cd) etc.
devices (abbreviation: sa, for serial access),
magnetic disks (da, for direct access), CDROMs (cd) etc.
In case you are wondering where you can find this stuff, it all
lives in <filename>/sys/scsi</filename>. See the man pages in
lives in <filename>/sys/cam/scsi</filename>. See the man pages in
section 4 for more details.</para>
<para>The multi level design allows a decoupling of low-level bit
@ -1071,15 +1074,15 @@ controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr
# Map SCSI buses to specific SCSI adapters
controller scbus0 at ahc0
controller scbus2 at ncr0
controller scbus2 at ncr0
controller scbus1 at uha0
# The actual SCSI devices
disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0]
disk sd1 at scbus0 target 1 [implicit LUN 0 if omitted]
disk sd2 at scbus1 target 3 [SCSI disk on the uha0]
disk sd3 at scbus2 target 4 [SCSI disk on the ncr0]
tape st1 at scbus0 target 6 [SCSI tape at target 6]
disk da0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0]
disk da1 at scbus0 target 1 [implicit LUN 0 if omitted]
disk da2 at scbus1 target 3 [SCSI disk on the uha0]
disk da3 at scbus2 target 4 [SCSI disk on the ncr0]
tape sa1 at scbus0 target 6 [SCSI tape at target 6]
device cd0 at scbus? [the first ever CDROM found, no wiring]</programlisting>
<para>The example above tells the kernel to look for a ahc (Adaptec
@ -1094,7 +1097,7 @@ device cd0 at scbus? [the first ever CDROM found, no wiring]<
allocated the unit number one greater than the highest
<quote>wired down</quote> unit number for that kind of device. So,
if you had a SCSI tape at target ID 2 it would be configured as
st2, as the tape at target ID 6 is wired down to unit number
sa2, as the tape at target ID 6 is wired down to unit number
1.</para>
<note>
@ -1114,7 +1117,7 @@ device cd0 at scbus? [the first ever CDROM found, no wiring]<
which device.</para>
<para>A kernel built to the config file below will attach the first
SCSI disk it finds to sd0, the second disk to sd1 etc. If you ever
SCSI disk it finds to da0, the second disk to da1 etc. If you ever
removed or added a disk, all other devices of the same type (disk
in this case) would <quote>move around</quote>. This implies you have to
change <filename>/etc/fstab</filename> each time.</para>
@ -1137,14 +1140,14 @@ controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seai
controller scbus0
device sd0 [support for 4 SCSI harddisks, sd0 up sd3]
device st0 [support for 2 SCSI tapes]
device da0 [support for 4 SCSI harddisks, da0 up da3]
device sa0 [support for 2 SCSI tapes]
[for the CDROM]
device cd0 #Only need one of these, the code dynamically grows</programlisting>
<para>Both examples support SCSI disks. If during boot more devices
of a specific type (e.g. sd disks) are found than are configured
of a specific type (e.g. da disks) are found than are configured
in the booting kernel, the system will simply allocate more
devices, incrementing the unit number starting at the last number
<quote>wired down</quote>. If there are no <quote>wired
@ -1194,10 +1197,10 @@ device cd0 #Only need one of these, the code dynamically grows</pro
cartridge tape units:</para>
<screen>Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: &lt;TANDBERG TDC 3600 -06:&gt;
Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue
Feb 25 21:03:34 yedi /kernel: sa0: Tandberg tdc3600 is a known rogue
Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: &lt;ARCHIVE VIPER 150 21247-005&gt;
Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
Mar 29 21:16:37 yedi /kernel: sa1: Archive Viper 150 is a known rogue </screen>
<para>For instance, there are devices that respond to all LUNs on a
certain target ID, even if they are actually only one device. It
@ -1210,8 +1213,8 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
Because the INQUIRY response also includes the version number of
the device firmware, it is even possible that for different
firmware versions different workarounds are used. See e.g.
<filename>/sys/scsi/st.c</filename> and
<filename>/sys/scsi/scsiconf.c</filename> for more info on how
<filename>/sys/cam/scsi/scsi_sa.c</filename> and
<filename>/sys/cam/scsi/scsi_all.c</filename> for more info on how
this is done.</para>
<para>This scheme works fine, but keep in mind that it of course
@ -1236,23 +1239,25 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
<para>This means that any devices with LUNs != 0 are not normally
found during device probe on system boot. To work around this
problem you must add an appropriate entry in /sys/scsi/scsiconf.c
problem you must add an appropriate entry in /sys/cam/scsi
and rebuild your kernel.</para>
<para>Look for a struct that is initialized like below:</para>
<para>Look for a struct that is initialized like below:
(FIXME: which file? Do these entries still exist in this form
now that we use CAM?)</para>
<programlisting>{
T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A",
"mx1", SC_ONE_LU
}</programlisting>
<para>For you Mumbletech BRIDGE2000 that has more than one LUN, acts
<para>For your Mumbletech BRIDGE2000 that has more than one LUN, acts
as a SCSI disk and has firmware revision 123 you would add
something like:</para>
<programlisting>{
T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123",
"sd", SC_MORE_LUS
"da", SC_MORE_LUS
}</programlisting>
<para>The kernel on boot scans the inquiry data it receives against
@ -1372,14 +1377,14 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
device with debugging turned on for that device. If your device
does not even probe at startup, you may have to define the
address of the device that is failing, and the desired debug
level in <filename>/sys/scsi/scsidebug.h</filename>. If it
level in <filename>/sys/cam/cam_debug.h</filename>. If it
probes but just does not work, you can use the
&man.scsi.8; command to dynamically set a debug level to
it in a running kernel (if <literal>SCSIDEBUG</literal> is
&man.camcontrol.8; command to dynamically set a debug level to
it in a running kernel (if <literal>CAMDEBUG</literal> is
defined). This will give you <emphasis>copious</emphasis>
debugging output with which to confuse the gurus. See
<command>man 4 scsi</command> for more exact information. Also
look at <command>man 8 scsi</command>.</para>
<command>man camcontrol</command> for more exact information. Also
look at <command>man 4 pass</command>.</para>
</listitem>
</itemizedlist>
</sect2>
@ -1497,8 +1502,9 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
<para>On Usenet the newsgroups <ulink
url="news:comp.periphs.scsi">comp.periphs.scsi</ulink> and <ulink
url="news:comp.periphs">comp.periphs</ulink> are noteworthy places
to look for more info. You can also find the SCSI-Faq there, which
is posted periodically.</para>
to look for more info. You can also find the <ulink
url="http://scsifaq.org:9080/scsi_faq/scsifaq.html">SCSI-FAQ</ulink>
there, which is posted periodically.</para>
<para>Most major SCSI device and host adapter suppliers operate FTP
sites and/or BBS systems. They may be valuable sources of
@ -1552,37 +1558,39 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
<title>Rotational speed</title>
<para>Rotational speeds of SCSI drives sold today range from around
4,500RPM to 10,000RPM. Most of them are either 5,400RPM or
7,200RPM. Even though the 7,200RPM drives can generally transfer
data faster, they run considerably hotter than their 5,400RPM
4,500RPM to 15,000RPM. Most of them are either 7,200RPM or
10,000RPM, with 15,000RPM becoming affordable (June 2002).
Even though the 10,000RPM drives can generally transfer
data faster, they run considerably hotter than their 7,200RPM
counterparts. A large fraction of today's disk drive malfunctions
are heat-related. If you do not have very good cooling in your PC
case, you may want to stick with 5,400RPM or slower drives.</para>
case, you may want to stick with 7,200RPM or slower drives.</para>
<para>Note that newer drives, with higher areal recording densities,
can deliver much more bits per rotation than older ones. Today's
top-of-line 5,400RPM drives can sustain a throughput comparable to
7,200RPM drives of one or two model generations ago. The number
top-of-line 7,200RPM drives can sustain a throughput comparable to
10,000RPM drives of one or two model generations ago. The number
to find on the spec sheet for bandwidth is <quote>internal data
(or transfer) rate</quote>. It is usually in megabits/sec so
divide it by 8 and you will get the rough approximation of how much
megabytes/sec you can get out of the drive.</para>
<para>(If you are a speed maniac and want a 10,000RPM drive for your
<para>(If you are a speed maniac and want a 15,000RPM drive for your
cute little PC, be my guest; however, those drives become
extremely hot. Do not even think about it if you do not have a fan
blowing air <emphasis>directly at</emphasis> the drive or a
properly ventilated disk enclosure.)</para>
<para>Obviously, the latest 10,000RPM drives and 7,200RPM drives can
deliver more data than the latest 5,400RPM drives, so if absolute
<para>Obviously, the latest 15,000RPM drives and 10,000RPM drives can
deliver more data than the latest 7,200RPM drives, so if absolute
bandwidth is the necessity for your applications, you have little
choice but to get the faster drives. Also, if you need low
latency, faster drives are better; not only do they usually have
lower average seek times, but also the rotational delay is one
place where slow-spinning drives can never beat a faster one.
(The average rotational latency is half the time it takes to
rotate the drive once; thus, it is 3 milliseconds for 10,000RPM
rotate the drive once; thus, it is 2 milliseconds for 15,000RPM,
3ms for 10,000RPM
drives, 4.2ms for 7,200RPM drives and 5.6ms for 5,400RPM drives.)
Latency is seek time plus rotational delay. Make sure you
understand whether you need low latency or more accesses per
@ -1601,10 +1609,10 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
largest volume of cool air flowing around it. You may need to seal
some unwanted holes or add a new fan for effective cooling.</para>
<para>Another consideration is noise. Many 7,200 or faster drives
<para>Another consideration is noise. Many 10,000 or faster drives
generate a high-pitched whine which is quite unpleasant to most
people. That, plus the extra fans often required for cooling, may
make 7,200 or faster drives unsuitable for some office and home
make 10,000 or faster drives unsuitable for some office and home
environments.</para>
</sect3>
@ -1623,9 +1631,12 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
<sect3>
<title>Interface</title>
<para>The majority of SCSI hard drives sold today are Ultra or
Ultra-wide SCSI. The maximum bandwidth of Ultra SCSI is 20MB/sec,
and Ultra-wide SCSI is 40MB/sec. There is no difference in max
<para>The majority of SCSI hard drives sold today are Ultra,
Ultra-wide, or Ultra160 SCSI. As of this writing (June 2002),
the first Ultra320 host adapters and devices become available.
The maximum bandwidth of Ultra SCSI is 20MB/sec,
and Ultra-wide SCSI is 40MB/sec. Ultra160 can transfer 160MB/sec
and Ultra320 can transfer 320MB/sec. There is no difference in max
cable length between Ultra and Ultra-wide; however, the more
devices you have on the same bus, the sooner you will start having
bus integrity problems. Unless you have a well-designed disk
@ -1636,7 +1647,8 @@ Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue </screen>
for Fast-wide SCSI may not be a bad idea. That will have the same
max bandwidth as Ultra (narrow) SCSI, while electronically it is
much easier to get it <quote>right</quote>. My advice would be: if
you want to connect many disks, get wide SCSI drives; they usually
you want to connect many disks, get wide or Ultra160 SCSI drives;
they usually
cost a little more but it may save you down the road. (Besides,
if you can not afford the cost difference, you should not be building
a disk array.)</para>