98

I have a 400GB disk with a 320GB ext4 partition. I would like to grow the ext4 partition to use the left space (80GB of free space).

+--------------------------------+--------+
|             ext4               |  Free  |
+--------------------------------+--------+

How could I do this?

I've seen people using resize2fs but I don't understand if it resizes the partition.

Another solution would be to use fdisk but I don't want to delete my partition and loose data. How could I simply grow the partition without loosing any file?

Note: I'm talking about an un-mounted data partition without LVM and I have backups, but I'd like to avoid spending some time on recovery.

masegaloeh
  • 17,978
  • 9
  • 56
  • 104
mimipc
  • 1,767
  • 2
  • 17
  • 27
  • This type of question has been asked and answered a number of times that I am aware of. Have you consulted the archives here? – mdpc May 22 '13 at 02:00
  • @mimipc; have you tried the suggestion offered by @Chris Stryczynski? It is so much easier than making a CD, then booting from that CD, then doing all sorts of unnecessary steps. – Shōgun8 Jun 14 '21 at 03:50

10 Answers10

95

You must begin with the partition unmounted. If you can't unmount it (e.g. it's your root partition or something else the system needs to run), use something like System Rescue CD instead.

  1. Run parted, or gparted if you prefer a GUI, and resize the partition to use the extra space. I prefer gparted as it gives you a nice graphical representation, very similar to the one you've drawn in your question.

  2. resize2fs /dev/whatever

  3. e2fsck /dev/whatever (just to find out whether you are on the safe side)

  4. Remount your partition.

While I've never seen this fail, do back up your data first!

poige
  • 9,171
  • 2
  • 24
  • 50
Flup
  • 7,688
  • 1
  • 31
  • 43
  • 14
    The `resize2fs` man page says: *If the filesystem is mounted, it can be used to expand the size of the mounted filesystem, assuming the kernel supports on-line resizing. (As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 and ext4.).* However, resizing a mounted filesystem is a more dangerous operation, since the kernel could easily freeze or crash while running rarely exercised code, leaving your filesystem in a bad state. – 200_success May 21 '13 at 15:12
  • 1
    True -- but you don't want to be messing around with your partition table with the filesystem mounted. That's why I started with the fs unmounted. – Flup May 21 '13 at 15:15
  • 2
    For ext4, might be `resize4fs` instead on RHEL 5. – Zac Thompson Sep 04 '14 at 20:04
  • 2
    Growing the partition with your root file system should work just fine as long as: `1.` You don't change the starting sector number. `2.` You reboot after changing the partition table before taking the next step. – kasperd Mar 27 '15 at 11:23
  • parted refuses to resize an ext4 partition on CentOS 6. – reinierpost Sep 27 '16 at 14:39
  • 2
    Note that `parted`'s `resizepart` command understands the size "100%", if you want the single partition to fill the entire device. – Joe Oct 20 '19 at 19:28
  • 1
    This works perfect for me. I had a VM, increase the size of the disk and then applied this steps. Run parted (print list, resizepart with the ID selected in the first command, put the new size of the disk and finally run resize2fs and works perfect.). The server it's a Ubuntu server 20.04. – rfrp Jul 28 '21 at 18:34
34

Yes, you can grow EXT4 fs online if you have partition already sorted. Have you got partition sorted? Have you got LVM?

sudo resize2fs /dev/drive_to_grow

fdisk will resize your partition, true, but if this a root partition (or if fact any mounted partition) it will have to be unmounted first. So offline most likely!

As with anything related to disk/fs operations I strongly recommend to have backup, and tested, well understood, recovery process.

tshepang
  • 377
  • 2
  • 12
Chris
  • 633
  • 6
  • 11
  • If you use `fdisk` be sure to check you use MBR and not GPT (with hybrid MBR for example). – stek29 Oct 04 '16 at 14:54
  • 2
    On my debian XEN server I resized my logical volume with `lvextend +40G /dev/vg0/volumeName`, then logged in as root in the vm and entered `resize2fs /dev/xvda2` which **grows the running root filesystem** to the new max. I am not sure if that was needed, but i rebooted the vm after this action. Everything seems fine. – rubo77 Sep 06 '17 at 00:43
  • 2
    @rubo77 No, no need for a reboot, – Chris Sep 11 '17 at 16:05
  • 1
    2022 update: parted can extend the partition even if it is mounted and used (worked for me without data loss) – eNca Aug 18 '22 at 07:02
24

Using growpart and resize2fs example:

