Open bmr-cymru opened 3 weeks ago
It's impressive that nothing crashes except the snapshot data.
Well - seems like we allowed some operation that should remain prohibited.
There was likely some idea in the past - which however needs further thinking through -
to support 'lvresize -V' to size 'virtual' volume - which in however needs quite some effort.
This then would allow to resize 'virtual' snapshot size (use visible snapshot volume) - and 'physical' snapshot size (storage for exception store) - allowing users to eventually deal with device size changes - but ATM - this is much easier usable with thin-pool - and dm-snapshot target is in some 'limbo' state so not much progress...
Related to #163.
If
lvresize
is used to shrink a CoW snapshot's exception store and the LV does not contain a file system recognised by lvm2 the command will allow the exception store to be truncated beyond in-use exceptions. This does not invalidate the snapshot but leads to IO errors on the snapshot device and attempts to access beyond the end of the CoW device:The snapshot now gives IO errors on read:
dmseg shows out-of-bounds access to the CoW device:
(dm-2 is fedora-test1--snap-cow, dm-3 is fedora-test1--snap)
It's not clear from a quick read of
dm-snap-persistent.c
whether thesectors_allocated
from the snapshot status line can be relied upon to find the highest-allocated exception in order to check if a shrink is safe. Rejecting all attempts to shrink the CoW device size would be better than the current behaviour.