Re: raid 1 - automatic 'repair' possible?

[Kiniger]

On Tue, Jan 18, 2005 at 10:46:05PM +0100, Lars Marowsky-Bree wrote:
> On 2005-01-18T22:18:01, "Kiniger, Karl (GE Healthcare)" <karl.kiniger@xxxxxxxxxx> wrote:
> 
> > idea for enhancement of software raid 1:
> > 
> > every time the raid determines that a sector cannot
> > be read it could at least try to overwrite the bad are
> > with good data from the other disk.
> 
> The idea is good and I'm sure we'll love to get a patch ;-)

Dont account on me as a coder  (absolutely no spare time
for the next couple of months)

some random thoughts:

nowadays hardware sector sizes are much bigger than 512 bytes and
the read error may affect some sectors +- the sector which actually
returned the error.

to keep the handling in userspace as much as possible: 

the real problem is the long resync time. therefore it would
be sufficient to have a concept of "defective areas" per partition
and drive (a few of them, perhaps four or so , would be enough) 
which will be excluded from reads/writes and some means to
re-synchronize these "defective areas" from the good counterparts
of the other disk. This would avoid having the whole partition being
marked as defective.

The repair could then be done in userspace given some kernel support.

There might be some corner cases though (e.g defective physical
sector spanning more than one partition) but I think they would be
rare.

Has anybody else had problems with the newer Maxtors
(200 GB and up) ? 

Karl

> 
> 
> Sincerely,
>     Lars Marowsky-Brée <lmb@xxxxxxx>
> 
> -- 
> High Availability & Clustering
> SUSE Labs, Research and Development
> SUSE LINUX Products GmbH - A Novell Business

-- 
Karl Kiniger   mailto:karl.kiniger@xxxxxxxxxx
GE Medical Systems Kretztechnik GmbH & Co OHG
Tiefenbach 15       Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/