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

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

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

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

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

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

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

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

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

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


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

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

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

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

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.


1

I highly recommend MHDDFS. MHDDFS is a FUSE file system that allows you to combine multiple drives (or partitions) into a single mount point. The idea is that you mount all of your partitions, then tell MHDDFS which partitions you want to include for a particular mount point. MHDDFS will fill the first drive until it is full, then move on to the next, making ...


1

I guess data alignment issues. Every level (partition, RAID, filesystem) has to start at a supercell boundary. If not, every erase cycle (the worst part of Flash memory technology) would effectively be duplicated. There's an online tool to calculate alingments, described on the OCZ forum. It might help.


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

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

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

The correct (initial) way would have been to overlay LVM on top of the RAID array, and then re-allocate volumes as needed. But you're not at a point where this is probably feasible. You may still have a way out. Ext3/Ext2 are re-sizable, although it is slightly risky when you are contracting filesystems. I don't recommend this unless you have no other ...



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