Following are two bugfixes for md in current kernels.
The first is suitable for -stable is it can allow drive errors
through to the filesystem wrongly.
Both are suitable for 2.6.22.
Thanks,
NeilBrown
[PATCH 001 of 2] md: Avoid a possibility that a read error can wrongly
propagate through
When a raid1 has only one working drive, we want read error to
propagate up to the filesystem as there is no point failing the last
drive in an array.
Currently the code perform this check is racy. If a write and a read
a both submitted to a device on a 2-drive raid1, and the write fails
During a 'resync' or similar activity, md checks if the devices in the
array are otherwise active and winds back resync activity when they
are. This test in done in is_mddev_idle, and it is somewhat fragile -
it sometimes thinks there is non-sync io when there isn't.
The test compares the total
On Wednesday May 9, [EMAIL PROTECTED] wrote:
Neil Brown [EMAIL PROTECTED] [2007.04.02.0953 +0200]:
Hmmm... this is somewhat awkward. You could argue that udev should be
taught to remove the device from the array before removing the device
from /dev. But I'm not convinced that you always
On Thu, 10 May 2007 16:22:31 +1000 NeilBrown [EMAIL PROTECTED] wrote:
The test currently looks for any (non-fuzz) difference, either
positive or negative. This clearly is not needed. Any non-sync
activity will cause the total sectors to grow faster than the sync_io
count (never slower) so
On Thursday May 10, [EMAIL PROTECTED] wrote:
On Thu, 10 May 2007 16:22:31 +1000 NeilBrown [EMAIL PROTECTED] wrote:
The test currently looks for any (non-fuzz) difference, either
positive or negative. This clearly is not needed. Any non-sync
activity will cause the total sectors to grow
On May 10 2007 16:22, NeilBrown wrote:
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c 2007-05-10 15:51:54.0 +1000
+++ ./drivers/md/md.c 2007-05-10 16:05:10.0 +1000
@@ -5095,7 +5095,7 @@ static int is_mddev_idle(mddev_t *mddev)
*
On Thursday May 10, [EMAIL PROTECTED] wrote:
On May 10 2007 16:22, NeilBrown wrote:
diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c2007-05-10 15:51:54.0 +1000
+++ ./drivers/md/md.c2007-05-10 16:05:10.0 +1000
@@ -5095,7 +5095,7 @@ static
On May 10 2007 20:04, Neil Brown wrote:
- if ((curr_events - rdev-last_events + 4096) 8192) {
+ if ((long)curr_events - (long)rdev-last_events 4096) {
rdev-last_events = curr_events;
idle = 0;
}
/* sync IO will cause
Neil Brown wrote:
On Wednesday May 9, [EMAIL PROTECTED] wrote:
Neil Brown [EMAIL PROTECTED] [2007.04.02.0953 +0200]:
Hmmm... this is somewhat awkward. You could argue that udev should be
taught to remove the device from the array before removing the device
from /dev. But I'm not convinced
Ronen Shitrit wrote:
The resync numbers you sent, looks very promising :)
Do you have any performance numbers that you can share for these set of
patches, which shows the Rd/Wr IO bandwidth.
I have some simple tests made with hdparm, with the results I don't
understand.
We see hdparm
On May 9 2007 18:51, Linus Torvalds wrote:
(But Andrew never saw your email, I suspect: [EMAIL PROTECTED] is probably
some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
What do the letters kp stand for?
Jan
--
-
To unsubscribe from this list: send the line
On Thu, 2007-05-10 at 16:51 +0200, Jan Engelhardt wrote:
(But Andrew never saw your email, I suspect: [EMAIL PROTECTED] is
probably
some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
What do the letters kp stand for?
Keep Patching ?
-
To unsubscribe from this list: send
Tomasz Chmielewski schrieb:
Ronen Shitrit wrote:
The resync numbers you sent, looks very promising :)
Do you have any performance numbers that you can share for these set of
patches, which shows the Rd/Wr IO bandwidth.
I have some simple tests made with hdparm, with the results I don't
On 5/10/07, Xavier Bestel [EMAIL PROTECTED] wrote:
On Thu, 2007-05-10 at 16:51 +0200, Jan Engelhardt wrote:
(But Andrew never saw your email, I suspect: [EMAIL PROTECTED] is
probably
some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
What do the letters kp stand for?
Heh
On Thursday 10 May 2007 09:12:54 Neil Brown wrote:
On Wednesday May 9, [EMAIL PROTECTED] wrote:
Neil Brown [EMAIL PROTECTED] [2007.04.02.0953 +0200]:
Hmmm... this is somewhat awkward. You could argue that udev should be
taught to remove the device from the array before removing the device
On May 9 2007 15:38, Jens Axboe wrote:
I am a mdadm/disk/hard drive fanatic, I was curious:
On i386, we can at most fit 256 scatterlist elements into a page,
and on x86-64 we are stuck with 128. So that puts us somewhere
between 512kb and 1024kb for a single IO.
How come 32bit is 256 and
On Thu, 10 May 2007 16:51:31 +0200 (MEST) Jan Engelhardt [EMAIL PROTECTED]
wrote:
On May 9 2007 18:51, Linus Torvalds wrote:
(But Andrew never saw your email, I suspect: [EMAIL PROTECTED] is probably
some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
What do the letters
Hi,
I created a MD-RAID5 array using 8 Maxtor SAS Disk Drives (chunk size is
256k). I have measured the data transfer speed for single SAS disk drive
(physical drive, not filesystem on it), it is roughly about 80~90MB/s.
However, I notice MD also reports the speed for the RAID5 array when it
On Thu, 10 May 2007, Liang Yang wrote:
Hi,
I created a MD-RAID5 array using 8 Maxtor SAS Disk Drives (chunk size is
256k). I have measured the data transfer speed for single SAS disk drive
(physical drive, not filesystem on it), it is roughly about 80~90MB/s.
However, I notice MD also
Could you please give me more details about this? What do you mean the fast
end and slow end part of disk? Do you mean the location in each disk
platter?
Thanks,
Liang
- Original Message -
From: Justin Piszcz [EMAIL PROTECTED]
To: Liang Yang [EMAIL PROTECTED]
Cc:
http://partition.radified.com/partitioning_2.htm
System and program files that wind up at the far end of the drive take
longer to access, and are transferred at a slower rate, which translates
into a less-responsive system. If you look at the graph of sustained
transfer rates (STRs) from the
On Thu, May 10 2007, Jan Engelhardt wrote:
On May 9 2007 15:38, Jens Axboe wrote:
I am a mdadm/disk/hard drive fanatic, I was curious:
On i386, we can at most fit 256 scatterlist elements into a page,
and on x86-64 we are stuck with 128. So that puts us somewhere
between 512kb and
On Thu May 10, 2007 at 05:33:17PM -0400, Justin Piszcz wrote:
On Thu, 10 May 2007, Liang Yang wrote:
Hi,
I created a MD-RAID5 array using 8 Maxtor SAS Disk Drives (chunk size is
256k). I have measured the data transfer speed for single SAS disk drive
(physical drive, not filesystem
Satyam Sharma wrote:
On 5/10/07, Xavier Bestel [EMAIL PROTECTED] wrote:
On Thu, 2007-05-10 at 16:51 +0200, Jan Engelhardt wrote:
(But Andrew never saw your email, I suspect: [EMAIL PROTECTED] is
probably
some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
What do the
On Thursday May 10, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
On Wednesday May 9, [EMAIL PROTECTED] wrote:
Neil Brown [EMAIL PROTECTED] [2007.04.02.0953 +0200]:
Hmmm... this is somewhat awkward. You could argue that udev should be
taught to remove the device from the array before
26 matches
Mail list logo
