ext3 offline resizing

Theodore Ts'o tytso at mit.edu
Tue Jun 21 22:20:31 UTC 2005

On Tue, Jun 21, 2005 at 08:58:59PM +0200, jjletho67-3txe at yahoo.it wrote:
> Ok now is much more clear. In our opinion in this
> moment (without waiting for a fix) what is the better
> solution for an ext3 based system which will often
> need to resize its partitions (offline with resize2fs)
> ?
> Disabling the resize_inode feature is safer ? Or is it
> better to use the resize_inode feature and choose a
> better initial size ?
> Is the "1000*(original size)" limit I guessed correct
> ?
> I'm sorry but i wasn't able to find any deep
> documentation about resize_inode.

It's should be better to use the resize inode.  The filesystem
inconsistency reported by e2fsck is just e2fsck being very nit-picky;
there is no danger of losing data as a result of this.  

If you use the resize inode, it will allow you to do on-line resizes
up to 1000*original_size by default; this figure however can be
adjusted by "mke2fs -E resize=" option --- see the mke2fs man page for
more details.  If the resize inode present, off-line resizes will use
those reserved block to allow for fast resizing that doesn't require
moving data blocks belonging to files, directories, or the inode table
around.  It's not a limit, though; if you try to resize a filesystem
bigger than 1000*original size (or whatever on-line resizing limit you
specified to mke2fs), resize2fs will still work, but it may have to
move filesystem data blocks around in order to accomplish the resize.

The costs of the online resize inode is that you have to pay a slight
penalty upfront in reserved blocks; but given the size of modern
disks, the overhead isn't particularly great.  

						- Ted

More information about the Ext3-users mailing list