Resizing an Ext3 Partition

From PrgmrWiki
Revision as of 20:32, 15 November 2011 by Nik (talk | contribs) (update centos version)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


Here is a procedure to resize an existing ext3 partition, relying on the fdisk, tune2fs, and resize2fs utilities available when booting your domU via the Centos 5.5 "Rescue" image.

This method may be a bit old school - guessing there could be easier ways (for example parted may not work reliably with ext3 but might be used instead of resize2fs after converting to ext2). Anyway .... I have tested the method described here in the Prgmr xen environment, and it seems to work fine. YMMV - please feel free to suggest better (hopefully also tested) alternatives here.

Before trying this procedure, be sure to back up the existing disk image somewhere safe (on a different server/disk) "just in case" ...

Boot the "Rescue" image, mount partition to check free space.

[root@domU]# mkdir /tmp/xvda1

[root@domU]# mount /dev/xvda1 /tmp/xvda1

[root@domU]# df /tmp/xvda1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1            11812024   1300604   9911396  12% /tmp/xvda1

Unmount partition, inspect details provided by fdisk.

[root@domU]# umount /tmp/xvda1/

[root@domU]# fdisk -l /dev/xvda
Disk /dev/xvda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1               1        1494    12000523+  83  Linux

[root@domU]# fdisk -s /dev/xvda1
12000523

Verify ext3 filesystem consistency.

[root@domU]# fsck -n /dev/xvda1
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
PRGMRDISK1: clean, 32998/1501440 files, 339474/3000130 blocks

Remove journal to work with ext2 instead of ext3 filesystem.

This may be safer than trusting resize2fs to handle ext3 journal correctly.

[root@domU]# tune2fs -O ^has_journal /dev/xvda1
tune2fs 1.39 (29-May-2006)

Verify ext2 filesystem consistency.

[root@domU]# e2fsck -f /dev/xvda1
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

PRGMRDISK1: ***** FILE SYSTEM WAS MODIFIED *****
PRGMRDISK1: 32998/1501440 files (1.0% non-contiguous), 306672/3000130 blocks

Resize ext2 filesystem.

In this example, the filesystem size is reduced to 3000 MB. If the existing filesystem contained over 3000 MB of data, then data would be lost at this point. Beware!

[root@domU]# resize2fs /dev/xvda1 3000M
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/xvda1 to 768000 (4k) blocks.
The filesystem on /dev/xvda1 is now 768000 blocks long.

Modify partition table to reflect new filesystem size.

Note here I specified new partition size 5% greater than new filesystem size (ie +3225600K instead of +3000M) - the extra 5% may not be absolutely necessary - for the sake of this example a slight abundance of caution at the expense of some disk space. (See notes re journal size etc.)

[root@domU]# fdisk /dev/xvda
The number of cylinders for this disk is set to 1566.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/xvda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1               1        1494    12000523+  83  Linux

Command (m for help): d
Selected partition 1

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1566, default 1): 
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1566, default 1566): +3225600K

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Verify ext2 filesystem size and consistency.

[root@domU]# fsck -n /dev/xvda1
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
PRGMRDISK1: clean, 32998/391680 files, 271848/768000 blocks

Switch ext2 filesystem back to ext3 by adding journal.

[root@domU]# tune2fs -j /dev/xvda1
tune2fs 1.39 (29-May-2006)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first.  Use tune2fs -c or -i to override.

Remount to verify updated partition size and contents.

[root@domU]# mount /dev/xvda1 /tmp/xvda1/

[root@domU]# df /tmp/xvda1/
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1             3022800   1103800   1796120  39% /tmp/xvda1

Everything okay? Good. Done. Reboot and enjoy.


Notes

The default size of ext3 journal will change when filesystem is resized by this method. So, while we started out using a total of 1,300,604 1K blocks in the original 11,812,024 K filesystem ...

Before:

[root@domU]# df /tmp/xvda1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1            11812024   1300604   9911396  12% /tmp/xvda1

After:

[root@domU]# df /tmp/xvda1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1             3022800   1103800   1796120  39% /tmp/xvda1

... after shrinking the filesystem to 3000M and creating a new journal file, only 1,103,800 K are now used. But we didn't lose ~200 MB of data! The discrepancy is due to the new, smaller journal size.


To inspect journal size, first use tune2fs to determine journal inode:

[root@domU]# tune2fs -l /dev/xvda1 | grep -i "journal inode"
Journal inode:            8

Pass the journal inode number as an argument to the debugfs "stat" command:

[root@domU]# debugfs -R "stat <8>" /dev/xvda1 | grep -i "user:.*size:"  
debugfs 1.39 (29-May-2006)
User:     0   Group:     0   Size: 67108864

So, the new ext3 journal size for the 3000 MB filesystem is 64 MB (67,108,864 bytes).

One might see larger ext3 journal sizes (up to 400 MB) when working with larger filesystems.


See also http://wiki.archlinux.org/index.php?title=Ext3_Filesystem_Tips#Reclaim_Reserved_Filesystem_Space