Tag Info

Hot answers tagged

20

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


11

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


10

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


9

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


7

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


7

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

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

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


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

When an array is initially assembled, it is placed in "auto-read-only" mode. I quickly tested, with my kernel (3.10.x) and mdadm (3.3), this doesn't happen on create—but you must be running different versions. However, auto-read-only isn't an error, nor is it anything to worry about. The basic idea behind it is to make --assemble (and, apparently now, even ...


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

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!


5

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


5

We have configured all of our servers to run regular selftests with the following line in /etc/smartd.conf: # DEVICESCAN matches all hard disks found in /dev/ and applies the following # options to them. # # Default options from Debian: # -d removable don't exit when the device when a device vanishes # -n standby don't wake a device up that is ...


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

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


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

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


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



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