-1

I had a LV with a ext4 filesystem.

lubuntu@lubuntu:~$ sudo parted -l
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/lubuntu--vg-root: 499GB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags: 

Number  Start  End    Size   File system  Flags
 1      0.00B  499GB  499GB  ext4

I would like to shrink the LV to 1/10 of its size. I was very bad at estimating the target sizes of the filesystem and the LV, as shown in the below process, and wonder if you could provide some advice to help me do better in the future?

(1) I found out the size of the LV in terms of block counts, and calculate target size

lubuntu@lubuntu:~$ sudo e2fsck -f /dev/mapper/lubuntu--vg-root
/dev/mapper/lubuntu--vg-root: 169997/30433280 files (0.2% non-contiguous), 3088725/121713664 blocks

lubuntu@lubuntu:~$ echo "121713664/10"  | bc
12171366

(2) I shrinked the size of the filesystem on the LV

lubuntu@lubuntu:~$ sudo resize2fs /dev/mapper/lubuntu--vg-root 12171366
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/mapper/lubuntu--vg-root to 12171366 (4k) blocks.
The filesystem on /dev/mapper/lubuntu--vg-root is now 12171366 (4k) blocks long.

Verified the size of the fs changed

ubuntu@lubuntu:~$ mkdir /tmp/root
lubuntu@lubuntu:~$ sudo mount /dev/mapper/lubuntu--vg-root /tmp/root
lubuntu@lubuntu:~$ df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/lubuntu--vg-root   45G  3.5G   39G   9% /tmp/root
lubuntu@lubuntu:~$ sudo umount /tmp/root

(3) Shrinked the size of the LV. I wasn't sure what size to shrink to, so I gave a number "46G" slightly "larger" than "45G" of the filesystem as reported by df -h.

lubuntu@lubuntu:~$ sudo lvreduce -L46G /dev/mapper/lubuntu--vg-root
  WARNING: Reducing active logical volume to 46.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lubuntu-vg/root? [y/n]: y
  Size of logical volume lubuntu-vg/root changed from 464.30 GiB (118861 extents) to 46.00 GiB (11776 extents).
  Logical volume lubuntu-vg/root successfully resized.


lubuntu@lubuntu:~$ sudo fdisk -l

Disk /dev/mapper/lubuntu--vg-root: 46 GiB, 49392123904 bytes, 96468992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

(4) Tried to "extend" the fs to the LV, but why I couldn't?

lubuntu@lubuntu:~$ sudo resize2fs /dev/mapper/lubuntu--vg-root
resize2fs 1.44.1 (24-Mar-2018)
Please run 'e2fsck -f /dev/mapper/lubuntu--vg-root' first.

lubuntu@lubuntu:~$ sudo e2fsck -f /dev/mapper/lubuntu--vg-root
e2fsck 1.44.1 (24-Mar-2018)
The filesystem size (according to the superblock) is 12171366 blocks
The physical size of the device is 12058624 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

(5) Tried again to "extend" the LV to be bigger than fs, but why I couldn't?

lubuntu@lubuntu:~$ sudo lvextend -l 12171366 /dev/mapper/lubuntu--vg-root
  Insufficient free space: 12159590 extents needed, but only 107085 available

(6) Tried a third time to "extend" the LV to a bigger size, and I was lucky my guess was larger than the size of the filesystem. But it was only a wild guess, and how could I derive a target size large enough to hold the filesystem?

lubuntu@lubuntu:~$ sudo lvextend -L 48G /dev/mapper/lubuntu--vg-root
  Size of logical volume lubuntu-vg/root changed from 46.00 GiB (11776 extents) to 48.00 GiB (12288 extents).
  Logical volume lubuntu-vg/root successfully resized.

What did "Inode 30571 extent block passes checks, but checksum does not match extent" mean in the following?

lubuntu@lubuntu:~$ sudo e2fsck -f /dev/mapper/lubuntu--vg-root
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Inode 30571 extent block passes checks, but checksum does not match extent
    (logical block 303, physical block 54575, len 1)
Fix<y>? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/lubuntu--vg-root: 169997/3047424 files (0.6% non-contiguous), 1364383/12171366 blocks

Now I could extend the fs to the LV

lubuntu@lubuntu:~$ sudo resize2fs /dev/mapper/lubuntu--vg-root
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/mapper/lubuntu--vg-root to 12582912 (4k) blocks.
The filesystem on /dev/mapper/lubuntu--vg-root is now 12582912 (4k) blocks long.

Thanks.

2

The intuitive option would be to use the -r, --resizefs option provided by lvresize:

-r, --resizefs

Resize underlying filesystem together with the logical volume using fsadm(8).

The test output shown below is from my CentOS 7 system, but the principle should be same for Ubuntu as well.

We start with a 10GiB LV:

[root@testvm1 ~]# lvs testvg/testlv
  LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  testlv testvg -wi-a----- <10.00g

And now we resize the LV, specifying a target size of 2GiB and the -r flag to resize the filesystem:

[root@testvm1 ~]# lvresize -r -L 2G /dev/mapper/testvg-testlv
fsck from util-linux 2.23.2
/dev/mapper/testvg-testlv: clean, 12/655360 files, 83130/2620416 blocks
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/testvg-testlv to 524288 (4k) blocks.
The filesystem on /dev/mapper/testvg-testlv is now 524288 blocks long.

  Size of logical volume testvg/testlv changed from <10.00 GiB (2559 extents) to 2.00 GiB (512 extents).
  Logical volume testvg/testlv successfully resized.

Verifying that the conversion worked as expected:

[root@testvm1 ~]# lvs testvg/testlv
  LV     VG     Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  testlv testvg -wi-a----- 2.00g

If you insist on doing the two steps separately, it would still be preferable to work with a size rather than counting the number of extents and blocks.

First, we resize the filesystem by specifying the target size:

[root@testvm1 ~]# resize2fs /dev/mapper/testvg-testlv 2G
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/mapper/testvg-testlv to 524288 (4k) blocks.
The filesystem on /dev/mapper/testvg-testlv is now 524288 blocks long.

Then we resize the LV by specifying the same size:

[root@testvm1 ~]# lvresize -L 2G /dev/mapper/testvg-testlv
  WARNING: Reducing active logical volume to 2.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce testvg/testlv? [y/n]: y
  Size of logical volume testvg/testlv changed from <10.00 GiB (2559 extents) to 2.00 GiB (512 extents).
  Logical volume testvg/testlv successfully resized.

Hopefully that addresses the core of your question about how the filesystem and LV could be resized together.


The error from (4) is straightforward. Your resizing efforts resulted in the partition being smaller (12058624 blocks ) than the filesystem (12171366 blocks). This is illogical, so e2fsck is warning you that either your filesystem or your partition table is corrupted.

(5) is occurring because you specified -l 12171366. You're confusing blocks and extents here. A block is a concept used by a filesystem, while an extent is a concept used by LVM. A filesystem block represents the smallest unit of work for the filesystem. An LVM extent is the smallest unit of space that can be allocated when using LVM.

To illustrate this better, here is an example from my ~10 GiB partition and ~10 GiB filesystem:

block count (2620416) * block size (4K) = size of filesystem (10236M)
number of extents (2559) * extent size (4M) = size of volume (10236M)

The block count and block size for an ext4 filesystem can be retrieved with tune2fs -l. The extent size and count can be retried using pvdisplay or pvs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.