Hi, I know what is going on: there is some kind of a replay of the snapshot being performed when booting. This results into increasing boot times on increasing snapshot allocation.
I've tested this with a virtual client with incremental blocks changed on a LV which being the source of a snapshot LV. Upon bootup I could detect incremental blocks read on the snapshot COW LV (the largest user) (log the results of iostat in /etc/rc.local). When switching off caching on the client disk I could indeed detect incremental boot times with incremental blocks changed. This up to a point where the boot process stalls due to a timeout requiring manual intervention. (snapshot replay continues in the background). When in a good state a replay of the snapshot should not be required (in my opinion). I guess some kind of journaling is going on within LVM2, requiring at most the last (couple of) transaction(s) on a snapshot to be replayed, not the complete snapshot. This may need to be reported upstream (which I will do when no other comments here). Greetings, Gerben -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1651838 Title: bootup halted, lvms NOT active, one LV lost To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1651838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
