[clug] Storage

Paul Wayper paulway at mabula.net
Sun May 7 08:32:18 UTC 2017

On 07/05/17 08:08, David C via linux wrote:
> Hello all,
> We have many servers at work laid out with a normally partitioned OS drive
> supporting filesystems and one or more partitioned drives supporting
> everything else on a large logical volume.
> So if you're building a virtual server, why would you embrace the risk and
> annoyance of resizing a partition table, compared with allocating the raw
> disk (with offset) as an LVM pv?
> If allocated without a partition table, extending filesystems is quick and
> nearly risk free.

I agree.  I always use LVM to allocate storage, because of its flexibility.

With LVM thin provisioning you can also 'overcommit' your disk, which means
that as long as every VM doesn't fill its disk at the same time, you can
allocate more space to VMs than you have physical storage.  So a hundred 10G
VMs can exist on a 500GB disk rather than taking a terabyte.  It's exactly the
same as overcommitting memory.  But that's a risk you want to think about
before you go into it.  It's also much easier to thin provision LVs as clones
of existing disks, which make it easier to spin up and tear down short lived
VMs for e.g. testing.

I tend to think of layering LVM on top of MD RAID1 or RAID10.  I found out the
other day that MD's implementation of RAID10 can read from all disks in
parallel, where RAID0 on RAID1 only reads from half of the disks.  It
functions exactly the same for everything else, so that's pretty cool.

Have fun,


More information about the linux mailing list