Hot answers tagged md
10
I have never heard of any sort of "odd/even" performance impact of a RAID5/6 array, and like you, I can't find anything useful from a quick web search.
There are potential issues with the number of disks and write performance in a RAID5/6 array, but they're related to "more disks == slower writes", because (depending on the implementation) the RAID system ...
4
Looks like the filesystem was hosed and the fsck didn't fully repair it.
At this point I'd be tempted to check the logs to see if the disks are all physically working (noises? SMART status? errors in the logs regarding resets? etc.) and restore from backup rather than spend more time trying to straighten out the results of the fsck.
4
That's kinda awkward due to read-write cache is always there in despite of having RAID or a single disk block device. But there's one knob which can add more RAM for RAID's own stripe-cache: /sys/block/mdYOUR_MD_NUMBER/md/stripe_cache_size
stripe_cache_size (currently raid5 only)
number of entries in the stripe cache. This is writable, but
...
3
The HP MSA60 and MSA70 both present themselves as a simple SAS Expander with drives. I've been told by HP and it's reps that they're only compatible with HPs other MSA and P-Series HBAs. However I've heard other people claim they work fine with other hardware. YMMV. Using them with a Dell unit wouldn't be supported by either company (that support is a large ...
3
How does the RA setting get passed down the virtual block device chain?
It depends. Let's assume you are inside Xen domU and have RA=256. Your /dev/xvda1 is actual LV on the dom0 visible under /dev/dm1. So you have RA(domU(/dev/xvda1)) = 256 and RA(dom0(/dev/dm1)) = 512 . It will have such effect that dom0 kernel will access /dev/dm1 with another RA ...
3
"what is the better choice for a normal server without frequent changes to disks and partition setup?"
To answer your question you posed, there is a reason there are so many options for disk array setup to choose from. Each scenario has its own requirements, wants/needs, performance related issues, etc. If you were to post what the server was going to be ...
3
The renaming of software raid devices is something unproblematic (here from md0 to md127). I've seen this over the last years and you shouldn't worry about it.
But your were totally right to ask about the auto-assembly warnings. Here, the devil lies in the details. In dmesg you see it's trying to find mdadm 0.90c superblocks (the old ones). It fails and it ...
3
I would say that you are in a pretty bad shape. If you are simply desperate to somehow recover some of your data and don't care much about the LVM (whose metadata is probably already corrupt, judging by the IO errors from vgchange -an), I would recommend going low level. Remember, LVM is just a wrapper around the kernel device mapper, so you can use dmsetup ...
3
For Linux md RAID, the only constraint I'm aware of is that the new drive must be no smaller than the old one. For that reason, I often move to the next drive size up (ie, last time a 1TB HDD failed, I replaced it with a 2TB; sacrificing the extra blocks was less time - and therefore money - than agonising about whether the new 1TB drive was 20,000 blocks ...
2
Know the answer harder to explain so I will do so in example. Say for the sake of this you have 3 block devices an you set your RA to say 4 (4*512 byte) assuming standard sector. If you were to say use a RAID-5 scheme using the 3 disks, any read that even touched a stripe on a unique disk would compound the RA by the factor you initially set block device RA ...
2
If you are not using LVM, you need to:
remove the md device (using mdadm),
remove the partition (using fdisk),
recreate the needed partitions (using fdisk),
and then recreate the md device (using mdadm).
2
Having the RAID1 over the entire disk allows you to replace a defective disk without downtime (if the disk controller allows hot swapping).
If you have separate partitions you can do more creative things. You can have /, /boot, and /srv different partitions. This allows you to split the RAID for / and do an OS upgrade in a VM that has access to the unused / ...
2
It is likely stalling before finishing because it requires the faulty disk to return some sort of status, but it's not getting it.
Regardless, all your data is (or should be) intact with only 3 out of 4 disks.
You say it ejects the faulty disk from the array - so it should still be running, albeit in degraded mode.
Can you mount it ?
You can force the ...
2
The obvious approach would be to replace the faulty disk, re-create the arrays and replay the backup you have taken before the array extension operation.
But since you appear not to have this option, this would be the next best thing to do:
get a Linux system with enough space to accomodate all your disks' raw space (12 TB, if I got the numbers right)
...
2
You can use the --assume-clean option. From the man:
Tell mdadm that the array pre-existed and is
known to be clean. It can be useful when trying
to recover from a major failure as you can be
sure that no data will be affected unless you
actually write to the array. It can also be
used when creating a RAID1 or RAID10 if you want
to avoid the ...
2
The logic for when Linux applies read-ahead is complicated. Starting in 2.6.23 there's the really fancy On-Demand Readahead, before that it used a less complicated prediction mechanism. The design goals of read-ahead always include not doing read-ahead unless you have a read access pattern that justifies it. So the idea that the stripe size is a relevant ...
1
Okay, I figured it out.
The problem was that grub2 needs space to save the stage2 loader to - and in my configuration, there was none.
The solution was to shrink Partition 1 on both disks using resize2fs, parted and mdadm by taking out one disk at a time from the RAID.
I shrank 16MB of the front of Partition 1, retried "upgrade-from-grub-legacy", ...
1
Wow, a tough one.
This seems to indicate that 0x31120303 is a bus reset due to one of your devices being under heavy load. It also says you don't need to worry about it. (Haha, yeah right.)
This indicates that these log messages are happening because one of your devices is taking too long to respond to commands. This says the same thing, and also indicates ...
1
Likely your best bet is a hardware problem somewhere between your disks and up to and including your sas raid controller. I recommend trying: 1) Run any diagnostic tools from the vendor/s if they are available, 2) Check/re-seat/replace cables, 3) strip out hardware components and swap out hardware in the chain that connects the disks to your raid controller, ...
1
If you can clone the drives with dd then I would do that. Keep your original drives as untouched as possible.
Then this is a total shoot from the hip thing but is what I'd try if I were in that situation. With the cloned drives in the system I'd erase all the RAID metadata using.
mdadm --zero-superblock /dev/sdx#
on each of the drives involved.
Then ...
1
Are you certain of your command line for creating the array?
My guess is that it was a "standard" 4 drive raid10 array with a hot spare drive, which would explain the result of /dev/sdc2
Can you tell us the result of:
cat /proc/mdstat
cat /etc/mdadm.conf
mdadm --examine /dev/sdx2 ( each drive )
With this you might be able to guess which drive was the hot ...
1
You need to do
shell># mdadm --assemble --scan
once done, you should be able to see that md0 became active when you type
shell># cat /proc/mdstat
if it is not the case, try
shell># mdadm --assemble --scan --run
and repeat
shell># cat /proc/mdstat
to see if md0 became active.
Once md0 is active, you can mount it with
shell># ...
1
Maybe it's too late now, but did you update your mdadm.conf file after adding you new drive? If you change a disk, your array won't have the same uuid anymore, and at reboot it will be looking for the old drive, not knowing that the new drive is here.
Here's the command to generate the lines for mdadm.conf :
mdadm --detail --scan
About the boot ...
Only top voted, non community-wiki answers of a minimum length are eligible
