Re: Unusually long boot times with LVM Snapshots

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: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
_______________________________________________
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/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux