| 1 |
Apparently, though unproven, at 13:43 on Saturday 09 April 2011, Dale did |
| 2 |
opine thusly: |
| 3 |
|
| 4 |
> So, when I get me a new drive, I use pvcreate to get it ready for LVM, |
| 5 |
> then use vgextend to add it to the VG, then it is available for whatever |
| 6 |
> LV I want to extend or to make a new LV? |
| 7 |
|
| 8 |
Yup, that's really what it's all about. |
| 9 |
|
| 10 |
|
| 11 |
|
| 12 |
LVM will decide for itself what bits of what PV to use for each LV, you should |
| 13 |
just let it go ahead and make it's own decisions. The man page describes |
| 14 |
options where you can control stuff - like striping and mirroring. I find this |
| 15 |
just confuses the issue though and makes stuff needlessly complex. |
| 16 |
|
| 17 |
A much better viewpoint is you deal with your striping and performance issues |
| 18 |
at a lower layer - RAID - and treat LVM as something that creates a gigantic |
| 19 |
storage bucket where you take out how much you need and don't care where it |
| 20 |
is. If two drives have vastly different performance characteristics and you |
| 21 |
find yourself having to dictate to LVM what to do, then they really should not |
| 22 |
be in the same VG at all. |
| 23 |
|
| 24 |
-- |
| 25 |
alan dot mckinnon at gmail dot com |
Archives