$ growpart /dev/sda 1
CHANGED: partition=1 start=2048 old: size=39999455 end=40001503 new: size=80000991,end=80003039
$ resize2fs /dev/sda1
resize2fs 1.45.4 (23-Sep-2019)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 5
The filesystem on /dev/sda1 is now 10000123 (4k) blocks long.
Chris Stryczynski
  • 1,176
  • 2
  • 15
  • 23
12

Note, on some VDS servers you could have non-primary root partition and need to resize Extended partition container first

For example, you've just upgraded your plan and have something like:

Disk /dev/vda: 83886080s
Number  Start    End        Size       Type      File system  Flags
1      2048s    194559s    192512s    primary   ext2         boot
2      196606s  51197951s  51001346s  extended
5      196608s  51197951s  51001344s  logical   ext4

Here /dev/vda2 - is your Extended container. And /dev/vda5 - main partition that we need to resize to full available space.

The simpliest way:

apt-get -y install parted
parted /dev/vda unit s print all # print current data for a case
parted /dev/vda resizepart 2 yes -- -1s # resize /dev/vda2 first
parted /dev/vda resizepart 5 yes -- -1s # resize /dev/vda5
partprobe /dev/vda # re-read partition table
resize2fs /dev/vda5 # get your space
WSR
  • 139
  • 1
  • 4
  • What really helped me, was seeing that you can set `END` to negative number. Usually you don't know the exact linux size of a resized partition - you don't know how to set `END` argument of `resizepart`. Setting it to `-1s` will resize your partition to max. – srigi Jul 02 '18 at 20:27
  • Error: Invalid token -1s – starbeamrainbowlabs Jul 24 '19 at 18:11
  • 1
    This approach (first growing the primary e.g. vda2, then the extended partition e.g. vda6) also worked when using growpart. – Rémi Nov 17 '20 at 08:17
3

Parted doesn't work on ext4 on Centos. I had to use fdisk to delete and recreate the partition, which (I validated) works without losing data. I followed the steps at http://geekpeek.net/resize-filesystem-fdisk-resize2fs/. Here they are, in a nutshell:

$ sudo fdisk /dev/sdx 
> c
> u
> p
> d
> p
> w
$ sudo fdisk /dev/sdx 
> c
> u
> p
> n
> p
> 1
> (default)
> (default)
> p
> w
JTW
  • 39
  • 3
  • 1
    Welcome to Server Fault! Please summarize the steps in the answer itself, to guard against link rot. – 200_success Dec 06 '14 at 02:28
  • Used this process but used gdisk for creating the partition. This allowed me to save the data and to create a partition that was > 2TB – pcnate Sep 18 '16 at 03:11
2

The accepted answer is somewhat outdated: resizing an ext4 filesystem is better done online rather than offline, as the online expansion code path is much more commonly used than the offline one.

The more difficult thing probably is to expand the underlying partition, unless you are using LVM and you have free space into your volume group. To expand a partition online, you can use fdisk or parted; then, you had to run kpartx <device> to inform the kernel of the change. If using LVM, you need to pvresize the just-resized partition before lvresize the volume.

Finally, you can issue resize2fs your filesystem.

shodanshok
  • 44,038
  • 6
  • 98
  • 162
2

parted can resize partitions and their filesystems.

200_success
  • 4,701
  • 1
  • 24
  • 42
  • Thanks, I was using the graphical one and it doesn't support partition resizing. I've seen the option on the cli program, but could you tell me how to use it surely without loosing data? In `resize NUMBER START END`, are START and END the sector numbers? How would I know that? – mimipc May 21 '13 at 08:00
  • It is always recommended to back up your data before doing any risky operation like resizing a partition. `parted` supports a choice of units — for example, use the `s` suffix for sectors, `B` or `GB` for bytes, `%` for percentage of device size, and `cyl` for cylinders. – 200_success May 21 '13 at 08:06
2

Just to clarify how I do this for anyone that is still reading this thread.
If it is the boot partition you want to resize, then you must boot from a bootcd or bootusb "rescue" drive which is just a Live Linux. This allows you to run Linux on the machine other then the drive you want to make changes to.

I think the best "rescue" cd or usb in this case would be a bootable gparted USB or CD
Cases in which you need a rescue image
1. Partition to be expanded is the last partition, but you booted from it and cannot unmount it.
sda1 = boot (or swap)
sda2 = swap (or boot)
sda3 = /
Unused space

  1. If partition to be expanded is NOT the last partition, you must use gparted boot image to move or resize the partitions.
    sda1 = boot
    sda2 = / (partition to be expanded is not last)
    sda3 = swap
    unused space

