Bug 1011681 - thin snapshot LV doesn't grow with related thin LV
thin snapshot LV doesn't grow with related thin LV
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-09-24 16:07 EDT by Heinz Mauelshagen
Modified: 2013-10-22 07:25 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-22 04:05:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Heinz Mauelshagen 2013-09-24 16:07:53 EDT
Description of problem:

Took snapshot of 30GiB thin provisioned LV.
Extended thin provisioned LV but its snapshot sticks to the old size.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create eg. 30GiB thin LV
2. take a snapshot of it
3. grow thin LV by eg. 1G
4. check size of its snapshot LV

Actual results:
Snapshot still 30GiB in size.

Expected results:
Snapshot LV has the same size 31GiB as its origin thin LV

Additional info:
[root@o ~]# lvs tst
  LV             VG   Attr      LSize  Pool Origin Data%  Move Log Copy%  Convert
  home           tst  Vwi-aotz- 31.00g pool         27.92                        
  home_Fedora-19 tst  Vwi-aotz- 30.00g pool home    27.96                        
  pool           tst  twi-a-tz-  7.00t               0.21                        
[root@o ~]# blockdev --getsz /dev/tst/home
[root@o ~]# blockdev --getsz /dev/tst/home_Fedora-19
Comment 1 Heinz Mauelshagen 2013-09-24 16:10:22 EDT
  LVM version:     2.02.98(2) (2012-10-15)
  Library version: 1.02.77 (2012-10-15)
  Driver version:  4.25.0
Comment 2 Zdenek Kabelac 2013-09-25 04:29:00 EDT
Thin snapshots are 'independent' LVs - they only have a reference to the origin, but otherwice they are living it's own life from the moment of taking snapshot - i.e. if you resize origin - you typically need to resize also its filesystem - so the snapshot remains 'intact'.

So IMHO it's not a bug but a feature.
Comment 4 Joe Thornber 2013-10-01 04:33:02 EDT
Agree with Zdenek Kabelac.  Working as intended.
Comment 5 Zdenek Kabelac 2013-10-02 04:40:46 EDT
Behavior from description was only related to the lvm1 - since this very old metadata format was not able to keep persistent information about the size of snapshoted device - this was fixed with newer lvm2 format which preserves the size of snapshot.  New thin snapshot just adds a new feature when user could change size totally independently - thus snapshot could be resized while origin is active and many more combinations and availability state is not enforced like with old snaps. The old-snaps were quite limited with changing sizes - since only origin could have been extended when it is of-line and the snapshot resizes only COW device and not the 'snapshot' itself.

We have now somewhat problematic terminology in use - since we use 'snapshot' for 2 different things in the many documents.

We call snapshot a COW device which keeps diff blocks from origin as well as the device which is a snapshot of origin.

So while for thin snapshots - we keep COW blocks in the thin pool, with old snapshots we use the term 'snapshot' for 2 different things and we probably should make it more clear about which device is being modified with i.e. lvresize operation.

Note You need to log in before you can comment on or make changes to this bug.