How mature and featureful is LVM RAID?
LVM-RAID is actually mdraid under the covers. It basically works by creating two logical volumes per RAID device (one for data, called "rimage"; one for metadata, called "rmeta"). It then passes those off to the existing mdraid drivers. So things like handling disk read errors, I/O load balancing, etc. should be fairly ...
You've got a three-way mirror there: each drive has a complete copy of all data. Assuming the drive you want to remove is /dev/sdc, and you want to remove it from all three arrays, you'd perform the following steps for /dev/sdc1, /dev/sdc2, and /dev/sdc4.
Step 1: Remove the drive from the array. You can't remove an active device from an array, so you need ...
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 -...
Hardware and Software RAID are two different worlds. Since you mention "Server" most likely there is Hardware RAID present.
to find out use:
lspci -vv | grep -i raid
If Hardware RAID is present the output should be something like:
Subsystem: abcdefg RAID Controller
To find out more about your Hardware RAID configuration, this is only possible using ...
Q#1: Can you set up a RAID system using USB sticks as the storage media
You should be able to use any block storage devices in a RAID. Any standard directions for setting up a RAID using SATA HDD's should be applicable when using USB storage as well. You'll have to set it up so that the USB devices are assembled as members of the RAID array.
Q#2: What ...
Yes, it is possible by using fake file-backed disks for your redundant ones. Of course, not supported and you should have a backup, so simulate it first with small files on your old pool to see if everything works as expected.
For details see https://firstname.lastname@example.org/msg22993.html and https://www.mail-archive.com/zfs-discuss@...
If you know the array UUID, then mdadm --assemble /dev/md0 --uuid <uuid> (note the slight difference in parameter order) will do what you want: scan all unused volumes for ones that have md metadata for the given UUID. Other options:
mdadm --assemble /dev/md0 --name <name> (does the same thing as --uuid, but with an array name instead of a UUID....
It's because the device nodes no longer exist on your system (probably udev removed them when the drive died). You should be able to remove them by using the keyword failed or detached instead:
mdadm -r /dev/md0 failed # all failed devices
mdadm -r /dev/md0 detached # failed ones that aren't in /dev anymore
If your version of mdadm is too old to do ...
The easiest method, that requires no changes to your setup whatsoever, is probably to reduce the RAID to a single disk. That leaves you the option to add a disk and thus re-use the RAID at a later time.
mdadm /dev/mdx --fail /dev/disky1
mdadm /dev/mdx --remove /dev/disky1
mdadm --grow /dev/mdx --raid-devices=1 --force
The result would look something like ...
You need to assemble the (degraded) RAID array, using something like:
mdadm --assemble --readonly /dev/md0 /dev/sdb2
Of course, pick a number besides md0 if that's already in use. Then you can mount /dev/md0 (or, if it is actually LVM, etc., continue down the chain).
You can, in the case of RAID1, also do this using loopback devices & an offset, but ...
the Debian and Ubuntu 'mdadm' package contains the file
which in turns the first sunday of each month will run the command
/usr/share/mdadm/checkarray --cron --all --idle --quiet
that will check all your arrays for consistency (unless you set AUTOCHECK to false in /etc/default/mdadm ). A report will be sent to the 'root' user (make ...
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 usually 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 ...
Two issues spring to mind
You've got duplicate array definitions in mdadm.conf. Replace (or comment out) the block of three ARRAY lines following # definitions of existing MD arrays so that each array is declared only by your most recent scan.
A typical scenario for RAID arrays that fail to build on boot is that either they have not been updated in the ...
That's a bad idea because you're deliberately degrading your RAID and Resyncs might fail unexpectedly. It's better to hook the new disk up to the system (so you have n+1 disks) and then use mdadm --replace to sync it in. That way the RAID never degrades in between.
You don't have to fail / remove drives to find out which is which. You can see a device's ...
Your arrays are not properly started. Remove them from your running config with this:
mdadm --stop /dev/md12
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 /etc/...
The cause was an erroneous spares=1 option in the mdadm.conf:
# definitions of existing MD arrays
ARRAY /dev/md0 UUID=621d5f15:cce75825:60273c48:78a7dac7
I'm not sure how this ended up there, but I suppose it happened when a device failed and was replaced.
Removing the spares=1 option or just recreating the mdadm.conf from scratch fixes the ...
EFI knows how to access FAT and FAT32 filesystems. This is why your EFI boot partition has to be FAT or FAT32 formatted. EFI however does not know how to read a software RAID 1 partition, even if it is formatted using FAT32. There is a pretty simple away around this, at least using Arch Linux. When installing the system, you set the boot partition up as ...
The stupidly simple solution: add --update=devicesize when assembling.
I have no idea how, but apparently the partition size and the size that md remembered for this drive didn't match up anymore. Cheers to the guys over at the german ubuntuusers forum who painstakingly solved their case with manual hex editing before finally finding the correct switch to ...
I didn't know LVM could do RAID either. Personally, I would stick with mdadm since it's a much more mature software that does the same thing. If something breaks with LVM RAID, you're probably not going to be able to get as much support than if you had gone with mdadm. Additionally, I wouldn't trust LVM RAID since LVM has historically shown to not be the ...
I couldn't find a solution with an already created RAID 1 configuration, so backup your data, because for this solution I'll give you'll need to delete your RAID 1 first. Actually, I just deleted the virtual machine I was working with and created a new one.
So this it's going to work with Debian 10, and with a clean machine
Create a new clean ...
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 ...
I found the solution to this issue in the following thread titled: [SOLVED] CentOS 6 on GA-990FXA-UD5.
The solution involved removing the BIOS RAID metadata that apparently was part of a residual software RAID that the 40GB HDD must of been used in. Running this command in the CentOS 6.5 LiveCD in a terminal fixed it:
$ dmraid -r -E /dev/sda
Do you really ...
It ultimately depends on the implementation of the RAID that's built into your motherboard but often times this "hardware" RAID is little more than software RAID facilitated through some proprietary drivers that will need to be loaded into the OS.
If this is the case, IMO, it's almost always better to use the stock software RAID that's included with any ...
This is an old question, but since I searched quite long for a solution, I want to share my result:
ARRAY <ignore> UUID=3f620e6d:4e655d66:b931eb71:baf7cf3a
From man mdadm.conf:
ARRAY The ARRAY lines identify actual arrays. The second word on the line may be the name of the device where the array
This recipe worked for me after having the same issue. Looked all over the net trying to find the answer, and finally coming across this, and still no help.
The problem as I see it is multifold.
mdadm reassigns the device files from /dev/md0 to something like /dev/md127 on the next reboot. So you cannot just use the device file in the fstab. I ended up ...
Unmounting (filesystems) is not sufficient.
You'd have to stop the array then re-assemble it afterwards:
mdadm --stop /dev/md0
# re-arrange / hotplug drives
mdadm --stop /dev/md0 # (*)
mdadm --assemble /dev/md0
It makes sense to check journalctl / dmesg, and/or cat /proc/partitions / lsblk, to make sure the drives got re-detected fine before attempting to ...
So assuming you are using mdadm you can do exactly what you suggest The only caveat is that the raid monitoring utility will generally only handle one disk at a time and normally when you have marked one as failed. Further you just need to ensure that it has completed copying the data before removing the old disks from the raid array otherwise you'll end up ...
In this scenario, each disk would claim that the other disk failed.
The result depends on how exactly you're assembling disks, but essentially, it will go with one disk and ignore the other; or it might assemble the other as a separate raid, which gives you a split brain.
I've done an experiment with loop devices, where I first changed loop1 and then ...
What I ended up doing was using mknod like @derobert suggested to create the devices that mdadm was looking for. I tried the major/minor numbers mdadm was telling me it couldn't find with the different drive letters I was trying to remove until it worked.
mknod /dev/sde1 b 8 17
Then I had to use the --force option to get it remove the component.