On Fri, Nov 20, 2020 at 4:45 PM Bryn M. Reeves <bmr@xxxxxxxxxx> 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: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.
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
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
_______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
