2

I set-up a server with LVM, and I just recently extended one of my logical volumes from 25TB to 35.

root@server:/home/user# df -h /dev/mapper/vg--data-lv--data
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg--data-lv--data     25T  9.3T   15T  40% /DATA

root@server:/home/user# lvs /dev/mapper/vg--data-lv--data
  LV      VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv-data vg-data -wi-ao---- 34.90t

In order to apply the change to the filesystem, I ran e2fsck and then resize2fs, but resize2fs keeps asking me to run e2fsck first :

root@server:/home/user# resize2fs /dev/vg-data/lv-data
resize2fs 1.43.5 (04-Aug-2017)
Please run 'e2fsck -f /dev/vg-data/lv-data' first.

root@server:/home/user# e2fsck -f /dev/vg-data/lv-data
e2fsck 1.43.5 (04-Aug-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg-data/lv-data: 672943/836247552 files (3.1% non-contiguous), 2546845858/6689948672 blocks
root@server:/home/user# resize2fs /dev/vg-data/lv-data
resize2fs 1.43.5 (04-Aug-2017)
Please run 'e2fsck -f /dev/vg-data/lv-data' first

I've been looking all over the web, but I still can't get what the problem is about. I found someone having a similar issue, and it was because e2fsck and resize2fs were running on different versions. This is not my case as you can see above (e2fsprogs is version 1.43.5).

I also found this very old Ubuntu bug report refering to a time issue. I checked, and I indeed had a network issue which resulted in a wrong time on my system. I fixed it, and I even checked the hwclock was synced with the systems date. But it still doesn't work, and I still can't resize my filesystem.

I absolutely don't get this, since there's not even a single error/warning message (and since it worked one day before when doing the exact same operation on a smaller lvm partition).

Maybe someone has an idea ??

EDIT :

Problem solved thanks to wurtel ! Easy solution : don't unmount the partition and do an online resizing... The solution is so easy and seems so obvious... I feel really stupid... Thank you very much

root@server:/home/user# mount -a
root@server:/home/user# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg--data-lv--data     25T  9.3T   15T  40% /DATA

root@server:/home/user# resize2fs /dev/vg-data/lv-data
resize2fs 1.43.5 (04-Aug-2017)
Filesystem at /dev/vg-data/lv-data is mounted on /DATA; on-line resizing required
old_desc_blocks = 3191, new_desc_blocks = 4467
The filesystem on /dev/vg-data/lv-data is now 9367890944 (4k) blocks long.

root@server:/home/user# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg--data-lv--data     35T  9.3T   24T  29% /DATA
  • Have you downgraded ext3 to ext2? Have you umounted it? – Rui F Ribeiro May 30 '18 at 16:41
  • 2
    Try mounting the filesystem first, as then the resize utility will assume that the filesystem is OK (otherwise it couldn't have been mounted) and will do an online resize. – wurtel May 31 '18 at 6:55
0

Broken fix in 1.44.4 (for ext4)

root@server:~# resize2fs -p '/dev/sdc5' 414144512K
resize2fs 1.44.4 (18-Aug-2018)
Filesystem at /dev/sdc5 is mounted on /mnt; on-line resizing required
resize2fs: On-line shrinking not supported

use first:

root@server:~# fsck /dev/sdc5

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.