r RAID1 by telling the driver not to retry on failures and giving some
weight to read errors for failing the array. Hopefully, Neil is still
mulling it over and it or something similar will eventually make it into
the main line kernel as a solution for this problem.
--
Mike Accetta
ECI Tele
ing in any drive specs to begin with. Read-ahead
seems to be the closest concept.
> Thanks. I agree that we do need something along these lines. It
> might be a while before I can give the patch the brainspace it
> deserves as I am travelling this fortnight.
Looking forward to fu
n which came up with some even better approach.
Mike Accetta
ECI Telecom Ltd.
Transport Networking Division, US (previously Laurel Networks)
---
diff -Naurp 2.6.20/drivers/md/md.c kernel/drivers/md/md.c
--- 2.6.20/drivers/md/md.c 2007-06-04 13:52:42.0 -0400
+++ kernel/drivers/md/m
if (j >= 0)
mddev->resync_mismatches +=
r1_bio->sectors;
- if (j < 0 || test_bit(MD_RECOVERY_CHECK,
&mddev->recovery)) {
+ if (j < 0 || (test_bit(MD_RECOVERY_CHEC
,
I still don't see the path that would update 'corrected_errors' in this
case. There are only two raid1.c sites that touch 'corrected_errors', one
is in fix_read_errors() and the other is later in sync_request_write().
With my limited understanding of how this all works, neither o
llel /sys file that would report
all errors, not just the corrected ones. Does this seem reasonable?
Are there other alternatives that might make sense here?
--
Mike Accetta
ECI Telecom Ltd.
Transport Networking Division, US (previously Laurel Networks)
-
To unsubscribe from this list: send the lin
t;turn off RAID" do you mean to not even bring up the disk
as a degraded array? If all you do is fail and remove the partition, RAID is
actually still running to manage the single remaining partition, but I would
expect that overhead to be minimal.
--
Mike Accetta
ECI Telecom Ltd.
Transport Net
n this case. Hopefully,
someone more knowledgeable will comment soon.
--
Mike Accetta
ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majo
break;
+ } else {
+ j = 0;
+ }
if (j >= 0)
mddev->resync_mismatches +=
r1_bio->sectors;
if (j < 0 || t
close(mdfd);
+ }
}
}
break;
--
Mike Accetta
ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More
H. Peter Anvin wrote:
Mike Accetta wrote:
I've been considering trying something like having the re-sync algorithm
on a whole disk array defer the copy for sector 0 to the very end of the
re-sync operation. Assuming the BIOS makes at least a minimal
consistency
check on sector 0 b
Bill Davidsen wrote:
Gabor Gombas wrote:
On Fri, Mar 02, 2007 at 09:04:40AM -0500, Mike Accetta wrote:
Thoughts or other suggestions anyone?
This is a case where a very small /boot partition is still a very good
idea... 50-100MB is a good choice (some initramfs generators require
Gabor Gombas wrote:
On Fri, Mar 02, 2007 at 09:04:40AM -0500, Mike Accetta wrote:
Thoughts or other suggestions anyone?
This is a case where a very small /boot partition is still a very good
idea... 50-100MB is a good choice (some initramfs generators require
quite a bit of space under /boot
plication which is x86-based.
Thoughts or other suggestions anyone?
--
Mike Accetta
ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
Mor
even if it had been possible to find out what md files were holders of
the removed block device to begin with. Do I have the details right?
Any new thoughts in the last few months about how it would be best to
solve this problem?
--
Mike Accetta
ECI Telecom Ltd.
Data Networking Division (pr
level seem to imply
that the array isn't completely usable until the assembly file
descriptor is closed, even on return from the ioctl(), and hence the
kernel add_disk() isn't having the desired partitioning side effect at
the point it is being invoked.
This is all with kernel
16 matches
Mail list logo
