60

Today I tried this on my machine with OpenSUSE 12.3 (kernel 3.7):

# resize2fs /dev/mapper/system-srv 2G
resize2fs 1.42.6 (21-Sep-2012)
Filesystem at /dev/mapper/system-srv is mounted on /srv; on-line resizing required
resize2fs: On-line shrinking not supported

/dev/mapper/system-srv is an EXT4 volume.

Is it really unsupported or I am missing something?

Alicia
  • 755
  • 1
  • 5
  • 8

4 Answers4

93

As the message said, you can only grow an ext4 filesystem on-line. If you want to shrink it, you will need to unmount it first.

According to the ext4 filesystem maintainer, Ted Ts'o:

Sorry, on-line shrinking is not supported.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
37

If the case is remote server without console, you can shrink filesystem using initramfs while rebooting. You need to add resize2fs to initramfs and run it before mounting root.

Debian/Ubuntu example:

/etc/initramfs-tools/hooks/resizefs (executable):

#!/bin/sh

set -e

PREREQS=""

prereqs() { echo "$PREREQS"; }

case $1 in
    prereqs)
        prereqs
        exit 0
    ;;
esac

. /usr/share/initramfs-tools/hook-functions

copy_exec /sbin/e2fsck
copy_exec /sbin/resize2fs
    
exit 0

/etc/initramfs-tools/scripts/local-premount/resizefs (executable)

#!/bin/sh

set -e

PREREQS=""

prereqs() { echo "$PREREQS"; }

case "$1" in
    prereqs)
        prereqs
        exit 0
    ;;
esac

# simple device example
/sbin/e2fsck -yf /dev/sda1
/sbin/resize2fs /dev/sda1 5G # see size info below
/sbin/e2fsck -yf /dev/sda1

# complex device example
# activate md-raid containing FS/PV
#/sbin/mdadm -A /dev/md0
# activate VG containing FS
#/sbin/lvm vgchange -ay vg0
# resize
#/sbin/e2fsck -yf /dev/vg0/root # or /dev/md0
#/sbin/resize2fs /dev/vg0/root 5G
#/sbin/e2fsck -yf /dev/vg0/root

Now run update-initramfs -u -k kernel-name to update initramfs for the kernel kernel-name which is set as default in your bootloader (grub). In case of boot failure - you can boot with another unmodified healthy kernel/initramfs. Or you can use all to update all kernels, but then you have no way back.

Check that you do not have any tools in your system that grow filesystem automatically (e.g. cloud-init - comment resizefs in /etc/cloud/cloud.cfg).

Reboot. Check filesystem size. Remove initramfs scripts and run update-intiramfs -u -k kernel-name again.

Now you can shrink underlying device with parted resizepart / mdadm --grow --size= / lvresize -L. The size of the device should be bigger then the size of filesystem from the scripts. The simplest way to make no mistakes: if planned device size - 6G. set fs size in the script to 5G. after fs is resized - resize device to 6G, then grow fs to maximum online with resize2fs /dev/sda1. Now your fs fits perfectly in your device.

For dracut (Fedora,CentOS) use the same logic (/usr/lib/dracut/modules.d).

This is very usefull for crypting or moving rootfs, with no free space available for the new partition.

urusha
  • 479
  • 4
  • 3
  • 5
    This works like a charm. Note that you need to run update-initramfs with the -u option. – Diomidis Spinellis Jan 25 '18 at 18:19
  • Cool. In my case I also needed to `update-grub`. – Wojciech Kaczmarek Aug 03 '18 at 12:32
  • 1
    This totally works, but I didn't think so at first because my hosting provider had stuck an /etc/rc.local entry in that resizes / to maximum size on every boot! Presumably they have a stock image that gets autoexpanded per host. Banished and all is well. – Bill McGonigle Jul 24 '20 at 18:18
  • Shouldn't the `/sbin/resize2fs` be run with `/dev/lg/lv_root` parameter in case of LVM? My logical volume `/dev/lg/lv_root` consist of two physical partitions `/dev/sda2` and `/dev/sda3` therefore I don't think I should be shrinking sdaX directly. – adamsfamily Dec 27 '20 at 14:25
  • By 'run update-initramfs', do you mean to run it with the `-u` parameter? – adamsfamily Dec 27 '20 at 14:59
  • Added more info from comments/questions – urusha Dec 29 '20 at 08:45
  • This is a very helpful answer to a different question. `on-line` == *without rebooting* – reinierpost Aug 04 '21 at 10:52
23

Yes, you can shrink/move/grow a root partition without any reboots (nor livecd, nor usbkey): consult this answer. It's very well written and easy to follow, although quite long and a little risky.

resize2fs can't shrink online ext4 partitions. This limitation, when applied on the root partition may lead you to think you can't avoid rebooting the host to allow shrinking the root partition, which might be something you want to avoid. The linked process will allow you to umount the root partition without any reboots. So in this light it is not strictly speaking online resizing in regards to the mounted state of the partition, however it remains an online resizing in regards to the network online status or reachability of the host.

Of course, if you only want to grow your ext4 partition, you should stick to the conventional working resize2fs solutions.

The general solution I've linked will work on any type of dedicated or VPS solution for instance.

TLDR; this solution implies to pivot_root to tmpfs so you can umount safely your root partition live and fiddle with it. Once done, you'll pivot_root back on your new root partition.

This allows pretty much any manipulation on the root file system (move it, change filesystem, changing it's physical device...).

I have personally used this, and it works very well on debian system also, but the guide was initially written in 2007 for redhat, the answer I've linked was updated for CentOS7. It's highly probable that it'll work on your OpenSUSE, although probably with some adaptation.

Community
  • 1
vaab
  • 512
  • 3
  • 13
  • 14
    This is not 'online' in regards to comparison with 'online grow'. All services must be down and your root filesystem becomes inaccessible. Might be worth contrasting this with the livecd or initramfs/rdshell approach in this comment. I'd hate for people to be confused by this. – Brian Chrisman Jun 14 '16 at 23:16
  • 3
    @BrianChrisman This is indeed a gotcha that merited clarification and that I hope I've covered with an edit in my post. Many thanks for the feedback. – vaab Jun 15 '16 at 07:35
  • What I like about the referenced solution is that it's 'almost online'. I did this particular thing by encoding a small script and tools into the dracut command and launched the resultant initramfs from kexec. If this could somehow keep an ssh session open through the process, that would be best. I suppose if you build the faked root with sshd and needed files, start another sshd (because you're ssh'd in) on another port, then you can ssh to the other port and verify connectivity before continuing to lobotomize the system. – Brian Chrisman Sep 03 '16 at 23:33
-3

yes..

you can use --resizefs flag to lvreduce command.

lvreduce --size -2G  --resizefs /dev/<volumegroup-name>/<logical-volume-name>

Command Example

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
shubham rasal
  • 1
  • how should that work on root fs partition? – djdomi Mar 07 '21 at 11:39
  • 3
    @shubham rasal, read the other answers. The --resizefs option is just a convenience option, which calls the ```fsadm``` tool to resize. This does not change the limitation, which is being posted in the other answers: an ext4 filesystem is not shrinkable while mounted. – Martin Mar 07 '21 at 11:48