[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Resizing LVM issue


I have encrypted LVM on one of my Wheezy machines, and recently noticed that /tmp space was too low for one application (In fact it was about 350 MB and I wanted it to be around 2.5 GB). So I tried to make /tmp space bigger while I was mounted and online, but vgdisplay reported no free space for that action (something like that):

sys@localhost:~$ sudo vgdisplay
  --- Volume group ---
  VG Name               localhost
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  9
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                6
  Open LV               6
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               297.85 GiB
  PE Size               4.00 MiB
  Total PE              76249
  Alloc PE / Size       76249 / 297.85 GiB
  Free  PE / Size       0 / 0
  VG UUID               fbCaw1-u3SN-2HCy-

Then I decided to shrink /home for some 2 gig and to add to /tmp :

sys@localhost:~$ sudo lvresize --size -2G /dev/mapper/localhost-home
sys@localhost:~$ sudo lvresize --size +2G /dev/mapper/localhost-tmp

According to df, it did so:

sys@localhost:~$ df
Filesystem                 1K-blocks     Used Available Use% Mounted on
rootfs                        329233   219069     93166  71% /
udev                           10240        0     10240   0% /dev
tmpfs                         304560      756    303804   1% /run
/dev/mapper/localhost-root    329233   219069     93166  71% /
tmpfs                           5120        0      5120   0% /run/lock
tmpfs                         609100       80    609020   1% /run/shm
/dev/sda1                     233191    31650    189100  15% /boot
/dev/mapper/localhost-home 289312040 11966292 262649508   5% /home
/dev/mapper/localhost-tmp    2408315    11231   2273129   1% /tmp
/dev/mapper/localhost-usr    8647944  5745732   2462916  70% /usr
/dev/mapper/localhost-var    2882592   916600   1819560  34% /var

It seems that /dev/mapper/localhost-tmp was about 2.4 GB so I wanted to resize newly changed filesystems:

sys@localhost:~$ sudo resize2fs /dev/mapper/localhost-home
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/mapper/localhost-home is mounted on /home; on-line resizing required
resize2fs: On-line shrinking not supported

Similar output was with e2fsck:

sys@localhost:~$ sudo e2fsck -p /dev/mapper/localhost-home
/dev/mapper/localhost-home is mounted.
e2fsck: Cannot continue, aborting.


Obviously I should not have done that while being mounted (or did not know the proper syntax), however it did not complain with resize2fs /dev/mapper/localhost-tmp

But after the next reboot, it stopped when tried to perform Checking file systems:

/dev/mapper/localhost-home: The filesystem size (according to the superblock) is 73481216 blocks
The physical size of the device is 72956928 blocks
Either the superblock or the partition table is likely to be corrupt!

/dev/mapper/localhost-home: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
         (i.e., without -a or -p options)

Anyway, the other segments of the filesystem were clean, so by CONTROL-D it was possible to terminate the shell, so to resume system boot.

My question is how to solve that inconsistency issue now? At first I tried with dumpe2fs in searching for backup superblocks, then with e2fsck -b <one_of_those_backup_superblocks_from_the_list>, but without resolution. I mean the inconsistency is not fixed. Probably I do not use e2fsck properly even when /home is not mounted. So the machine still keeps stopping during the boot at filesystem check, so I have to continue booting by pressing CONTROL-D.

Any suggestion?

Reply to: