> Am 18.05.2019 um 11:31 schrieb Roman Mamedov <r...@romanrm.net>:
> 
> On Sat, 18 May 2019 11:18:31 +0200
> Michael Laß <be...@bi-co.net> wrote:
>> 
>> pvdisplay -m:
>> 
>>  --- Physical volume ---
>>  PV Name               /dev/sda1
>>  VG Name               vg_system
>>  PV Size               119.24 GiB / not usable <22.34 MiB
>>  Allocatable           yes (but full)
>>  PE Size               32.00 MiB
>>  Total PE              3815
>>  Free PE               0
>>  Allocated PE          3815
>>  PV UUID               mqCLFy-iDnt-NfdC-lfSv-Maor-V1Ih-RlG8lP
> 
> Such peculiar physical layout suggests you resize your LVs up and down a lot,
> is there any chance you could have recently shrinked the LV without first
> resizing down all the layers above it (Btrfs and LUKS) in proper order?

This is mostly a result from my transition from several ext4 volumes to one 
btrfs volume, where I extended the new btrfs volume several times. I quickly 
checked my shell history and it was something like this:

cryptsetup luksFormat /dev/mapper/vg_system-btrfs
cryptsetup luksOpen --allow-discards /dev/mapper/vg_system-btrfs cryptsystem
mkfs.btrfs -L system /dev/mapper/cryptsystem
lvextend -l100%free /dev/vg_system/btrfs
cryptsetup resize cryptsystem
btrfs fi resize max /

The previous ext4 volumes had been resized a couple of times as well before. 
However, the last resize operation was in 2015 and never caused any issues 
since then.

The btrfs file system which I now use to reproduce the issue is freshly 
created. So if there is any fallout from these resize operations, it would have 
to be in dm-crypt or LVM. Just to double-check, I compared the output of 
“cryptsetup status” and “lvdisplay”:

lvdisplay shows me that vg_system/btrfs uses 3511 LE. Each of those is 32MiB 
which makes
3511 * 32 * 1024 * 1024 / 512 = 230096896 sectors

cryptsetup shows me that the volume has a size of 230092800 sectors and an 
offset of 4096 which makes
230092800 + 4096 = 230096896 sectors

So this seems to match perfectly.

>>  --- Physical Segments ---
>>  Physical extent 0 to 1248:
>>    Logical volume    /dev/vg_system/btrfs
>>    Logical extents   2231 to 3479
>>  Physical extent 1249 to 1728:
>>    Logical volume    /dev/vg_system/btrfs
>>    Logical extents   640 to 1119
>>  Physical extent 1729 to 1760:
>>    Logical volume    /dev/vg_system/grml-images
>>    Logical extents   0 to 31
>>  Physical extent 1761 to 2016:
>>    Logical volume    /dev/vg_system/swap
>>    Logical extents   0 to 255
>>  Physical extent 2017 to 2047:
>>    Logical volume    /dev/vg_system/btrfs
>>    Logical extents   3480 to 3510
>>  Physical extent 2048 to 2687:
>>    Logical volume    /dev/vg_system/btrfs
>>    Logical extents   0 to 639
>>  Physical extent 2688 to 3007:
>>    Logical volume    /dev/vg_system/btrfs
>>    Logical extents   1911 to 2230
>>  Physical extent 3008 to 3320:
>>    Logical volume    /dev/vg_system/btrfs
>>    Logical extents   1120 to 1432
>>  Physical extent 3321 to 3336:
>>    Logical volume    /dev/vg_system/boot
>>    Logical extents   0 to 15
>>  Physical extent 3337 to 3814:
>>    Logical volume    /dev/vg_system/btrfs
>>    Logical extents   1433 to 1910


Reply via email to