On Sat, Aug 20, 2005 at 12:54:02PM +0100, Dieter wrote:
> > The problem is that we don't know what kind of interface we have:
> > if could be a PATA drive behind a SATA/PATA bridge (or, with a PATA
> > controller, we could also have a SATA drive behind a bridge).
> > In such a case, the bridge should snoop the SET_FEATURE command and
> > change its speed appropriately.
> 
> Yeah, the bridge issue came to mind *after* I had sent the message.
> 
> Perhaps a "don't downgrade speed due to error" flag in the config file,
> similar to the "use a lower speed than the device & controller claim" flags?

Well, this is already possible. Just wire the speed in the config file
using flags, and the kernel won't downgrade.

> Or an option to atactl or dkctl?

A way to control the speed via atactl would be nice, but I didn't get around
implementing it yet.

> I suspected this when trying to recover my scrambled PATA drive.
> 
> > The code doens't make a difference between read and write
> > (while a write would likely remap the bad sector). You can use
> > 'dkctl badsector' to see or flush this list. 
> > A dkctl badsector flush followed by a write to this sector should fix it.
> 
> The badsector option looks very useful, thank you!
> 
> Is there a way to get the disk's list of bad sectors?  I have vague memories
> of being able to do this back in the ST-506 days.

From the drive itself ? I don't think so, smart will only report how many
sectors have been remapped. dkctl can report the list of bad sectors
noticed by the kernel.

> 
> Meanwhile, the other new drive (same make and model, shipped in the same box,
> intended to become a RAID1 mirror) is looking okay so far:
> 
> dd if=/dev/rwd0c count=161507 bs=1512k of=/dev/null
> 161507+0 records in
> 161507+0 records out
> 250059350016 bytes transferred in 6657.544 secs (37560300 bytes/sec)
> 
> dd if=/dev/zero of=/dev/rwd0c count=161507 bs=1512k
> 161507+0 records in
> 161507+0 records out
> 250059350016 bytes transferred in 38300.036 secs (6528958 bytes/sec)
> 
> I was expecting write to be slower than read, but not this much slower.
> Is this typical, or do I have something wierd going on?

Maybe you have the write cache turned off ?

> 
> Would NCQ help on sequential writes?  The controller and disk both claim
> NCQ support, but I haven't found anything in NetBSD sources that looks
> like NCQ support (maybe I missed it?).

If you have the write cache turned off, NCQ may help (or may not, depending
on how the drive handles write cache and NCQ). NCQ is not implemented in
NetBSD yet (mostly because of lack of documentation of the interesting
controllers).

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--