New answers tagged mdadm
I did it with LVM. Initial configuration: - sda2, sdb2 - and created raid1 md1 on top. sda1 and sdb1 were used for second raid1 for /boot partition. - md1 was pv in volume group space, with some lvm's on it. I've added disks sdc and sdd and created there partitions like on sda/sdb. So: created md10 as: mdadm --create /dev/md10 --level raid10 ...
I needed to reference the volume as /dev/md127 in fstab.
I don't know why one step is important. You can just plug in your new array, use dd to sync the FS into the new md device (like dd if=/dev/md1 of=/dev/md2 bs=4k (4k is important for speed) and then do e2fsck -f /dev/md2 && resize2fs /dev/md2. If you have RAID1, you can do it easier, BTW. You can remove one disk and replace with a bigger one. Then do ...
I assume you have RAID5. If yes, then my guess is that you can replace the disks one by one and let it rebuild on the new one, then see if you can extend it. One of the reasons why I would always use LVM.
The problem looks to me very much down to this unrecovered read error on sda. That's the only currently-live half of the mirror, so if it can't be read, there's no way to cleanly made sdb6 a copy of sda6 and resync the mirror. I note it's been nearly 10,000 hours since sda last passed a selftest, so the idea that hardware failure might've crept up on it, ...
You can't. See where it says FAILED? That means your data is gone. RAID 5 can only sustain one failed drive, and generally speaking, is evil and to be avoided as if it were radioactive. Remember kids, only people who hate their data use RAID 5.
I have hit his problem as well and after some testing can grow a Software RAID 0 array. I found an option which if you think about it makes sense to include in the grow command, the option is, --backup-file. If you think about it to realistically grow a RAID 0 array as you would if you did it in hardware is you'd need to copy the data elsewhere to destroy ...
Top 50 recent answers are included