Tag Info

New answers tagged

3

Your arrays are not properly started. Remove them from your running config with this: mdadm --stop /dev/md12[567] Now try using the autoscan and assemble feature. mdadm --assemble --scan Assuming that works, save your config (assuming Debian derivative) with (and this will overwrite your config so we make a backup first): mv /etc/mdadm/mdadm.conf ...


2

Start situation A1+A2+A3+A4. after first permutation B1+A2+B3+A4 disk A1 and A3 have data at stage 1 after second permutation B1+B2+B3+B4 disk A2 and A4 have data at stage 2 putting together A1+A2+A3+A4 gives data at stage 1 and 2, the only way that those data are sync is to have the OS down and let hardware raid do the sync. This might be a ...


3

In RAID-5, unless your write was large enough to cover all data chunks for a given parity chunk, it has to read the missing data chunks in order to be able to recalculate and update parity. Thus a relatively small write on a RAID-5 can turn into a large read operation. RAID-1 does not need such additional reads, as there is no parity, it just writes to all ...


2

OK, it'd appear that /dev/sda is very dead, and you're not going to get data off it, at least not without tricks. /dev/sdb on the other hand just seems to have a lot of bad sectors. That's probably a bad sign for it, but you should be able to get your data off. Depending on how important the data is and how confident you are in your backups, you'll want to ...


0

It's all about layers. You have a disk (the lowest layer). On that disk you put a partition table. On that, you put a RAID. On the RAID you put LUKS. On the LUKS you add LVM. On the LVM, finally the filesystem (the highest layer). Disk -> Partition -> RAID -> LUKS -> LVM -> Filesystem You may skip or reorder some of those layers. It ...


0

You don't have to worry about all this. The data in a volume won't overlap with the metadata. Otherwise it would be very difficult to manage! For example, this is what each of your disks will look like (not to scale): [--------------------- sda ------------------------] [---][------------------ sda1 ---------------------] ...


0

I fixed it, but I can't honestly tell you how. Basically I booted into a LiveUSB version of Mint 17. I noticed the raid array was happy, so I mounted the system and chrooted into it. I then installed dmraid again and mdadm (don't know why I did that), updated my grub settings and installed grub to the array. A reboot later, it complained about mdadm, but ...


0

The chance of a URE during the reconstruction is very high?! What utter rubbish. Well, it's true - if you are stupid and never ever test your hard disks for errors! In that case, the resync is your first ever full read test for all other drives. Since read errors can go undiscovered for ages, naturally the risk of finding one such at rebuild time is high. ...


0

OK, it looks like we have now access to the raid. At least the first checked files looked good. So here is what we have done: The raid recovery article on the kernel.org wiki suggests two possible solutions for our problem: using --assemble --force (also mentioned by derobert) The article says: [...] If the event count differs by less than 50, then ...


0

Your only option here, since you turned your drives spare and lost their metadata, is to re-create the RAID. This is very dangerous, a mistake will wipe your data. When re-creating a RAID there are several things to consider. You must use --assume-clean so it won't sync. You should leave one drive out (preferably the one that is in the worst state) by ...


0

mdadm --force should fix this. Note that you may suffer minor data corruption, as its going to pretend its in sync. Use it like this: mdadm --stop /dev/md127 (you need to stop what's currently running first) mdadm -v --assemble --run --force /dev/md127 /dev/sd[a-hl-z]. The key thing is leaving out /dev/sdi here, as we know that disk is the least recent. ...



Top 50 recent answers are included