[1304] in linux-scsi channel archive
Re: Problems with MO-Drive
daemon@ATHENA.MIT.EDU (Michael Ulbrich)
Fri Jan 24 05:53:26 1997
Date: Fri, 24 Jan 97 11:02:41 +0100
From: mul@lab1033.berlin.ptb.de (Michael Ulbrich)
To: linux-scsi@vger.rutgers.edu
CC: mul@lab1033.berlin.ptb.de
On Mon Jan 20 23:07:35 1997 Jeffrey Templon wrote:
>I saw you mentioned the NCR chip. 2.0.0 kernel has a very buggy NCR
>driver. I managed to completely trash my disk subsystem by running
>it. I'd recommend kernel version 2.0.18 or higher.
>
> JT
Yeah, thanks Jeffrey, I upgraded to 2.0.28 and the NCR-SCSI bus hangs
are gone. The developers seem to have achieved a major improvement in
stability here, well done!
OTOH, there are still some strange things happening, which of course
are related to my unusual application, but here it goes (for those
who are interested):
Let me first describe my problem again: I'm reading (and only reading)
magneto-optical disks which are written in a non contiguous manner, i.e
valid (readable) sectors are randomly mixed with unreadable (maybe blank,
maybe containing some kind of filemark) sectors. I'm accessing the disk
on the raw level, there is no recognisable filesystem on the disk.
The program I wrote to access the disk tries to read single sectors
(512 bytes) and returns valid or invalid buffer data depending on the
return status of the fread() call.
First thing, which I don't understand is, if I start reading at, let's
say, sector 1000 and I know that this and the following sectors are
readable, while the preceding sectors (up to 999) are unreadable, why
does the syslog report a '...MEDIUM ERROR: sector 996'?? It shouldn't
access sector 996 at all!! This is annoying because all the retrying
and resetting, which goes on in the background, slows down the process
considerably.
Same thing happens if I read over alternating readable and unreadable
sectors. The whole process is slowed down tremendously. One explanation
for this slowing down could be, if the scsi subsystem would perform
read ahead of a predefined number of sectors, despite my access re-
quested only a _single_ sector. To verify this assumption I checked
the ioctl() interface with BLKRAGET and BLKRASET. BLKRAGET returned the
(default?) value of 120 and I succeeded to set the read ahead parameter
to 0 with BLKRASET, but nothing changed. The syslog goes on reporting
MEDIUM ERRORS on sectors which my program hasn't accessed yet, in this
case (opposite to the first example) with higher sector numbers.
But, to come to an end, basically I'm able to solve my problem with
the system upgraded to 2.0.28, so
thanks again ... Michael U.
