I have found 08:05 to correspond to /dev/sda5, mounted as /usr(Thanks for
the pointer!).
Sda is the single-drive volume
(non-RAID, as it is only for the O/S,
which needs to be speedy and can be pulled from tape easily).
This explains several things:
A/ Why a single error can take an entire
Kit Gerrits wrote:
I have found 08:05 to correspond to /dev/sda5, mounted as /usr(Thanks for
the pointer!).
Sda is the single-drive volume
(non-RAID, as it is only for the O/S,
which needs to be speedy and can be pulled from tape easily).
This explains several things:
A/ Why a single error can
Good information for a single drive on a simple SCSI card. This will not
work for drives that are part of an array (volume) as /dev/sda
references a pseudo device. Besides, the firmware in the RAID controller
takes the actions necessary to perform recoverable bad block remaps.
Sincerely -- Mark
On Tue, Feb 01, 2005 at 02:11:48AM +, S Iremonger wrote:
I would like if anybody out there knwos why linux-2.6 (well, at
least 2.6.8.1 and 2.6.10) seems to have seagate as an
incomplete or experimental driver, at least that it
does not appear in the SCSI low level drivers list
On Tue, 1 Feb 2005, Matthew Wilcox wrote:
Actually, it's worse than that:
config SCSI_SEAGATE
tristate Seagate ST-02 and Future Domain TMC-8xx SCSI support
depends on X86 ISA SCSI BROKEN
The driver is marked as BROKEN so it's even a candidate for deletion unless a
maintainer
Kit,
If you have another (non-RAID) SCSI system, you could take the faulty
drive there to modify the mode pages to turn on AWRE and ARRE with
either sgmode (scsirastools.sf.net) or sginfo (sg3_utils).
Otherwise, you are dependent on the tools that are provided for the
PowerEdge RAID controller.
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?
-
James Smart pointed out that if you insert and remove a HBA driver a few
times, eventually the system oopses.
The reason is that the transport classes all kfree their attribute
containers, but don't actually unregister them first (so we have freed
memory on the container list). The attached
Salyzyn, Mark wrote:
An unrecoverable medium error is typically `corrected' when a write to
the block occurs. RAID cards will use the redundancy to calculate the
data and write it back to the offending drive for instance.
Otherwise, for none-redundant stores, bad media is as good as anything
to
On Tue, Jan 25, 2005 at 07:52:42PM -0500, Ju, Seokmann wrote:
Hello,
Here is a patch for megaraid_mbox 2.20.4.3 and megaraid_mm 2.20.2.5.
The patch includes following changes/fixes
- sysfs support for drive addition/removal
- Tape drive timeout issue
- Made some code static
I am
10 matches
Mail list logo
