Hot answers tagged

12

You may need to understand a bit more about RAID-6; I recommend reading Wikipedia's explanation. The problem is that the second parity bit in RAID-6 isn't just a copy of the first (simple, XOR-style, as used in RAID-5) parity bit; that would be completely useless, because in the event of losing two data drives the fact that you have two surviving copies of ...


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 ...


9

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 than ...


6

You may be able to use a tool like ddrescue to image that 3rd failed drive to one of the new drives. This should be an exact copy minus the bad blocks. This way it won't get read errors. Then replace that 3rd failed drive with the newly imaged one. Assuming none of the bad blocks were critical to the RAID or filesystem then you may be able to then assemble ...


5

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, ...


5

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.


5

I think you might have a too old mdadm.conf in your initramfs and/or mdadm gets confused during the discovery&initialization of the arrays. Try telling mdadm to consider only disks on the PCI bus, by adding the following line in mdadm.conf: DEVICE /dev/disk/by-path/pci* Going a step further, you can directly specify the disks themselves. Make sure ...


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 ...


4

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 ...


4

Well the answer to that would be you have to wait it out.


4

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

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 ...


3

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).


3

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 problem,...


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

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 ...


3

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 ...


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

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

I know the MSA60 well and although it really is just a SAS JBOD I'd say that you'd struggle to get it to work with that Dell box and even if you could it may not be stable and won't be supported in any way, in fact I think doing that would void HP warranty.


3

I just had the same problem, with apparently the same type of hardware and a fresh 13.10 x64 install. Being less experienced, I spent a couple of days pursuing possibilities of missing kernel modules, etc., but after reading your report I do find that vgchange -ay at the initramfs busybox prompt does render the system bootable. I have not yet tried the 1 ...


3

Almost certainly not. Every RAID system I'm aware of takes some of the disk space to store its metadata and superblock, and that cuts into the space available to store files. If you had the disk partitioned in "just the right way", you could, theoretically, do it without an extra copy, but it would require an extensive amount of knowledge about how the ...


2

Yes, it's a bug. Report it to Ubuntu unless you feel like fixing it yourself.


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

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

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

I'm not sure you asked the question you think you asked, but /dev/md3 is the same as /dev/sdb1 and /dev/sdc1 since it's a mirror set. No, it shouldn't. No, that will create data loss for you. N/A You can probably get rid of this error message by modifying your /etc/lvm.conf file to change the filter to reject sdb* and scd* devices, regenrate your initrd, ...


2

I had the same problem and after searching I found out that this solution worked for me. I just had to rename all /dev/md/* devices to /dev/md* devices in /etc/mdadm/mdadm.conf and run update-initramfs -u to update the initramfs.


2

Restore from backup. The next time you build the machine, make md0 RAID1 and only the large data stores RAID6. Or better, invest in a hardware RAID card.


2

For sequential reads, there is no performance benefit from reading from both disks. Since the same data is on both disks, they would each have to seek over any data read by the other disk. But short seeks forward is not that much faster than reading all the intermediate data. However if you have multiple processes reading different data from the disk in ...



Only top voted, non community-wiki answers of a minimum length are eligible