Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi,
> # pvs
> /dev/drbd0: open failed: Falscher Medien-Typ
> PV VG Fmt Attr PSize PFree
> /dev/drbd1 replicated lvm2 a- 120,00G 76,05G
> /dev/md1 localvg lvm2 a- 1,81T 1,67T
What's this talk of drbd0? I guess it can be ignored?
> But when setting it to 140G it tells me, " Pretending size is 293601280
> not 251657856 sectors."
> That means my PV is bigger than the underlying LVM.
>
> But even when setting the PSize to 120G, drbd does not recognize this:
>
> # pvresize -v -d --setphysicalvolumesize 120G /dev/drbd1
This sounds like a Bad Idea.
If drbd is unaware of the resize of its own backing device, enforcing
the resize of the contained data is probably bound to give you pain.
> # drbdadm -- resize drbd.drbd1
>
> # cat /proc/drbd
> version: 8.3.7 (api:88/proto:86-91)
> GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by
> phil at fat-tyre, 2010-01-13 17:17:27
> 0: cs:Unconfigured
> 1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r----
> ns:0 nr:0 dw:312 dr:4876 al:2 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b
> oos:104854364
>From the manual about online resizing:
"""
To do so, two criteria must be fulfilled:
1.
The affected resource's backing device must be one managed by a
logical volume management subsystem, such as LVM or EVMS.
2.
The resource must currently be in the Connected connection state.
"""
You fail one of these.
Find out what's using your device (is one of the LVs in the replicated
group mounted?) and do an offline resize. Seeing as you use external
metadata, this is trivial as per the manual.
Is the peer Backing Device also being resized?
Cheers,
Felix