[linux-lvm] LVM VG is not activated during system boot

[Zdenek Kabelac]

Dne 19.3.2015 v 20:06 Stuart Gathman napsal(a):
> On 03/19/2015 02:34 PM, MegaBrutal wrote:
>> Now I think I figured out what's going on. It seems to be
>> Debian/Ubuntu specific, but I post here, maybe Debian/Ubuntu devs are
>> here and see this.
>>
>> Bug report:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1396213
>>
>> What actually makes the VG activation so long is that I have a
>> snapshot. Activating the snapshot takes very long, and bringing up the
>> entire VG takes about 5 minutes. This wouldn't be such a big problem,
>> as I could just patiently wait for the activation (with rootdelay).
>> But it seems something (maybe some kind of watchdog) kills vgchange
>> before it could finish bringing up all VGs. I had the fortune to boot
>> a developmental Vivid, and I've seen some 'watershed' messages stating
>> that 'vgchange' was killed because it was taking "too long". If we'd
>> let 'vgchange' to finish properly, I had the 2nd VG activated
>> properly, which contains my root FS.
>>
>> It's a server. If it has a long boot time, so be it, it doesn't get
>> rebooted often anyway during normal circumstances. But it is required
>> to boot up without user interaction, e.g., when I issue a reboot
>> remotely. The main problem is that currently, user interaction is
>> necessary to pass initrd (as the root VG needs to be manually
>> activated), which means, I can only reboot the server when I'm
>> physically near.
> I've had the same problem on Fedora - so it is not ubuntu specific. On Fedora,
> systemd has a timeout for VG activation.  That can be increased.  However, you
> can flag the snapshot to *not* be activated automatically (Skip activation:
> -k) at volume group activation. That allows the system to boot (remote
> reboot), and then you can manually activate the big snapshot (or automatically
> in a later script) - waiting the requisite 5 or 10 minutes.


Hi

To clean some 'myths' here:


With old-snapshots (non-thin pool based)  you cannot skip activation of 
snapshot -  origin and all its snapshots always have to be active.

If the old-snapshot is larger (in range of GB) it takes quite some time to 
process whole COW volume and read and parse all metadata stored there.
The metadata format for an old snapshot has been targeted to be small and 
occupy minimum extra space - thus if someone keeps it permanently and stores 
there a lot of data it's very very very inefficient.

This problem with old snaps basically cannot be fixed unless there would be a 
completely different new snapshot target ;)

So the advised fix for long term snapshot is to switch to use thin-pool.

Here you will have all the goodies - very fast and efficient snapshots, you 
could easily take snapshot of snapshot and you could also select if you want 
to have snapshot activated or not (and by default it's skipped from activation).

Regards

Zdenek