On Tue, 23 Jun 2015 19:08:24 -0700
Gordon Messmer <gordon.messmer@xxxxxxxxx> wrote:
>
> Such as:
> 1) LVM makes MBR and GPT systems more consistent with each other,
> reducing the probability of a bug that affects only one.
> 2) LVM also makes RAID and non-RAID systems more consistent with each
> other, reducing the probability of a bug that affects only one.
OTOH, it increases the probability of a bug that affects LVM itself.
But really, these arguments sound like a strawman. It reduces the
probability of a bug that affects one of the setups --- I have a hard
time imagining a real-world usecase where something like that can be
even observable, let alone relevant.
> 3) MBR has silly limits on the number of partitions, that don't
> affect LVM. Sure, GPT is better, but so long as both are supported,
> the best solution is the one that works in both cases.
That only makes sense if I need a lot of partitions on a system that
doesn't support GPT. Sure, that can happen (ever more rarely on modern
hardware), but I wouldn't know how common it is. I rarely needed many
partitions in my setups.
> 4) There are lots of situations where you might want to expand a
> disk/filesystem on a server or virtual machine. Desktops might do so
> less often, but there's no specific reason to put more engineering
> effort into making the two different. The best solution is the one
> that works in both cases.
What do you mean by engineering effort? When I'm setting up a data
storage farm, I'll use LVM. When I'm setting up my laptop, I won't.
What effort is there? I just see it as an annoyance of having to
customize my partition layout on the laptop, during the OS installation
(customizing a storage farm setup is pretty mandatory either way, so
it doesn't make a big difference).
> 5) Snapshots are the only practical way to get consistent backups,
> and you should be using them.
That depends on what kind of data you're backing up. If you're backing
up the whole filesystem, than I agree. But if you are backing up only
certain critical data, I'd say that a targeted rsync can be waaay more
efficient.
> 6) If you use virtualization, LV-backed VMs are dramatically faster
> than file-backed VMs.
I asked for an explanation of this in the other e-mail. Let's keep it
there.
> LVM has virtually zero cost, so there's no practical benefit to not
> using it.
If you need it. If you don't need it, there is no practical benefit of
having it, either. It's just another potential point of failure, waiting
to happen.
> The point of view that LVM isn't needed when a symlink will do is no
> more valid than the opposite point of view: that there's no reason to
> play stupid games with symlinks when you have the ability to manage
> volumes.
I would agree with this, up to the point of fragility/robustness (see
below).
> > (2) It is fragile. If you have data on top of LVM spread over an
> > array of disks, and one disk dies, the data on the whole array goes
> > away.
>
> That's true of every filesystem that doesn't use RAID or something
> like it. It's hardly a valid criticism of LVM.
If you have a sequence of plain ext4 harddrives with several symlinks,
and one drive dies, you can still read the data sitting on the other
drives. With LVM, you cannot. It's as simple as that.
In some cases it makes sense to maintain access to reduced amount of
data, despite the fact that a chunk went missing. A webserver, for
example, can keep serving the data that's still there on the healthy
drives, and survive the failure of the faulty drive without downtime.
OTOH, with LVM, once a single drive fails, the server looses access to
all data, which then necessitates some downtime while switching to the
backup, etc. LVM isn't always an optimal solution.
> > And since hatred is an irrational thing, you need not look any
> > further than that. ;-)
>
> Well, let's not forget that you are the one who said that you despise
> LVM. As long as you recognize that you aren't rational, I suppose we
> agree on at least one thing. :)
Oh, of course! :-) The ability to be irrational is what makes us human.
Otherwise life would be very boring. ;-)
Best, :-)
Marko
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
