At 14:56 Uhr +0200 07.04.1997, Allen Briggs wrote:
>Howdy...  I have a patch for the ncrscsi driver that might improve its
>reliability.  I was wondering if anyone is brave and willing to try it...

Been there, done that.

>I will be attempting to break it on some other SCSI devices, but I ran
>several punishing tests on my PB145's external drive with no failures.

I've seen...err...interesting things.

>To apply this patch, you will, of course, need to be compiling your own
>kernels, etc.  I would really like to know how this driver does on disks
>that it previously failed on.

I've run the test script

------------------------------------------------------------------
#!/bin/sh
#
# Copies a file again and again and verifies correct
# execution to trap drive faults

export PATH=/sbin:/bin:/usr/sbin:/usr/bin:.

a=$1
b=$a.copy
logfile="filecopy.log"

rm -f $logfile
touch $logfile

while true; do
        cp $a $b

# differences => return value <> 0
        cmp -l $a $b >> $logfile || date >> $logfile
        rm -f $b
done
------------------------------------------------------------------

on /tmp which is a mfs, on /var which is on a Quantum TRB850 and on / which
is on a Quantum LPS105S.

/tmp says something like

root:~/src/q105-test # l
total 1577
-r-x------  1 root  wheel   54811 Jun 24  1996 cmp
-rw-------  1 root  wheel       0 Apr 13 01:55 filecopy.log
                             ^^^^^
-rwx------  1 root  wheel     321 Jun 24  1996 filecopy.sh
-rwx------  1 root  wheel     265 Jun 24  1996 filecopy.sh~
-rw-------  1 root  wheel  762169 Apr 13 01:50 gunk
-rw-------  1 root  wheel  762169 Apr 13 01:51 gunk.copy
-rwx------  1 root  wheel     107 Jun 24  1996 lstest.sh
root:~/src/q105-test # ^

(which you would have expected ;), and so does /var (the TrailBlazer).

The LPS105 now, mounted on /, has other things to say:

root:~/src/q105-test # !hea
head filecopy.log
 16385 155 160
 16386 160  56
 16387  56 157
 16388 157 163
 16389 163  56
 16390  56 155
 16391 155 163
 16392 163  55
 16393  55 167
 16394 167 151

Notice an offset of 1 char between the original file and the copy, starting
at char 16385 which is a magic number and means an offset of 0x4000.

I haven't seen any fs damage so far, but I am going to reboot with a
different kernel soon.  =8)

>Thanks,
>-allen

You're welcome.

	hauke



--
"It's never straight up and down"     (DEVO)