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

[MegaBrutal]

I resend this message in plaintext, as I think the previous
HTML-formatted one didn't reach the list, as I don't see it in the
archives.


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.