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
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
