Re: [linux-lvm] Unusually long boot times with LVM Snapshots

From: Sreyan Chakravarty <sreyan32@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Unusually long boot times with LVM Snapshots
Date: Fri, 20 Nov 2020 21:48:10 +0530	[thread overview]
Message-ID: <CAMaziXss8HAjSjV6g5kFjzkxnYCGZSowfZcT-nJVRm-tf0rJEQ@mail.gmail.com> (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 <bmr@redhat.com> 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 rd.lvm.lv 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
/dev/mapper/vgfedora-fedora

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
/dev/disk/by-uuid/03aef3ba-dca1-4cba-a3f5-36c5c0fe948e.
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.
https://pastebin.com/raw/275JPvZB

> 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
blame"

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.
-- 
Regards,
Sreyan Chakravarty

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