From: Douglas Gilbert [mailto:[EMAIL PROTECTED] writes:
All may not be lost. If a medium error occurs and the ASC and
ASCQ imply the sector could be read but
failed ECC then the READ LONG SCSI command should fetch the
block (plus ECC and other data). For example a Fujitsu MAM3184
returns 576
- Mount points it
to:
# /dev/sda5 5.3G 1.5G 3.6G 30% /usr
-Oorspronkelijk bericht-
Van: Salyzyn, Mark [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 1 februari 2005 4:15
Aan: Kit Gerrits
Onderwerp: RE: Disk errors
The controller does not appear to be busted; you have
-Oorspronkelijk bericht-
Van: Salyzyn, Mark [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 1 februari 2005 4:15
Aan: Kit Gerrits
Onderwerp: RE: Disk errors
The controller does not appear to be busted; you have a Volume and a
RAID-5. Are you missing an Array?
A two drive failure on a RAID-5 gives you
Salyzyn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Douglas Gilbert
Sent: Tuesday, February 01, 2005 7:44 AM
To: Kit Gerrits
Cc: linux-scsi@vger.kernel.org
Subject: Re: Disk Errors
Kit Gerrits wrote:
I have found 08:05 to correspond to /dev/sda5
.
Andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Douglas Gilbert
Sent: Tuesday, February 01, 2005 7:44 AM
To: Kit Gerrits
Cc: linux-scsi@vger.kernel.org
Subject: Re: Disk Errors
Kit Gerrits wrote:
I have found 08:05 to correspond to /dev/sda5
So there are two situations in which damaged blocks remain
accessible:
1) unrecoverable medium errors
...
What's the rationale behind leaving a damaged block accessible in the case
of an unrecoverable medium error? A possibility that someone might
actually be able to recover the data?
-
To: [EMAIL PROTECTED]
Cc: Kit Gerrits; linux-scsi@vger.kernel.org
Subject: Re: Disk Errors
So there are two situations in which damaged blocks remain
accessible:
1) unrecoverable medium errors
...
What's the rationale behind leaving a damaged block accessible in the
case
of an unrecoverable medium
for the info
Kit
-Oorspronkelijk bericht-
Van: Cress, Andrew R [mailto:[EMAIL PROTECTED]
Verzonden: maandag 31 januari 2005 15:46
Aan: Kit Gerrits; linux-scsi@vger.kernel.org
Onderwerp: RE: Disk errors
Kit,
With the growing size of disk drives, and a more sectors
allocated to reserve
-Oorspronkelijk bericht-
Van: Salyzyn, Mark [mailto:[EMAIL PROTECTED]
Verzonden: maandag 31 januari 2005 17:03
Aan: Kit Gerrits
Onderwerp: RE: Disk errors
You get tones of I/O error messages from the filesystem
driver once the device goes offline. You can check
/var/log/messages
, January 31, 2005 10:22 AM
To: Cress, Andrew R; linux-scsi@vger.kernel.org
Subject: RE: Disk errors
Andrew,
Thanks for explaining the initial vs grown error list.
Unfortunately, the tool itself monitors softwareRAID and SCSI devices.
This means that sgmode itself sees only the containers on the PERC
The PERC controller looks after bad block reassignment.
Sincerely -- Mark Salyzyn
-Original Message-
From: Kit Gerrits [mailto:[EMAIL PROTECTED]
Sent: Monday, January 31, 2005 11:44 AM
To: Salyzyn, Mark
Cc: linux-scsi@vger.kernel.org
Subject: RE: Disk errors
Indeed, I had an entire
But if the PERC (controller) handles disk errors, what could cause:
I/O Error Dev 08:05 Sector 529712
I would assume that this error is generated by the harddrive, but shouldn't
the controller catch SCSI errors (and relocate sectors automagically)?
Kit
SCSI relevant DMESG:
scsi0 : Adaptec
On Tue, Feb 01, 2005 at 12:41:13AM +0100, Kit Gerrits wrote:
But if the PERC (controller) handles disk errors, what could cause:
I/O Error Dev 08:05 Sector 529712
I would assume that this error is generated by the harddrive, but shouldn't
the controller catch SCSI errors (and relocate
@vger.kernel.org
Subject: RE: Disk errors
But if the PERC (controller) handles disk errors, what could cause:
I/O Error Dev 08:05 Sector 529712
I would assume that this error is generated by the harddrive, but shouldn't
the controller catch SCSI errors (and relocate sectors automagically)?
Kit
SCSI
14 matches
Mail list logo
