| 1 |
Am 16.05.2014 13:06, schrieb Alan McKinnon: |
| 2 |
|
| 3 |
> LVM is an excellent solution for what it was designed to do, which is to |
| 4 |
> deal with stuff like this: |
| 5 |
> |
| 6 |
> Oops. I misjudged how big /var/log needed to be and now I need to add |
| 7 |
> 50G to that partition. But it's sda6 and I have up to sda8. Arggghhhhh! |
| 8 |
> Now I need 5 hour downtime to play 15-pieces with fdisk. |
| 9 |
> |
| 10 |
> LVM makes that 2 commands and 12 seconds. Yes, it's a bit complex and |
| 11 |
> you have to hold the PV/VG/LV model in your head, but it also *fixes* |
| 12 |
> the issue with rigid MSDOS partition style. |
| 13 |
> |
| 14 |
> Modern filesystems like ZFS and btrfs sidestep the need for LVM in a |
| 15 |
> really elegant and wonderful way, none of which changes the fact that |
| 16 |
> ZFS/btrfs weren't around when LVM was first coded. |
| 17 |
|
| 18 |
exactly. I loved LVM when it was new as it was a way to get the |
| 19 |
mentioned capability to resize filesystems and underlying "partitions". |
| 20 |
|
| 21 |
And I still use it for servers, creating a VG on the mdadm-RAID-array |
| 22 |
and only providing a part of it for the customers ... if they then fill |
| 23 |
up their samba-shares with cat pictures I can easily ssh in and give |
| 24 |
them some more space in a minute ... that is nice to have! |
| 25 |
|
| 26 |
OK, I also had some issues with LVM over the years ... but not in a |
| 27 |
regular way, more when physical volumes got flaky or so. In general it |
| 28 |
just works for me (and show me one piece of tech where you are |
| 29 |
guaranteed to not have issues with ...) |
| 30 |
|
| 31 |
But sure, now I also think of using btrfs on one of the next fileservers |
| 32 |
I deliver ... and instead of using rsnapshots to give customers a |
| 33 |
readonly history of their data there could be btrfs-snapshots. |
| 34 |
|
| 35 |
time changes, things develop ... |
| 36 |
|
| 37 |
Stefan |
Archives