Hi,
On 06-Aug-99 Marc SCHAEFER wrote:
> Karl-Heinz Herrmann <[EMAIL PROTECTED]> wrote:
>> Can relocating blocks cause short scsi blocks?
sorry I did a bad choice of words.... with "short scsi blocks" I didn't mean
short read blocks or blocks as in disk blocks at all.
I wanted to ask if block recovery of a HD drive can cause the scsi bus to be
busy -- longer then usual (and therefor "block it").
> No. However, depending on the setting of the PER bit in the error
> recovery mode page, uncorrectable read error and/or write errors
> can cause CHECK CONDITION, MEDIUM ERROR. But I would assume to
> have all the data transferred (write) and all data transferred (read)
> if data could be reallocated (and, in the case of read, if
> data could be corrected). If not, you don't get a RECOVERED ERROR
> sense, and you might get less data than expected. In that case
> Linux usually reports underrun errors (with good low-level drivers,
> such as ncr53c8xx), or reports an error, or just hangs.
Yes, usually the aic7xxx is complaining very loud if something with the data is
(or maybe) wrong. But it will recover most of the time.
>> By the way: The Samsung drive is configured for 16 retries on read/write
> 16 retries ? That could last an awful lot of times.
Thats default setting from manufactor -- I can't change it permanent.
The drive won't let me write it to the NVRAM.
> but with many drives, recovery action include recalibration,
> seeks, and 16 retries could well take enough to either make Linux
> timeout (and maybe reset while the CDR is disconnected which could
> make it destroy the CD it's writing),
I don't see any timeout in the log. Will I get the Recovered Error reported in
the usual log messages? Does this depend on the low-level driver (aic7xxx)?
> or *maybe* if the samsung drive
> doesn't disconnect for some reason when doing recovery, starve the
> other device.
Thats more like what I wanted to know. *Are* threre drives which won't
disconnect during recovery? They should disconnect, shouldn't they?
>> errors. If I set it to 1 and run badblocks it's dead after 1 minute and wont
>> be recognised on the scsi bus on reboot. A powercycle clears it again.
> Are you sure your power levels are enough ? I mean, I run usually my
> drives 1 retry (and none for verify mode page), and they do not
> die that easily.
I don't think it's power level, because I can run badblocks for hours in 16
retries (where it won't find most of the bad blocks) but it will die when it
hits the first bad blocks with 1 retry. What will a drive do when it want's to
relocate a bad block but hasn't a spare one?
The drive looks absolutely dead -- the ID is not answering any more and the
device get's thrown out during rescanning of the bus (later /dev/sdx names
actualy move) and after a hard reset (without powercycle) the drive won't be
there.
I know the drive is "bad" -- But is it the drives fault when scsi bus is busy
for a while or can it be something in the scsi drivers?
Karl-Heinz
----------------------------------------------------------
E-Mail: Karl-Heinz Herrmann <[EMAIL PROTECTED]>
Date: 09-Aug-99 Time: 14:44:23
----------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
