[linux-lvm] LVM performance vs direct dm-thin
Demi Marie Obenour
demi at invisiblethingslab.com
Sun Jan 30 22:14:43 UTC 2022
On Sun, Jan 30, 2022 at 04:39:30PM -0500, Stuart D. Gathman wrote:
> On Sun, 2022-01-30 at 11:45 -0500, Demi Marie Obenour wrote:
> > On Sun, Jan 30, 2022 at 11:52:52AM +0100, Zdenek Kabelac wrote:
> > >
> >
> > > Since you mentioned ZFS - you might want focus on using 'ZFS-only'
> > > solution.
> > > Combining ZFS or Btrfs with lvm2 is always going to be a painful
> > > way as
> > > those filesystems have their own volume management.
> >
> > Absolutely! That said, I do wonder what your thoughts on using loop
> > devices for VM storage are. I know they are slower than thin
> > volumes,
> > but they are also much easier to manage, since they are just ordinary
> > disk files. Any filesystem with reflink can provide the needed
> > copy-on-write support.
>
> I use loop devices for test cases - especially with simulated IO
> errors. Devs really appreciate having an easy reproducer for
> database/filesystem bugs (which often involve handling of IO errors).
> But not for production VMs.
>
> I use LVM as flexible partitions (i.e. only classic LVs, no thin pool).
> Classic LVs perform like partitions, literally using the same driver
> (device mapper) with a small number of extents, and are if anything
> more recoverable than partition tables. We used to put LVM on bare
> drives (like AIX did) - who needs a partition table? But on Wintel,
> you need a partition table for EFI and so that alien operating systems
> know there is something already on a disk.
>
> Your VM usage is different from ours - you seem to need to clone and
> activate a VM quickly (like a vps provider might need to do). We
> generally have to buy more RAM to add a new VM :-), so performance of
> creating a new LV is the least of our worries.
To put it mildly, yes :). Ideally we could get VM boot time down to
100ms or lower.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20220130/a4391e2b/attachment.sig>
More information about the linux-lvm
mailing list