Hey, that was quick ... thanks!
> 1) Where does the mismatch come from? The box hasn't been down since the
creation of
> the array.
Do you have swap on the mirror at all?
As a matter of fact I do, /dev/md0_p2 is a swap partition.
I recently discovered/realised that when 'swap' writes to a
Hello,
these questions apparently got buried in another thread, so here goes again ...
I have a mismatch_cnt of 384 on a 2-way mirror.
The box runs 2.6.17.4 and can't really be rebooted or have its kernel
updated easily
1) Where does the mismatch come from?
The box hasn't been down since the cr
Sorry to hijack the thread a little but I just noticed that the
mismatch_cnt for my mirror is at 256.
I'd always thought the monthly check done by the mdadm Debian package
does repair as well - apparently it doesn't.
So I guess I should run repair but I'm wondering ...
- is it safe / bugfree con
I think I'm leaning towards auto-creating names if they look like
standard names (or are listed in mdadm.conf?), but required
auto=whatever to create anything else.
The auto= option has the disadvantage that it is different for
partitionable and regular arrays -- is there no way to detect from t
with lvm you have to stop lvm before you can stop the arrays... i wouldn't
be surprised if evms has the same issue...
AFAIK there's no counterpart to evms_activate.
Besides, I'm no longer using EVMS, I just included it in my testing
since this issue bit me there first.
Thanks,
Christian
-
To
Are you sure that there's nothing left running from your initrd that
could be holding open, say, some block device that comprises part of
your RAID array?
No, I'm not sure. Both suitable ramdisk-creators in Debian (initramfs
and yaird) supposedly delete everything in the ram disk before
switchin
[This is a bit of a repost, because I'm slightly desperate :)]
I'm still having problems with some md arrays not shutting down
cleanly on halt / reboot.
The problem seems to affect only arrays that are started via an
initrd, even if they do not have the root filesystem on them.
That's all arrays
Based on various googled comments I have selected 'deadline' as the
elevator for the disks comprising my md arrays, with no further tuning
yet ... not so stellar :(
Basically concurrent reads (even just 2, even worse with 1 read + 1
write) don't work too well.
Example:
RAID1: I bulk-move some 9
Are there any actual bonuses to making RAIDs on whole raw disks?
Not if you're using regular md devices.
For partitionable md arrays using partitions seems a little strange to
me, since you then have partitions on a partition. That'd probably
make it difficult to just mount a single member of a
Why not just --set-faulty or --fail with mdadm?
This is not about testing, but about real errors.
1) I depend on the md layer to tell me if a disk is faulty ... failing
the disk manually would only help if I already knew the disk was
faulty and just wanted to remove it.
2) If the affected arra
For ICH5 and all other controllers (non-AHCI) of course, I've always seen
md mark it faulty on a bad disk/sector/etc.
ICH7 (ahci) does not. At least not a whole disk dieing, don't know
about bad sectors.
I thought you were just trying to mark it faulty manually for the purpose
of rebuilding it
I finally got around to testing 2.6.17.4 with libata-tj-stable-20060710.
Hardware: ICH7R in ahci mode + WD5000YS's.
EH: much, much better. Before the patch it seemed like errors were
only printed to dmesg but never handed up to any layer above. Now md
actually fails the disk when I pull the (pow
I'm (still) trying to setup a md array on the ICH7 SATA controller of
an Intel SE7230NH1-E with 4 WD5000YS disks.
On this controller (in ahci mode) I have not yet managed to get a disk
mark as failed.
- a bad cable just led to hangs and timeouts
- pulling the power on one of the SATA drives (whi
Nope, EVMS is not the culprit.
I installed the test system from scratch, EVMS nowhere in sight -- it
now boots successfully from a partitionable md array, courtesty of a
yaird-generated initrd I adapted for the purpose. Yay!
Or not. I get the "md: md_d0 still in use." error again :(
This is wit
It seems like it really isn't an md issue -- when I remove everything
to do with evms (userspace tools + initrd hooks) everything works
fine.
I took your patch back out and put a few printks in there ...
Without evms the "active" counter is 1 in an "idle" state, i. e. after the box
has finished b
Good morning!
That patch was against latest -mm For earlier kernels you want to
test 'ro'.
Ok. Was using stock 2.6.17.
> Done unmounting local file systems.
> *md: md0 stopped
> *md: unbind
> *md: export_rdev
> *[last two lines for each disk.]
> *Stopping RAID arrays ... done (1 array(s
How are you shutting down the machine? If something sending SIGKILL
to all processes?
First SIGTERM, then SIGKILL, yes.
You could try the following patch. I think it should be safe.
Hmm, it said chunk failed, so I replaced the line by hand. That didn't
want to compile because "mode" suppos
md is very dependant on the driver doing the right thing. It doesn't
do any timeouts or anything like that - it assumes the driver will.
md simply trusts the return status from the drive, and fails a drive
if and only if a write to the drive is reported as failing (if a read
fails, md trys to ove
I get these messages too on Debian Unstable, but since enabling the
bitmaps on my devices, resyncing is so fast that I don't even notice it
on booting.
Bitmaps are great, but the speed of the rebuild is not the problem.
The box doesn't have hotswap bays, so I have to shut it down to
replace a fa
May be your shutdown script is doing "halt -h"? Halting the disk
immediately without letting the RAID to settle to a clean state
can be the cause?
I'm using Debian as well and my halt script has the fragment you posted.
Besides, shouldn't the array be marked clean at this point:
md: stopping a
Still more problems ... :(
My md raid5 still does not always shut down cleanly. The last few
lines of the shutdown sequence are always as follows:
[...]
Will now halt.
md: stopping all md devices.
md: md0 still in use.
Synchronizing SCSI cache for disk /dev/sdd:
Synchronizing SCSI cache for disk
> I suggest you find a SATA related mailing list to post this to (Look
> in the MAINTAINERS file maybe) or post it to linux-kernel.
linux-ide couldn't help much, aside from recommending a bleeding-edge
patchset which should fix a lot of things SATA:
http://home-tj.org/files/libata-tj-stable/
Wh
Looks very much like a problem with the SATA controller.
If the repeat look you have shown there is an "infinite" loop, then
presumably some failure is not being handled properly.
I agree, even though the AHCI driver was supposed to be stable. The
loop is not quite infinite btw., it does time ou
More problems ...
As reported I have 4x WD5000YS (Caviar RE2 500 GB) in a md RAID5
array. I've been benchmarking and otherwise testing the new array
these last few days, and apart from the fact that the md doesn't shut
down properly I've had no problems.
Today I wanted to finally copy some data
[...] it seems that it wants to resync on every boot ...
Update:
- During shutdown I got a few errors on the console regarding arrays
that couldn't be stopped, because the mdadm package in Debian tries to
shut down all arrays, even if it is set not to autostart any --> will
file bug.
- The ker
Yesterday evening I initialized a new RAID5, waited for completion and
shut down the machine. Yet when I restarted it this morning it
immediately began with a resync -- it seems that it wants to resync on
every boot ...
This is a new Debian testing installation, array was created with EVMS
and is
Here's a tentative setup:
Intel SE7230NH1-E mainboard
Pentium D 930
2x1GB Crucial 533 DDR2 ECC
Intel SC5295-E enclosure
The above components have finally arrived ... and I was shocked to see
that the case's drive bays do not have their own fan, nor can I think
of anywhere to put one. Apparently
My current 15 drive RAID-6 server is built around a KT600 board with an AMD
Sempron
processor and 4 SATA150TX4 cards. It does the job but it's not the fastest
thing around
(takes about 10 hours to do a check of the array or about 15 to do a rebuild).
What kind of enclosure do you have this in?
The MaxLine III's (7V300F0) with VA111630/670 firmware currently timeout
on a weekly or less basis..
I have just one 7V300F0, so no idea how it behaves is a RAID. It's
been fine apart from the fact that my VIA southbridge SATA controllers
doesn't even detect it ... :(
(Anyone else notice compati
This is shrinking an array by removing drives. We were talking about
shrinking an array by reducing the size of drives - a very different
think.
Yes I know - I just wanted to get this in as an alternative shrinking semantic.
As for reducing the RAID (partition) size on the individual drives I
Why would you ever want to reduce the size of a raid5 in this way?
A feature that would have been useful to me a few times is the ability
to shrink an array by whole disks.
Example:
8x 300 GB disks -> 2100 GB raw capacity
shrink file system, remove 2 disks =
6x 300 GB disks --> 1500 GB raw c
> Pentium D 930
HPA recently said that x86_64 CPUs have better RAID5 performance.
Good to know. I did intend to use Debian-amd64 anyway.
Is it a NAS kind of device?
Yes, mostly. It also runs a caching NNTP proxy and drives our
networked audio players :)
Personal file server describes it bes
Hi list!
Having experienced firsthand the pain that hardware RAID controllers
can be -- my 3ware 7500-8 died and it took me a week to find even a
7508-8 -- I would like to switch to kernel software RAID.
Here's a tentative setup:
Intel SE7230NH1-E mainboard
Pentium D 930
2x1GB Crucial 533 DDR2
33 matches
Mail list logo