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@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@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 _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
