Discussion:
[linux-lvm] unexpected behaviour of "lvresize" with sparse volumes
Chris Friesen
2015-10-14 20:18:41 UTC
Permalink
Hi,

I'm running the 3.14 kernel with lvm 2.02.98 and I ran into something unexpected
with lvresize.

I created a sparse volume:

lvcreate -L 25M -V 50M -n sparsevol myvg


This gives output in lvdisplay like this:
LV Size 52.00 MiB
Current LE 13
COW-table size 28.00 MiB
COW-table LE 7

I then resized the volume with lvresize:

lvresize -L 200M myvg/sparsevol


This seems to resize the COW-table, but not the volume itself. Now lvdisplay shows:

LV Size 52.00 MiB
Current LE 13
COW-table size 200.00 MiB
COW-table LE 50


At this point I've got 200MiB of backing store and running "lvs" shows an LSize
of "200m" but I can only write 52MiB worth of data to the volume before it
complains.

Is there a way to expand the "LV Size" shown in lvdisplay so that I can write
the resized amount of data to the volume?

Thanks,
Chris
Alexey
2015-10-15 07:13:34 UTC
Permalink
Hello,

If you look at the output of `lvs myvg`, then you will understand whats
happens.
When you create thin LV without specifying option `-T`, lvm
automatically created TP for you with size equal to -L option.
And when you resize your sparsevol, your TP (auto name lvol1) still have
old size.

Regards,
Alexey Mochkin
Post by Chris Friesen
Hi,
I'm running the 3.14 kernel with lvm 2.02.98 and I ran into something
unexpected with lvresize.
lvcreate -L 25M -V 50M -n sparsevol myvg
LV Size 52.00 MiB
Current LE 13
COW-table size 28.00 MiB
COW-table LE 7
lvresize -L 200M myvg/sparsevol
LV Size 52.00 MiB
Current LE 13
COW-table size 200.00 MiB
COW-table LE 50
At this point I've got 200MiB of backing store and running "lvs" shows
an LSize of "200m" but I can only write 52MiB worth of data to the
volume before it complains.
Is there a way to expand the "LV Size" shown in lvdisplay so that I
can write the resized amount of data to the volume?
Thanks,
Chris
_______________________________________________
linux-lvm mailing list
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Zdenek Kabelac
2015-10-15 09:24:39 UTC
Permalink
Post by Alexey
Hello,
If you look at the output of `lvs myvg`, then you will understand whats happens.
When you create thin LV without specifying option `-T`, lvm automatically
created TP for you with size equal to -L option.
And when you resize your sparsevol, your TP (auto name lvol1) still have old
size.
Mixing 2 things together.

Newer lvm2 tools (then reported 2.02.98) are now creating sparse volumes
as a thin volume in thin-pool.

Old behavior with /dev/zero snapshot is thought still available
either with lvm.conf settings or using --type snapshot.

Now back to the original problem - yep you cannot resize it with tool ATM.

There will be likely added support for 'lvresize -V+'
(it will work for thin volumes & these sparse snapshot)

Basically adding 'virtual size'.

But it has lower priority ATM (as you may resize thin volumes
with -L, and thus users do not have much troubles with it,
expect the logical meaning looks 'wrong' - as resize of thin
volume does not really 'eat' extents from VG.

If you 'urgently' need bigger size -

- make sure modified LVs are rather deactivated.
- 'vgcfgbackup' your vg
- take your favourite text editor (e.g. vi)
- edit size for your '_vorigin' LV (extent_count = ....)
- edit size for respective hidden 'snapshot0' LV (extent_count = ....)
(if you have more then one -
find properly numbered one, the one referencing your _vorigin! -
those 2 LVs should have equal size)
- 'vgcfgrestore' your updated metadata
- activate now bigger sized _vorigin
- check blockdev --getsize64 /dev/vg/sparsevol has new correct size
- enjoy

Regards

Zdenek
Chris Friesen
2015-10-15 16:47:03 UTC
Permalink
Post by Zdenek Kabelac
Post by Alexey
Hello,
If you look at the output of `lvs myvg`, then you will understand whats happens.
When you create thin LV without specifying option `-T`, lvm automatically
created TP for you with size equal to -L option.
And when you resize your sparsevol, your TP (auto name lvol1) still have old
size.
Mixing 2 things together.
Newer lvm2 tools (then reported 2.02.98) are now creating sparse volumes
as a thin volume in thin-pool.
Old behavior with /dev/zero snapshot is thought still available
either with lvm.conf settings or using --type snapshot.
Okay, that's interesting. Do you know when this change went in?

Chris
Zdenek Kabelac
2015-10-15 19:53:45 UTC
Permalink
Post by Chris Friesen
Post by Zdenek Kabelac
Post by Alexey
Hello,
If you look at the output of `lvs myvg`, then you will understand whats happens.
When you create thin LV without specifying option `-T`, lvm automatically
created TP for you with size equal to -L option.
And when you resize your sparsevol, your TP (auto name lvol1) still have old
size.
Mixing 2 things together.
Newer lvm2 tools (then reported 2.02.98) are now creating sparse volumes
as a thin volume in thin-pool.
Old behavior with /dev/zero snapshot is thought still available
either with lvm.conf settings or using --type snapshot.
Okay, that's interesting. Do you know when this change went in?
Version 2.02.112 has configurable setting for this.

Zdenek
John Stoffel
2015-11-16 15:48:33 UTC
Permalink
Hi all,

I've finally upgraded my main server which hosts my home directories
and other files on a bunch of 1Tb and 2Tb disks, all mirrored (triple
mirrors in general since I'm paranoid).

So they're starting to die and give me problems, and it's time to
replace them. I'm thinking of getting a pair of 500Gb SSDs for
boot/lvmcache and a pair of 4Tb WD Blacks for the backend storage.

I've got some KVM running, NFS home directories, LDAP, samba, etc.
I'm willing to dedicate 256Gb of SSD for cache, but before I do this,
I'm curious to know if anyone else is doing this, and how the
performance is in their setup?

I'm running upto date Debbian Jessie on an AMD Phenom(tm) II X4 945
Processor with 16Gb of RAM and a bunch of internal disks on an LSI 8
port controller. Been very nice, but my mix of SATA I, II and III
disks are showing their age.

Thanks for the comments,
John

Loading...