2015-03-20 9:30 GMT+01:00 Zdenek Kabelac <zkabelac@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)
(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.
_______________________________________________ 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/
