archive mirror
 help / color / mirror / Atom feed
From: Sreyan Chakravarty <>
To: LVM general discussion and development <>
Subject: Re: [linux-lvm] Unusually long boot times with LVM Snapshots
Date: Fri, 20 Nov 2020 21:48:10 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20201120111433.GI1787072@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

On Fri, Nov 20, 2020 at 4:45 PM Bryn M. Reeves <> wrote:

> What type of snapshot are you using? LVM2 allows either "classic" CoW
> snaps,
> or the newer thin provisioned snapshots using the dm-thinp target.
> Classic snapshots are known to have very poor IO performance when multiple
> snapshots of the same volume exist simultaneously (especially for write-
> heavy workloads).
> Thin provisioned snapshots are not normally activated at boot time unless
> they are explicitly requested (via dracut's options) since they
> have the skip activation flag set by default.
How can I check which type of snapshot I am using ?

I am very interested in knowing more about these newer snapshots.

I think I am using the older COW snapshots.

I created it using:

              sudo lvcreate -L 70GB -s -n test_snapshot

Is there any indication in the log of what's happening during the delay?
> Look through the journalctl output to see if there are any messages logged
> while the delay happens.
Yes, I have found the reason for the 3 minute delay:

Nov 20 21:14:15  dracut-initqueue[902]: Scanning devices dm-0  for LVM
logical volumes vgfedora/fedora
Nov 20 21:14:16  dracut-initqueue[927]: inactive Original
'/dev/vgfedora/fedora' [700.00 GiB] inherit
Nov 20 21:14:16  dracut-initqueue[927]: inactive Snapshot
'/dev/vgfedora/pre_kde_Nov_9' [70.00 GiB] inherit
Nov 20 21:17:27  systemd[1]: Found device /dev/mapper/vgfedora-fedora.
Nov 20 21:17:27  systemd[1]: Found device
Nov 20 21:17:27  systemd[1]: Reached target Initrd Root Device.

As you can see it initializing the snapshots.

This is my entire boot log if you need to delve deeper.

> Another option is to use systemd-analyze to look into where the time is
> going during boot. It has various commands including "plot" which will
> generate an SVG plot of the boot timings on stdout. You can then compare
> that with a regular boot to try to understand the difference.

Well I don't know about "plot" but this is the output from "systemd-analyze

3min 30.737s dracut-initqueue.service

     31.399s udisks2.service

     26.650s lvm2-monitor.service

     25.500s systemd-journal-flush.service

     20.289s ModemManager.service

     18.242s abrtd.service

     18.233s avahi-daemon.service

     18.227s bluetooth.service

     17.725s systemd-cryptsetup@luks\x2d2ec7f1ae\x2d6f9b\x2d4896\x2da7b2\x2dbe7809e9d2f4.service

     17.604s firewalld.service

As you can see the 3min delay matches with the above LVM entry from the
boot log.

Again, I am very interested in knowing more about these newer snapshots.
Sreyan Chakravarty

[-- Attachment #2: Type: text/html, Size: 5016 bytes --]

  reply	other threads:[~2020-11-20 16:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19 14:16 Sreyan Chakravarty
2020-11-20 11:14 ` Bryn M. Reeves
2020-11-20 16:18   ` Sreyan Chakravarty [this message]
2020-11-23 13:13     ` Bryn M. Reeves
2020-11-24 11:57       ` Sreyan Chakravarty
2020-11-25  8:45         ` Sreyan Chakravarty
2020-11-25 12:36         ` Bryn M. Reeves
2020-11-25 15:32           ` Sreyan Chakravarty
2020-11-21  8:21   ` Sreyan Chakravarty
2020-11-23 12:52     ` Bryn M. Reeves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: [linux-lvm] Unusually long boot times with LVM Snapshots' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).