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 rem
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 shoul
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 remind one that the dat
Following regression tests on BK latest, two critical problems have
turned up in the SCSI subsystem:
1) Hang using REQ_BLOCK_PC on CD/DVD
2) oops in transport classes with multiple HBAs
Could we do a quick include of this tree:
bk://linux-scsi.bkbits.net/scsi-for-linus-2.6
to pick up fixes for
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
>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?
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.
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
>m
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
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 Sa
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 take
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 volume
12 matches
Mail list logo
