Tag Info

Hot answers tagged

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


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.


4

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


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

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


4

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


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

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


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

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


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

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

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

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


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


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

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


2

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


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


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

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

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


2

It's already using all usable ressources if you don't use it for anything during the resync. This process is nearly only limited by the disk speed on modern systems, so you will see very few other resources being used. If you use a hardware RAID controller, the load to the rest of the system will even be zero, as the RAID controller will do all of the work ...


1

Try the following great tutorial on HowToForge. You probably missed one or more commands for mdadm, see: http://www.howtoforge.com/replacing_hard_disks_in_a_raid1_array


1

When vgchange -an does not seem to do anything (on an Ubuntu system) then consider blaming udev rules after reading this bug report (I found it Googling for "dmsetup remove lvm vgchange"): https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081 The workaround is as follows (thanks to Martin): sudo umount /mnt # asume the drive in question is ...


1

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


1

I'm assuming a Red Hat-based system, since you didn't specify (and it may be important): The quick fix would be to edit /etc/sysconfig/raid-check and set MAXCONCURRENT=1. This will cause all your RAID arrays to be checked sequentially. As for the algorithm, /usr/sbin/raid-check is just a shell script, and you can easily read it to see what it's doing.



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