Differences

This shows you the differences between two versions of the page.

--- filesystem:increase_the_size_of_an_ext2_ext3_or_ext4_filesystem [2019/11/29 12:07] – removed peter
+++ filesystem:increase_the_size_of_an_ext2_ext3_or_ext4_filesystem [2020/07/15 20:50] (current) – old revision restored (2016/07/07 12:20) 95.91.41.38
@@ Line 1: / Line 1: @@
+====== Filesystem - Increase the size of an ext2, ext3 or ext4 filesystem ======
+To increase the size of an ext2, ext3 or ext4 filesystem so as to completely fill a block device
+Increasing the usable capacity of a filesystem on a resizeable block device (such as a partition or logical volume) is a two-step process:
+  - Increase the size of the block device.
+  - Increase the size of the filesystem to fill the block device.
+The method for the first step depends on the type of block device, and the method for the second step depends on the type of filesystem.  These instructions cover step 2 in the case where the filesystem is ext2, ext3 or ext4.
+**NOTE**:  The method described here is not specific to LVM, and could be usefully applied to any block device that can be resized without destroying its contents.
+Resizing is performed using the **resize2fs** command, however there are some preparatory steps that you can take which will reduce the risk of data loss:
+  * Ensure that you have an up to date backup.
+  * Unmount the filesystem.
+  * Check the filesystem.
+**NOTE**:  In older documentation you may encounter references to the programs **ext2resize** and **ext2online**.  These are now obsolete and should not normally be used.
+===== Ensure that you have an up to date backup of the filesystem =====
+Extending a filesystem is a moderately high-risk operation, so if you take backups of the data at all then this is a good time to perform one.
+Optionally, unmount the filesystem
+Modern versions of the Linux kernel can expand an ext3 or ext4 filesystem while it is mounted.  This has obvious benefits, but provides significantly more opportunity for things to go wrong.  For this reason it would be prudent to unmount the filesystem before resizing it unless there is a good reason not to:
+<code bash>
+umount /dev/vg01/foo
+</code>
+At the time of writing, current (2.6-series) kernels did not support online resizing of ext2 filesystems.  Unmounting is therefore essential in that case.
+===== Check the filesystem =====
+One factor that would increase the risk of failure is if there are pre-existing errors in the filesystem. For non-mounted filesystems, this risk can be reduced by checking the filesystem before resizing it:
+<code bash>
+fsck -f /dev/vg01/foo
+</code>
+**resize2fs** will refuse to run if it thinks the filesystem ought to be checked first, however there is no harm in running fsck regardless provided that you are confident the filesystem is not mounted.
+For mounted filesystems you should definitely not do this, otherwise fsck may itself cause data loss.
+===== Resize the filesystem =====
+Use the **resize2fs** command to resize the filesystem:
+<code bash>
+resize2fs /dev/vg01/foo
+</code>
+You can specify the required final size of the filesystem, but there is no need to in this instance because it defaults to the size of the device.  The command is the same whether or not the filesystem is mounted.
+The amount of time taken by resize2fs to enlarge a filesystem is broadly comparable to that taken by **mkfs** to create a new one.  The example described here took about a minute during testing, but this will obviously vary with the speed of the hardware.  The amount of data in the filesystem does not greatly affect the time taken.
+You can request a progress bar using the -p option.  This appears to work when resizing offline, but not when resizing online.
+When resize2fs has finished it should report the new size of the filesystem in blocks:
+<code>
+The filesystem on /dev/vg0/foo is now 31457280 blocks long.
+</code>
+Note that resize2fs does not change the block size, even if a freshly created filesystem on the same device would default to a larger size.  For this reason, recreation may be a better option if you need to turn a very small filesystem into a very large one.
+===== Testing =====
+You can obtain an approximate value for the new size of the filesystem using the **df** command once it has been remounted.  The output should be similar to the following:
+<code>
+Filesystem           1K-blocks      Used Available Use% Mounted on
+/dev/mapper/vg01-foo  123854820    192188 117371688   1% /mnt
+</code>
+The number of 1k blocks reported (123854820 in this case) is slightly less than the full size of the device (125829120).  This is normal.  If you want to see the exact size, or do not want to mount the filesystem, then you can use the **dumpe2fs** command:
+<code bash>
+dumpe2fs -h /dev/vg01/foo
+</code>
+The output is quite lengthy, but should contain the following information:
+<code>
+Inode count:              7864320
+Block count:              31457280
+Reserved block count:     1572736
+Free blocks:              30915658
+Free inodes:              7864309
+First block:              0
+Block size:               4096
+Fragment size:            4096
+</code>
+The block count should be the same as the value reported by **resize2fs**.  The size in bytes is the block count multiplied by the block size.
+===== See also =====
+  * [[LVM:Increase the size of an LVM logical volume|Increase the size of an LVM logical volume]]
+  * [[Filesystem:Reduce the size of an ext2, ext3 or ext4 filesystem|Reduce the size of an ext2, ext3 or ext4 filesystem]]