On Monday August 28, [EMAIL PROTECTED] wrote:
This might be a dumb question, but what causes md to use a large amount of
cpu resources when reading a large amount of data from a raid1 array?
I assume you meant raid5 there.
md/raid5 shouldn't use that much CPU when reading.
It does use more
Hi,
I'm not sure if this is the right place to ask this question, but a
Google search didn't turned out anything relevant, so I'm taking a
chance here.
I have my root on software raid on Debian and every night, cron is
sending me this error:
-
Subject: Cron [EMAIL PROTECTED] [ -x
On Mon, 2006-09-04 at 15:12 +1000, Neil Brown wrote:
It this repeatable?
100% repeatable.
Does the checksum stay wrong?
Yes, once they have changed to the bad value, they don't move again that
I've seen (done several trials over the past few days).
If you stop the array and run 'mdadm -E'
Tuomas Leikola [EMAIL PROTECTED] writes:
On 9/3/06, Tuomas Leikola [EMAIL PROTECTED] wrote:
Possibly safer to recreate with two missing if you aren't sure of the
order. That way you can look in the array to see if it looks right,
or if you have to try a different order.
I'd say it's safer
Mark Smith wrote:
Just a note, I've noticed this problem too. I run a RAID1 check once
every 24 hours, and while developing the script to do it, noticed that
the machine became virtually unusable - mouse was jumpy, typing lagged.
I run this check every morning at 4.00am so I'm usually
Michael Tokarev wrote:
Tuomas Leikola wrote:
[]
Here's an alternate description. On first 'unrecoverable' error, the
disk is marked as FAILING, which means that a spare is immediately
taken into use to replace the failing one. The disk is not kicked, and
readable blocks can still be used to
Ralf Herrmann wrote:
Dear Mr.Brown,
Yes.. you are hitting some pretty serious BUGs. And this is in
code that is not specific to RAID at all, so if there really were bugs
there, we would expect to have seen them well before now.
Your are absolutely right, it doesn't seem to be in RAID
Rob Bray wrote:
This might be a dumb question, but what causes md to use a large amount of
cpu resources when reading a large amount of data from a raid1 array?
Examples are on a 2.4GHz AMD64, 2GB, 2.6.15.1 (I realize there are md
enhancements to later versions; I had some other unrelated
[EMAIL PROTECTED] wrote:
I don't think the processor is saturating. I've seen reports of this
sort of thing before and until recently had no idea what was happening,
couldn't reproduce it, and couldn't think of any more useful data to
collect.
Well I can reproduce it easily enough.
Gordon Henderson wrote:
On Thu, 24 Aug 2006, Adam Kropelin wrote:
Generally speaking the channels on onboard ATA are independant with any
vaguely modern card.
Ahh, I did not know that. Does this apply to master/slave connections on
the same PATA cable as well? I know zero about
Richard Scobie wrote:
Has anyone had any experience or comment regarding linux RAID over
ieee1394?
As a budget backup solution, I am considering using a pair of 500GB
drives, each connected to a firewire 400 port, configured as a linear
array, to which the contents of an onboard array will
Doug Ledford wrote:
On Mon, 2006-08-21 at 17:35 +1000, Neil Brown wrote:
Buffer I/O error on device sde3, logical block 1793
This, on the other hand, might be a problem - though possibly only a
small one.
Who is trying to access sde3 I wonder. I'm fairly sure the kernel
wouldn't
Alternatives would be to have two such backup devices, and configure
them, as andy liebman wrote:
I may not have been clear what I was asking. I wanted to know if you
can make DISK IMAGES -- for example, with a program like Norton Ghost
or Acronis True Image (better) -- of EACH of the two
adam radford wrote:
Jim,
Can you try the attached (and below) patch for 2.6.17.11?
Don't you want the sleep BEFORE setting the new value? ie. giving a wait
for status to change before checking it again?
Also, please make sure you are running the latest firmware.
Thanks,
-Adam
diff
Alan Cox wrote:
Ar Iau, 2006-08-24 am 07:31 -0700, ysgrifennodd Marc Perkel:
So - the bottom line answer to my question is that unless you are
running raid 5 and you have a high powered raid card with cache and
battery backup that there is no significant speed increase to use
hardware raid.
Bill Davidsen wrote:
Alan Cox wrote:
Ar Iau, 2006-08-24 am 07:31 -0700, ysgrifennodd Marc Perkel:
So - the bottom line answer to my question is that unless you are
running raid 5 and you have a high powered raid card with cache and
battery backup that there is no significant speed
Bill Davidsen wrote:
It should work, but I don't like it... it leaves you with a lot of
exposure between backups.
Unless your data change a lot, you might consider a good incremental
dump program to DVD or similar.
Thanks. I have abandoned this option for various reasons, including
On Mon, 2006-09-04 at 12:00 -0400, Josh Litherland wrote:
I'll test to see if they actually change values, but I can say for
certain that they are still invalid checksum, i.e. once I stop the array
I have to assemble it with -U resync to get it back online. (and it of
course rebuilds)
Some
This one will really curl your hair. So, operating with the knowledge
that the checksum's state of correctness or incorrectness was changing
all the time, I did this:
while [ $? != 0 ] ; do
mdadm -A /dev/md0 /dev/sd[abcd]1
done
after 1,518 trials it successfully assembled.
*beats head
I'd like to note that the symptoms include not even being
able to *type* at the console, which I thought was all in-kernel
code, not subject to being swapped out. But whatever.
Really? Or is it just that you can type but the characters don't get
echoed. The type part is in the kernel, but
Hi Bill,
On Mon, 04 Sep 2006 12:42:53 -0400
Bill Davidsen [EMAIL PROTECTED] wrote:
Mark Smith wrote:
Just a note, I've noticed this problem too. I run a RAID1 check once
every 24 hours, and while developing the script to do it, noticed that
the machine became virtually unusable -
On Monday September 4, [EMAIL PROTECTED] wrote:
This one will really curl your hair. So, operating with the knowledge
that the checksum's state of correctness or incorrectness was changing
all the time, I did this:
while [ $? != 0 ] ; do
mdadm -A /dev/md0 /dev/sd[abcd]1
done
On Tue, 2006-09-05 at 07:35 +1000, Neil Brown wrote:
Something is SERIOUSLY wrong.
As it affects all drives, I suspect the drives are fine.
As that machine doesn't crash instantly, I suspect the cpu/memory is
fine.
Which leaves the controller and cables.
for i in `seq 1 20`; do
dd
On Tue, 2006-09-05 at 07:35 +1000, Neil Brown wrote:
Try
for i in `seq 1 20`; do
dd if=/dev/sda of=/tmp/try-$i conv=direct
done
for i in `seq 2 20`; do
cmp -l /tmp/try-1 /tmp/try=$i
done
I tried a variant of this:
for i in `seq 1 20`; do
dd if=/dev/sda1 of=/tmp/try-$i
On Monday September 4, [EMAIL PROTECTED] wrote:
Hi,
I'm not sure if this is the right place to ask this question, but a
Google search didn't turned out anything relevant, so I'm taking a
chance here.
I have my root on software raid on Debian and every night, cron is
sending me this
On Mon, 2006-09-04 at 17:46 -0400, Josh Litherland wrote:
I've only used it for a couple days, but never got any read errors or invalid
file problems.
Feh, disregard that. I've beaten it up some more, and occasional errors
are cropping up. Bad card. Nothing more to see here, move along.
On Monday September 4, [EMAIL PROTECTED] wrote:
On Mon, 2006-09-04 at 17:46 -0400, Josh Litherland wrote:
I've only used it for a couple days, but never got any read errors or
invalid file problems.
Feh, disregard that. I've beaten it up some more, and occasional errors
are cropping
Josh Litherland wrote:
Feh, disregard that. I've beaten it up some more, and occasional errors
are cropping up. Bad card. Nothing more to see here, move along.
It would be good to have an analog to memtest but for PATA and SATA
ports. Anyone seen something like that out there on the web?
28 matches
Mail list logo
