Bug 1011681 - thin snapshot LV doesn't grow with related thin LV
Summary: thin snapshot LV doesn't grow with related thin LV
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: 19
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: LVM and device-mapper development team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-24 20:07 UTC by Heinz Mauelshagen
Modified: 2013-10-22 11:25 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-22 08:05:30 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Heinz Mauelshagen 2013-09-24 20:07:53 UTC
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:
Always

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
65011712
[root@o ~]# blockdev --getsz /dev/tst/home_Fedora-19
62914560

Comment 1 Heinz Mauelshagen 2013-09-24 20:10:22 UTC
  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 08:29:00 UTC
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 08:33:02 UTC
Agree with Zdenek Kabelac.  Working as intended.

Comment 5 Zdenek Kabelac 2013-10-02 08:40:46 UTC
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.