The online ext2 resize patch allows you to "safely" growing of an
ext2 filesystem WHILE IT IS MOUNTED. The growth of
the filesystem can happen while the FS is in use, with open files,
and no impact to programs reading from or writing to the filesystem.
I only quote "safely" because the patch is not in widespread use, so
there may be some unresolved issues with the patch. I'm especially not
responsible for people without a backup - always a good idea even when
not doing things like this.

There are patches available for 2.0, 2.2, 2.4, and 2.6. The actual
functionality of the patch hasn't changed much since its inception.

The ext2 online patch DOES NOT give you the ability to resize
DOS partitions (i.e. partitions you made with fdisk or
similar). You need to be using something like a Logical Volume Manager(
LVM)
for Linux, or MD RAID devices, or hardware RAID units (or for testing,
loopback and not-full-size filesystems on larger partitions).

With a patched kernel you can:
Grow ANY mounted ext2 FS to the end of a group (8MB for 1k blocks,
128MB for 4k blocks) without any tools besides the kernel patch (using
mount -o remount,resize=size device).

With the ext2online tool + patched kernel you can:
Grow any mounted ext2 FS to the end of EXT2_DESC_PER_BLOCK groups
(normally 256MB for 1k blocks, 16GB for 4k blocks) without having to
unmount the filesystem. This again works on any normal ext2 filesystem
when you have the patched (19991014 or later, or 20000226 or later for
sparse filesystems) kernel running. The ext2online tool will create
group descriptors, and groups in the new areas of the disk without
touching the running filesystem, and then the online kernel resize will
start using these new groups.

With the ext2prepare + ext2online tools + patched kernel you can:
Grow a mounted prepared filesystem to the limits of what you prepare for
(up to 2 TB). The reason for the "prepared" part is the need to add a
group descriptor block after the next multiple of 32/128 groups are used
up. The ext2prepare filesystem moves the metadata around in an unmounted
filesystem so that you can increase the number of group descriptor blocks
in a mounted filesystem when you need to. Since each reserved block
will give 256MB, 4GB, or 16GB for 1k, 2k or 4k block sizes respectively,
not much space needs to be reserved in order to grow for most needs. It
is good to note that a "prepared" filesystem is still a legal ext2
filesystem in every way, so it is possible to use it with an unpatched
kernel.

BUGS/CAVEATS:

For 1k block filesystems, there is a current limit of growth at 45GB if
you start with a size smaller 23GB. Similarly, there is a limit for 2k
block filesystems at 362GB if you start with a filesystem smaller than
181GB. This is due to the requirement of reserving the GDT blocks in an
inode, and I don't want to use triple indirect blocks for this (laziness
mostly). You probably don't want to use a 1k block size for filesystems
that large anyways, as there is a huge amount of wasted space in the
metadata and fsck times are very slow. However, if you grow a filesystem
incrementally (ie don't double the size at the above limits), then it is
possible to grow the filesystem arbitrarily.

You can't resize a filesystem with ext2online when it is unmounted, but
who cares at that point, since you can always use ext2resize. In the
future, it may be that ext2online is integrated with ext2resize, so
there is a single tool for resizing filesystems whether they are mounted
or unmounted.

If testing the patch, you should mount with "debug,check=strict" options,
so that the debug messages are printed to the kernel syslog. You need
something like "kern.*<tab>/var/log/kern.log" in your
/etc/syslog.conf to output all the kernel messages, and then
"tail -f /var/log/kern.log" in another window so you can watch what's
going on while you resize.

I haven't tested on anything other than an x86 platform. I think I have
all of the endian conversions for the 2.2 patch on big-endian platforms,
but I have no way of testing this. The user tools definitely do not
work on non-x86 platforms.

Let me know of any issues at all with the patch. Testing wise,
I've been running resizes every few seconds on a filesystem while
simultaneously copying 11 MB/1500 files into the filesystem into a new
directory each time. This goes on for several hours (thousands of +2MB
or +random resizes) until I fill the disk with many thousands of files
(1GB worth). No problems with the latest patches.

The 2.0 patch is not currently maintained. If there is real demand for it,
a new patch could be made. However, it would also be easy (if you really
need it) to manually apply the 2.2 patch to the 2.0 kernel, since they are
nearly identical for the code in question.
Latest 2.0 patch: online-ext2-2.0-19991014.diff

online-ext2-2.2-19990727.diff had problems compiling because ext2_get_group_desc() is an external function in 2.2 and not 2.0, had ext2_update_groups() in balloc.c when it could have been in super.c and be a static function.

Thanks to Miguel de Icaza for his
ext2volume patch
for the basis for this work. While he worked with whole disks, I can use LVM
or MD to handle the growth for me (meaning less kernel mods), and I'm left
with a single normal filesystem afterwards. The other plus of my patch is that
the resize code path is only used at resize time, whereas Miguel's was used for
each block access, much like LVM, so there was more overhead.
Andreas Dilger <adilger AT users DOT sourceforge DOT net>