On 04/14/2017 11:53 AM, Gionatan Danti wrote: > > Yeah, I understand that. In that sentence, I was speaking about > classic LVM snapshot. > > The dilemma is: > - classic LVM snapshots have low performance (but adequate for backup > purpose) and, if growing too much, snapshot activation can be > problematic (especially on boot); > - thin-snapshots have much better performance but does not always fail > gracefully (ie: pool full). > > For nightly backups, what you would pick between the two? You've summarized it nicely. I currently stick with classic snapshots for nightly backups with smallish CoW (so in case backup somehow fails to remove the snapshot, production performance doesn't suffer). The failure model for classic snapshots is that if the CoW fills, the snapshot is invalid (both read and write return IOerror), but otherwise the system keeps humming along smoothly (with no more performance penalty on the source volume). Before putting production volumes in a thinpool, the failure model needs to be sane. However much the admin is enjoined to never let the pool be empty - it *will* happen. Having the entire pool freeze in readonly mode (without crashing the kernel) would be an acceptable failure mode. A more complex failure mode would be to have the other volumes in the pool keep operating until they need a new extent - at which point they too freeze. With a readonly frozen pool, even in the case where metadata is also full (so you can't add new extents), you can still add new storage and copy logical volumes to a new pool (with more generous metadata and chunk sizes). It is not LVMs problem if the system crashes because a filesystem can't handle a volume suddenly going readonly. All filesystems used in a thinpool should be able to handle that situation. _______________________________________________ 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/
