[linux-lvm] lvextend operation results in suspended volume
Zdenek Kabelac
zkabelac at redhat.com
Tue Nov 27 09:43:08 UTC 2018
Dne 26. 11. 18 v 19:24 Andrew Hall napsal(a):
Hi
> Can anyone confirm if the following situation is recoverable or not ?
> Thanks very much.
>
> 1. We have an LV which was recently extended using a VG with
> sufficient PE available. A filesystem resize operation was included
> with the -r flag :
Let's question this one first...
You say 'sufficient PE available'.
What makes you think that when you forcibly resize your PV to bigger
size - those extents exists and are available ?
>
> 4. We then see the following in the syslog confirming errors with this
> operation :
>
> Nov 12 17:05:59 servername kernel: device-mapper: table: 253:2: sdb1
> too small for target: start=35156248576, len=37756928,
> dev_size=35156248576
Clearly you have a in your VG PV which does NOT have the size you
made it.
> [root at servername ~]# lvchange -ay /dev/vgname/lvname
> device-mapper: resume ioctl on (253:2) failed: Invalid argument
> Unable to resume vgname-lvname (253:2)
>
> [98337.345943] device-mapper: table: 253:2: sdb1 too small for target:
> start=35156248576, len=37756928, dev_size=35156248576
Nope, activation command is really not doing any magic and will not expand nor
fix your PV.
> [root at servername ~]# pvresize /dev/sdb1
> /dev/sdb1: cannot resize to 4291534 extents as 4296143 are allocated.
> 0 physical volume(s) resized / 1 physical volume(s) not resized
It's too late to rescue the situation this way - your PV with 'way too big
size' is already using/allocating those virtual/non existing extents.
You cannot fix the size of your PV, until you first 'release' those extents
from LVs which have allocated them.
> /dev/sdb1: cannot resize to 4291534 extents as 4296143 are allocated.
>
> Any thoughts on how to potentially recover from this would be most
> greatly appreciated ! Thanks very much.
Well most likely by restoring archive metadata before you've started to fiddle
with PV size by using --force options without really knowing what is happening.
If you don't have archive - you will need to think out, how to reduce LVs
sizes to drop allocation of those nonexisting extents.
Regads
Zdenek
More information about the linux-lvm
mailing list