ext2prepare8
Ext2 filesystem resizing preparation tool
Usage
ext2prepare [-d] [-f] [-q] [-v] [-V] device size[b|K|M|G|T]]
Overview
The ext2prepare command modifies an unmounted ext2 filesystem on device so that ext2online(8) program can later resize the mounted filesystem to be at least as large as size although the actual maximum size will be some larger multiple of various filesystem parameters. While ext2prepare must be run on an unmounted filesystem, device does not have to currently be as large as size. This allows one to later increase the size of device and do the resize while the filesystem is mounted.
If the size parameter does not have a modifier, it will be taken to be in ext2 filesystem blocks (which can be 1k, 2k, or 4k - use dumpe2fs(8) to find out more information about the current filesystem). The modifiers b, K, M, G, or T mean the size parameter is given in 512-byte blocks, kilo-, mega-, giga-, or terabytes respectively.
The ext2prepare program does not change the size of the actual device. If you wish to enlarge a filesystem, you must make sure you expand the underlying device first. This can be done online for Logical Volumes by using lvextend(8) from the LVM package, or possibly via md or RAID facilities in the hardware if you are not using partitions. It is not possible to do this by using the fdisk(8) family of tools to extend a partition while it is mounted (at least the author has not been able to successfully do this).
Because of the original design of the ext2 filesystem did not have online resizing in mind, there are certain limitations to the amount of resizing that can be done while the filesystem is mounted, if you haven't done any preparation for the resize. The default block size for ext2 was 1k blocks until v1.15 of e2fsprogs (1999), where it changed to 4k blocks for filesystems larger than 512MB.
With no filesystem preparation, it is always possible to resize to the next 256MB boundary for 1k filesystems, the next 2GB boundary for for 2k filesystems, and the next 16GB boundary for 4k filesystems. By using ext2prepare on an unmounted filesystem, it is possible for ext2online(8) to increase the size of a mounted ext2 filesystem to at least the given size by reserving blocks for group descriptors within the ext2 filesystem structure. ext2prepare does this by moving metadata blocks while the filesystem is unmounted, and then allocating the freed blocks to a reserved inode so that ext2online(8) can later use these blocks to safely enlarge the filesystem while the filesystem is in use.
Options
-
-d, --debug -
Turn on debugging messages.
-
-f, --force -
Force preparation without first checking the filesystem state.
-
-q, --quiet -
Do not print anything but error messages.
-
-v, --verbose -
Turn on normal verbose status messages.
-
-V, --version -
Print the version number and exit.
Return values
0 Resizing successful
- 1 Error in options or command-line parameters.
- 2 Error while preparing filesystem.
Examples
The following example shows how to test ext2prepare with a spare partition. First a filesystem of 32MB is created on the device. The filesystem is then prepared to grow to a maximum size of 10GB, mounted, and the size is verified. The filesystem is then extended to fill the device (the default action when no size is given), and the new size is verified.
mke2fs /dev/vg0/lvtest 32768
ext2prepare /dev/vg0/lvtest 10G
mkdir /mnt/test
mount -o debug,check=strict /dev/vg0/lvtest /mnt/test
df /mnt/test
ext2online -d -v /dev/vg0/lvtest
df /mnt/test
By using the debug and check=strict options to mount, as well as the -d and -v options to ext2prepare, we will see the user-space status messages, and the kernel messages will be logged by syslog.
Warning
Note that resizing a mounted filesystem is inherently dangerous and may corrupt filesystems, although no errors resulting in data loss have ever been reported to the author. In theory online resizing should work fine with arbitrarily large filesystems, but it has not yet been tested by the author on a filesystem larger than 11GB. Use with caution. Backups are always a good idea, because your disk may fail at any time, you delete files by accident, or your computer is struck by a meteor.
Releases
2 releases since Debian 3.0 (Woody); the text changed 1 time.