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

[MegaBrutal]

2015-03-20 9:30 GMT+01:00 Zdenek Kabelac <zkabelac at redhat.com>:

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

I understand this is a by-design feature of LVM snapshots, and I accept it
as is. The problem for me is not the long activation time, but the fact
that initrd stops waiting for the full activation to complete. It gives up
and kills the vgchange process.

I understand initrd behaviour may be distro-specific.


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).
>

Well, thin pools seem nice, but I don't see them being matured enough for
production use. For example, basic VG management like reducing or splitting
a VG failed for me when a thin pool was present in the VG, even if the
split would have not affected the thin pool itself. I also failed to get
rid of missing PVs when a thin pool would have been affected – while
„vgreduce --removemissing --force” promises to remove affected LVs, it
couldn't get rid of the thin pool. When I posted a thread about the issue
here, no one bothered to answer.
(It is here:
https://www.redhat.com/archives/linux-lvm/2015-March/msg00001.html)

Also, as far as I know, thin snapshots can only be created of thin LVs
residing in the same thin pool. That means, you can't make a thin snapshot
of any LV, and one shouldn't keep critical LVs (e.g. root FS) in thin pools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20150320/a799ee63/attachment.htm>