1 |
On 6/24/19 12:12 PM, Mick wrote: |
2 |
> LVM-RAID uses the kernel's mdraid, |
3 |
|
4 |
Yep. |
5 |
|
6 |
You can get device mapper command(s) to show the internal / under the |
7 |
hood MD devices. |
8 |
|
9 |
I feel like what LVM does to mirror (RAID 1) devices is complex. You |
10 |
end up with non-obvious LVs that are then raided together to create |
11 |
another virtual block device that is what you see as the LV. |
12 |
|
13 |
There are options about where and how metadata is mirrored. Some of |
14 |
which is stored in the VG and others is stored in another small hidden |
15 |
LV specifically for this purpose. Which itself can be configured to |
16 |
have multiple copies. |
17 |
|
18 |
At least that's how I remember things from about five years ago. |
19 |
|
20 |
> but with less tools to manage the RAID configuration than mdadm offers: |
21 |
|
22 |
That's because the standard LVM tools make calls to the kernel to manage |
23 |
things. I never /needed/ anything other than the LVM tools to |
24 |
administer LVM RAID. But I think that you can find the expected things |
25 |
under device mapper et al. if you know where to go look. |
26 |
|
27 |
When I say "hidden", it seems as if the traditional LVM tools simply |
28 |
don't expose LVs with specific naming patterns unless you go looking for |
29 |
them. Much like dot files are ""hidden by default, but there if you |
30 |
know where and how to look. |
31 |
|
32 |
|
33 |
|
34 |
-- |
35 |
Grant. . . . |
36 |
unix || die |