If you want to change a mounted partition that is not the "root" partition (/), like /home which is a different partition, then there is no need to use a rescue image. This is especially true if is the last partition.
sda1 = boot
sda2 = /
sda3 = /home
unused space
-or-
sda1 = /
sda2 = /home
unused space

This is the situation I have when I take a image from a smaller drive or SSD and move it to a larger SSD.

In this case, you just need to unmount /home while you extend it. But to unmount /home, you need to make sure you are not logged into any user account whose home directory is within it. Since "root" user's home directory is directly under the system root / as in /root, if you can log into root, then you can unmount /home

I logout of a GUI (KDE / Gnome / etc) session and use [CTRL] + [ALT] + [F1] to bring up a shell session.
If you just logged out of a user log in, it can take Linux 20-30 seconds to finish closing any files, so you might get errors trying to umount /home.
1. umount /home (I retry this command if it fails for up to 30 seconds, then go look at other sessions to see if I am "cd /home/xxx" somewhere.)
2. parted /dev/sda
a. resize x (x = partition you want to resize, use "p" to get a list of partitions)
b. Enter last sector of resize = "-1" (minus 1 means 1 sector from end of disk)
c. q (quits parted)
3 resize2fs /dev/sda"x" (x = partition to be resized. This also remounts the filesystem)
4. df -m (I check /home to verify it resized)
I have never lost files or corrupted the drive using this method.

Good luck

Chuck A
  • 21
  • 2
1

I was asked to grow a disk mounted as /scratch on a Dell server running CentOS 7 without interrupting current users. This was an XFS partition on a RAID 0 disk with a normal GPT disklabel. This would work for an ext4 partition in almost exactly the same way - see later.

This is how I did this without dismounting, rebooting or interrupting operations on the system. I just used Linux commands (and Dell's RAID tools):

  1. Growing the physical RAID volume was done by adding two new disks to the server and using the OpenManage Server Administrator tool to add them to the existing RAID volume. This took several days to complete, but involved no further human effort. The server continued to work with lower disk speeds during the reconstruction of the RAID disk.
  2. The size of the disk in blocks had grown from 15623782400 to 23435673600 (512-byte) blocks, but the value of /sys/block/sdb/size was still at the lower value. This was corrected using the command: echo 1 > /sys/block/sdb/device/rescan
    to make the disk driver update its knowledge of the disk size and shape. This seems a poorly-advertised feature: I guessed what it did from the name!
  3. I ran parted to edit the disklabel and move its copy at the end of the disk to the new end-of-disk. Fortunately, it guessed exactly what I wanted to do without encouragement and prompted me. First, the copy of the disklabel: Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)? Fix/Ignore/Cancel? F
    And then the size of the disk as reflected in the disklabel: Warning: Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 7811891200 blocks) or continue with the current setting? Fix/Ignore? F
    So I had to enter "F" twice and then "q" to exit with the disklabel (and its copy) corrected. This fixed most of what had to be fixed without any hard thinking or work.
  4. I had to edit the partition size to fill the disk, but parted wouldn't let me do that while the disk was still mounted - so I used fdisk instead: fdisk /dev/sdb d 1 n 1 (defaults were correct for full size of disk) t 1 11 (That's Microsoft basic data - which is the same as xfs). w
    Notice that I had established that it was using the correct starting block number, 2048. Otherwise, it would not have worked. I was fortunate to use two tools which had the same convention for starting block, but I did check the initial start block first.
  5. I also used parted at this point to give the partition the same name as it used to have since fdisk doesn't support naming partitions. A minor detail.
  6. I used partprobe /dev/sdb (and partprobe /dev/sdb1 for good measure) to make the OS read the partition table again. I think only the first command actually made a difference.
  7. Finally, I used xfs_growfs -d /scratch which took just 1.6 seconds to grow the partition to its final size, filling the newly-grown disk.

This would also work with ext4 volumes: the only difference would be using resize2fs /dev/sdb1 instead of xfs_growfs -d /scratch - and using the correct partition type number for ext4 instead of xfs. The fdisk command can list the type numbers for common disk systems, including ext4.

Patrick McTiernan
  • 11
  • 2
1

You can use fdisk or cfdisk to modify (or re-create) the partition (just be sure you won't change its start boundary), then reboot and resize2fs. But in general it's preferable to use LVM-2 instead of MBR/GPT due it it allows you to bring in those changes w/o kernel rebooting.

poige
  • 9,171
  • 2
  • 24
  • 50