Tag Info

Hot answers tagged

10

The point of RAID with redundancy is that it will keep going as long as it can, but obviously it will detect errors that put it into a degraded mode, such as a failing disk. You can show the current status of an array with mdadm -D: # mdadm -D /dev/md0 <snip> 0 8 5 0 active sync /dev/sda5 1 8 23 ...


8

This is an attempt to summarize from the chat troubleshooting session. The setup turns out to be physical disk -> mdraid raid1 -> LVM. So there are several layers to work through. The old setup was (due to unfortunate prior recovery efforts) not available. However, the NAS gui had been used to create another volume on a different disk, and thankfully the ...


8

Open the /etc/mdadm/mdadm.conf file, find the line that begins with ARRAY /dev/md1 and remove the line immediately following which states 'spares=1'. Then restart mdadm service. If you did a mdadm --examine --scan to retrieve the array definitions while the md1 array was still rebuilding, one partition was seen as spare at that moment.


8

From Documentation/md.txt in the Linux kernel documentation: clean - no pending writes, but otherwise active. When written to inactive array, starts without resync If a write request arrives then if metadata is known, mark 'dirty' and switch to 'active'. if not known, block and switch to write-pending If written to an active array ...


6

mdraid always allows you to move disks around freely in the machine, regardless of how you add the disk to the array. It tracks the disks by the RAID metadata (superblocks) stored on the disk. Note that this assumes mdadm can find the disks when its assembling the arrays. The default (specified in /etc/mdadm/mdadm.conf) is normally DEVICE partitions, which ...


6

The right thing to do is something like mdadm --add /dev/md0 /dev/sdb1. Use the correct array in place of md0 and the correct partition in place of sdb1. The key thing is the array is running. Its completely unambiguous which data to copy: the data that is currently running. If you have bitmaps enabled, the resync will be fairly fast as it'll only copy what ...


6

Simply run mdadm --build -l1 -n2 /dev/md0 /dev/dm-10 /dev/dm11 to get your data back. Verify that the devices are correct (or use the aliases from /dev/mapper) before doing this! Also, if your kernel has already used (or is using) one of these devices, data will be inconsistent. You should set up the second device as a degenerate 1.2 array, copy the data ...


6

I hate to be the bearer of bad news, but... Q: I'm new to mdadm, did I do everything correctly? A: No. In fact, you did just about everything in the most destructive way possible. You used --create to destroy the array metadata, instead of using --assemble which probably would have allowed you to read the data (at least, to the extent the disk is ...


5

Chunk size does not apply to raid1 because there is no striping; essentially the entire disk is one chunk. In short, you do not need to worry about the 4k physical sector size. Recent versions of mdadm use the information from the kernel to make sure that the start of data is aligned to a 4kb boundary. Just make sure you are using a 1.x metadata format.


5

Basic Boot Process Grub Grub reads its disk, md, filesystem, etc. code from the MBR. Grub finds its /boot partition, and reads the rest of itself out of it. Including the config, and any modules the config specifies need loading. Grub follows the instructions in the config, which typically tell it to load a kernel and initramfs into memory, and execute ...


4

You can force a check of the entire array while it's online. For example, to check the array on /dev/md0, run as root: echo check > /sys/block/md0/md/sync_action I also have a cron job that runs the following command once a month: tar c /dir/of/raid/filesystem > /dev/null It’s not a thorough check of the drive itself, but it does force the ...


4

If it's RAID 1 with 0.90 superblock, you should be able to mount directly without using the RAID layer at all. Data starts without offset at the beginning of the disk, so there should be no problem. Use the read-only mount option or a read-only loop device for the experiment just in case. If that works, the simplest method would be to use the other disk to ...


4

RAID 0 has no redundancy so the array actually becomes more fragile with more disks since a failure in any of them will render the entire array unrecoverable. If you want to continue with your RAID 0 (for performance reasons presumably), and minimize downtime, boot your system with a rescue OS, e.g., SystemRescueCD, and use 'dd' or 'ddrescue' to make the ...


4

Given that chunks can be quite big and that the parity information is simple XOR (i.e. does not affect data before or after the piece in question) the assumption that only complete chunks can be written does not make sense to me. Chunks are the unit in which data is spread over the volumes. One chunk of continuous data is written to a certain volume, the ...


3

If you have configured your RAID-1 to use a bitmap (see man page) then --re-add is a lot faster because just the areas written after the connection breaking have to be written. In any way (even without a bitmap an full synchronization) you can more easily than with dd configure the sync speed via /sys/block/md0/md/sync_speed_* Synchronization with dd would ...


3

No, you can't. You should also check the drive's SMART status either with the gnome disk utility or with smartctl from the smartmontools package. If it is only a few bad sectors, md should have tried to rewrite them, which should have triggered the drive to automatically remap them to the spare pool. If you have enough bad sectors that the spare pool has ...


