Date: Sun, 12 Oct 1997 09:45:15 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@FreeBSD.ORG Subject: Re: Trouble with dump on ncr Message-ID: <19971012094515.RT52487@uriah.heep.sax.de> In-Reply-To: <199710120615.AAA18578@pluto.plutotech.com>; from Kenneth Merry on Oct 12, 1997 00:15:56 -0600 References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth Merry wrote:
> FWIW, that's what the new CAM SCSI code does. The da (i.e. sd)
> driver does a read capacity upon open. If the read capacity returns with
> 0x04, 0x02 ("Logical unit not ready, initializing cmd. required"), the error
> recovery code issues a start unit command to the drive.
Hmm, why doing it at open time? Quite a number of people have been
asking for a disk auto-spindown in the past (for filesystems that are
seldom used). I'm using a crock of an auto-spindown in the od driver
(the device is spun down at close time, and spun up at open time), but
i think the more generic solution would be to trigger the spindown by
a period of disc inactivity. Then, simply try the next command, and
if the drive is not ready, attempt to start it, and retry.
Back to the original question: i've looked into the existing code, and
it seems to be not that simple to add a fallback scsi_start_unit()
there once a command failed with NOT READY. The code is too twisted.
Given that there's enough evidence that the existing scsi_start_unit()
call in sd_open() didn't work at all, does anybody mind me simply
removing this call? Sticking a START UNIT command into sd_attach()
might perhaps make some sense, in case it's not spinning at boot or
reconfigure time.
> One interesting thing about that, though.. Apparantly not all
> drives return 0x04,0x02 when they aren't spun up. I ran into some Quantum
> Fireball ST (Stratus) drives that return 0x04,0x0b when they aren't spun
> up. Strange, 'eh? That sense code qualifier isn't in the SCSI specs (not
> even SCSI-3), and it isn't in Quantum's documentation on the drive.
Quantum seems to be the Microsoft of the SCSI vendors. They are proud
of this kind of crap. They have once been telling my colleague with
much pride that they don't support customer disk formatting even for
their SCSI drives (the colleague was asking for an IDE drive which
he's accidentally dropped on the floor), but only fake it there by
sitting for a couple of minutes upon receipt of a FORMAT UNIT command.
One of the disks of sax.sax.de (a Quantum LPS540) recently logged a
medium error, with a vendor-specific ASC (0xaa). Why the heck do they
require a vendor-specific ASC if there are dozens of ASC/ASCQ pairs
available already? I can understand the need for vendor-specific
things for stuff like a CD-R, but not for a plain disk drive.
I usually avoid Quantum like the plague. With a Seacrate drive, i
know what i've got. It works, or it fails. If it fails, chances are
good that i can repair it by reformatting, but i've been warned. With
a Quantum, i'm at my own once something unforseeable happens.
Speaking about opinions: apart from the weird behaviour with tagged
commands, and a START UNIT command, does anybody have seen any
complaints about the IBM drives so far? I'm pleasently surprised
about the new drive i've got. It's got a good bang-per-buck ratio
(maybe that's for being produced in Hungary?, so still cheap enough,
but not too much customs fees?), is surprisingly fast for a 5400 rpm
drive (8.5 MB dd(1) rate on the outer tracks), is fairly quiet, and
stays really cool.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971012094515.RT52487>