Date: Fri, 2 Jun 2000 22:44:04 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: John <papalia@udel.edu> Cc: Mike Smith <msmith@FreeBSD.ORG>, John Lengeling <johnl@raccoon.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: Dying connection? Message-ID: <20000602224404.A7506@panzer.kdm.org> In-Reply-To: <4.3.1.2.20000603004007.00ae3100@mail.udel.edu>; from papalia@udel.edu on Sat, Jun 03, 2000 at 12:41:08AM -0400 References: <4.3.1.2.20000603003152.00adfbd0@mail.udel.edu> <4.3.1.2.20000602013902.00ae1330@mail.udel.edu> <Your <4.3.1.2.20000602012826.00ad4e90@mail.udel.edu> <200006020538.WAA01381@mass.cdrom.com> <4.3.1.2.20000602013902.00ae1330@mail.udel.edu> <20000601235026.A98092@panzer.kdm.org> <4.3.1.2.20000603003152.00adfbd0@mail.udel.edu> <20000602223457.A7354@panzer.kdm.org> <4.3.1.2.20000603004007.00ae3100@mail.udel.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 03, 2000 at 00:41:08 -0400, John wrote:
> > > >So you probably don't need to add anything to your kernel config file,
> > > >unless you don't have the pass(4) driver configured. (You can't get the
> > > >defects list off the drive with camcontrol(8) without it.)
> > >
> > > So, to address curiosity, I recompiled with the pass device in the
> > > kernel. Now, using "camcontrol defects -f phys -P", I get the following
> > > nice long list. Does it mean anything in the end run? Also, from within
> > > the Adaptec SCSI bios, if I run their "media check", all turns up ok.
> >
> >The -P argument to the defects subcommand gives you the permanent defect
> >list, which is created at the factory. It is a list of blocks that were
> >bad when the disk was manufactured. Your list is fairly short.
> >
> >If you use the -G argument, you get the grown defect list, which is the
> >list if defects that have popped up since the drive left the factory. If
> >you use both -P and -G, you'll get both lists at the same time.
>
> Ah..... ok. My mistake. Retrying, I get:
>
> merlin# camcontrol defects -f phys -G
> Got 0 defects.
>
> So now, is that a good thing, or a bad thing?
It's good, probably. You might have defects, but the drive may not have
remapped them.
> And does that ultimately take
> into account all errors encountered since the drive left the factory, but
> before I configure the "pass" device?
It includes all remapped blocks since the drive left the factory. The pass
device doesn't affect it.
You'll probably want to make sure you've got read and write reallocation
turned on for the drive. To check it:
{panzer:/usr/home/ken:1:0} camcontrol modepage da1 -m 1
AWRE (Auto Write Reallocation Enbld): 1
ARRE (Auto Read Reallocation Enbld): 1
[ ... ]
Those two parameters should be set to 1. They tell the drive to
automatically remap a bad block to a spare sector when it finds the block
on either a read or a write.
As a practical matter, I think it's probably easier for the drive to remap
on a write, since it already has the "good" data that is supposed to go
into that particular block. On a read, it's trying to get the data, and
therefore may not be able to remap the block since it can't get good data
for the block. (If it can detect that the block is starting to go bad,
from ECC information or something similar, it may be able to salvage it on
a read.)
If read and write reallocation aren't enabled, you'll probably want to
enable them, using the following command:
camcontrol modepage da1 -m 1 -P 3 -e
(obviously, use daN, where daN is the drive in question)
Change the above two bits from 0 to 1.
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000602224404.A7506>