3

There's metadata at the start of the partition. If you do a mdadm -E /dev/sda1 you'll see where the data starts (Data Offset). That will be where your FS starts. You could use fdisk (for MBR-type partitioning) or gdisk (for GPT), to move the start of sda1 to the location of that Data Offset. For instance, if it says: Data Offset : 16384 sectors Run ...


3

I poked around /sys and got a lot closer to the answer. # cd /sys/block/md0/md # cat component_size 2147479552 That agrees with what we have seen before. But this: # grep . dev-sd*/size dev-sdc/size:2147482623 dev-sdd/size:2147482623 dev-sde/size:2147482623 dev-sdf/size:2930265560 dev-sdg/size:2147482623 dev-sdh/size:2147482623 dev-sdi/size:2147482623 ...


3

I think during creation the size of the device was registered somewhere in the metadata. Changing the controller doesn't change the metadata. Remove the spare from the md, then re-add it to the RAID set as a new drive. You probably have to remove the metadata (check man page for --zero-superblock or wipe the whole disk). If that works for a single disk, ...


3

First off, drive re-lettering just happens sometimes, depending on how your machine is set up. Drive letters aren't expected to be stable over reboots since, ummm, a while. So it isn't a huge concern that your drive moved on you. Assuming dmraid and device-mapper aren't using your devices: Well, mdadm --stop /dev/md0 might take care of your busy messages, ...


3

Okay, clearly one of your disks is not active in the array right now. Let's say, under the current enumeration, that /dev/md0 is missing /dev/sdb1. To add /dev/sdb1 back in its former state: mdadm -a --re-add /dev/md0 /dev/sdb1 You may want to re-check the array to make sure the data is all consistent. echo check >>/sys/block/md0/md/sync_action ...


3

If it's RAID 1, and if you know the data offset (e.g. 2048 sectors, you can usually find out the exact data offset by mdadm --examine /dev/sdb1), then you can create a read-only (to be safe) loop device like so: # losetup --find --show --read-only --offset $((2048*512)) /dev/sdb1 /dev/loop7 And then try to check then mount the printed loop device: # ...


3

Have a look at this question. I assume that is familiar to your problem. Recreating and even syncing a RAID-1 should not destroy data. Obviously the MD device starts at another offset now. Thus where mount looks for a superblock there is data. This can have happened in at least two ways: You (or rather: the default setting) have created the new array with ...


3

How did you partition the disks the first time? If you used fdisk, you may have limited yourself to just the first 2 TB of each disk, as that's the maximum partition size you can create with fdisk. As such, your raid device probably looks more like a RAID5 of 3 * 2TB disks. Use parted to create your larger than 2TB partition. Example: [root@evil ...


3

If the bitmap has not changed when the old disk was replaced by the new one, it should work to mark the disk as failed and remove it from the array. mdadm -f /dev/md0 /dev/sda1 mdadm -r /dev/md0 /dev/sda1 Then replace the disk and add the old one to the array: mdadm --add /dev/md0 /dev/sde1 I think that shutting down the machine and replacing the disks ...


3

With Software RAID, you don't have to use whole disks. If you have 3x2TB and 3x1TB, and planning to replace the 1TB with 2TB in the future, you could use 1TB members. So that's RAID5 (or if you prefer RAID6) over 6x1TB, and RAID5 over 3x1TB. So the 2TB will be shared by both RAIDs. When you kick out an 1TB and add a 2TB instead, then one RAID will see a ...


3

If you are still in the design stage (i.e. you're not already committed to mdadm and/or lvm) then I recommened that you seriously consider using a modern filesystem like Btrfs or ZFS. btrfs is built-in to the mainline linux kernel, and zfs is available from the zfsonlinux web site as easily installable kernel modules or dkms packages for most linux ...


3

Yes, you can (provided you have a 3.2+ kernel). First, add a new drive as a spare: mdadm /dev/md0 --add /dev/sdc1 (replace md0 and sdc1 with your RAID and disk device, respectively). Then, initiate a copy-replace operation like this: echo want_replacement > /sys/block/md0/md/dev-sdd1/state Where md0 is, again, your RAID device, and sdd1 is the ...


3

fdisk is the wrong tool for disks >2TB. Use parted or gdisk instead. It appears that /dev/sdc1 and /dev/sdd1 are 2TB partitions, so that's what limits your array size. For the other disks, they have GPT so I assume they are 3TB already, but you should check. Basically you have to stop the array, enlarge each partition to 3TB (without changing the starting ...


3

Partition start/alignment Make them start at 1 MiB boundaries, for example using parted and unit mib. That way you won't have an issue with today's 4k sector disks, and not with tomorrow's 8k or 16k disks... and you only waste 1MiB per disk. You can verify the partition alignment of any given disk using parted /dev/disk unit b print free. It ...



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