From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
Chris Friesen <chris.friesen@windriver.com>
Subject: Re: [linux-lvm] unexpected behaviour of "lvresize" with sparse volumes
Date: Thu, 15 Oct 2015 11:24:39 +0200 [thread overview]
Message-ID: <561F70D7.7040302@gmail.com> (raw)
In-Reply-To: <90c8e9f78fb27d380b22d2afdd6225be@alukardd.org>
Dne 15.10.2015 v 09:13 Alexey napsal(a):
> 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
next prev parent reply other threads:[~2015-10-15 9:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 20:18 [linux-lvm] unexpected behaviour of "lvresize" with sparse volumes Chris Friesen
2015-10-15 7:13 ` Alexey
2015-10-15 9:24 ` Zdenek Kabelac [this message]
2015-10-15 16:47 ` Chris Friesen
2015-10-15 19:53 ` Zdenek Kabelac
2015-11-16 15:48 ` [linux-lvm] lvmcache - performance and real life usage? John Stoffel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561F70D7.7040302@gmail.com \
--to=zdenek.kabelac@gmail.com \
--cc=chris.friesen@windriver.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.