Tag Info

Hot answers tagged

16

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


10

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


9

The first one reports the UUID of the ext4 filesystem on the md block device. It helps the system identify the file system uniquely accross among the filesystems available on the system. That is stored in the structure of the filesystem, that is in the data stored on the md device. The second one is the UUID of the RAID device. It helps the md subsystem ...


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

This is a bug on the update-grub script. After what is said in the Debian bug report, a patch has been applied upstream so it should be fixed in the Debian package at some time.


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


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

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.


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


6

There is nothing wrong with --create - if you know what you are doing. The only problem is: You don't know. When you create a RAID, the command is usally something short, like: mdadm --create /dev/md42 --level=5 --raid-devices=3 /dev/sdx1 /dev/sdy1 /dev/sdz1 Dead simple, right? Except it isn't, really. RAID has a lot more variables. There's a data ...


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


5

No. But you can create a RAID-0 array containing only /dev/sdb, copy the data from /dev/sda to /dev/md0 , then add /dev/sda to the array. Voila, data preserved!


4

mdadm supports dealloc. commit=sec is the time, the filesystem syncs its data and metadata. Setting this to 0 has the same effect as using the default value 5. So I don't get the link between mdadm and commit=0 in your question?


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

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


4

The simple answer to the question in the title is "Yes". But what you really want to do is the next step, which is getting the existing data mirrored. It's possible to convert the existing disk, but it's risky, as mentioned, due the the metadata location. Much better to create an empty (broken) mirror with the new disk and copy the exiting data onto it. ...


4

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


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

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


4

That file isn't typically included in the mdadm package. $ rpm -ql mdadm | grep "mdadm.conf" /usr/share/doc/mdadm-2.6.9/mdadm.conf-example /usr/share/man/man5/mdadm.conf.5.gz You can either use the sample one included or generate it your self. My file shows this in the header: # mdadm.conf written out by anaconda So it was likely built by some choices ...


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

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


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

One possible answer is that the remote filesystem is mounted by default with the "atime" option. Access time writes for everything that the remote rsync accesses combined with the write penalty you suffer with RAID 5 (computing parity means reading all the RAID disks before you write to one of them) could explain the I/O magnification on the remote side. ...


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

The Gentoo Wiki has information that discusses both Grub 1 and Grub 2. Note that the situation is completely different in Grub 1 and Grub 2: Grub 1 doesn't know anything about RAID, but can fake reading from a RAID-1 device by reading one of the disks (this requires a 0.9 or 1.0 mdraid superblock format, not 1.1 or 1.2); Grub 2 supports Linux mdraid volumes ...


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



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