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 ...
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
0 8 5 0 active sync /dev/sda5
1 8 23 ...
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 existing data onto it. ...
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 ...
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 system ...
And here's the fix, I'm not entirely clear on why it works, but it does!
After updating your mdadm file following the RAID array creation - usually with something like
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Simply run the following command
Then reboot, and everything will work as expected.
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 ...
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 ...
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 ...
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 ...
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....
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 ...
Does this help?
Specify the percentage of the filesystem blocks reserved for the
super-user. This avoids fragmentation, and allows root-owned
daemons, such as syslogd(8), to continue to function correctly
after non-privileged processes are prevented from writing to the
filesystem. The default ...
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 ...
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 ...
Two issues spring to mind
You've got duplicate array definitions in mdadm.conf. Replace (or comment out) the block of three lines following # definitions of existing MD arrays so that each array is declared 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 initramfs or ...
I found out the answer by asking on the mailing-list.
btrfs doesn't do RAID per-volume, but rather on a per-chunk basis. The filesystem reserves "raw" space in (p.e.) 1GB chunks. Initializing the fs with raid1 means that every time it tries to allocate a chunk, it tries to allocate a copy of this chunk on another device.
This architecture allows mixed-size ...
That file isn't typically included in the mdadm package.
$ rpm -ql mdadm | grep "mdadm.conf"
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 I ...
You can use lvm for this. It was designed to separate physical drive from logical drive.
With lvm, you can :
Add a fresh new physical drive to a pool (named Volume Group in LVM terminology)
pvcreate /dev/sdb my_vg
Extend space of a logical volume
And finish with an online resize of your filesystem
But beware it's ...
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 ...
An identical copy of your data is stored on each disk (provided the array is not "dirty"—e.g., if power is lost after writing to disk 0, but before writing to disk 1). However, the metadata is different; it allows mdadm & md to tell the two disks apart.
Can you swap the cables around?
You can swap the cables on the two disks. When you (or your distro's ...
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 ...
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 ...
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 ...
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 ...
Sounds like the device is remote. Assuming linux...
ssh remote_host 'dd if=/dev/sdb1' | cp --sparse=always /proc/self/fd/0 new-sparse-file
dd if=/dev/sdb1 | cp --sparse=always /proc/self/fd/0 new-sparse-file
This gives you an image that is mountable. However, if you pulled it across the network then you had 1.2 TB of network traffic (...
You can use /lib/cryptsetup/scripts/decrypt_derived in your crypttab to automatically use the key from one disk for another.
The decrypt_derived script is part of Debian's cryptsetup package.
Small example to add the key from sda6crypt to sda5:
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/...
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 ...