Dieter on the web

You probably know you can resize primary partitions by deleting them and recreating them, keeping the starting block the same but using a higher block as ending point. You can then increase the filesystem.
But what about logical partitions? A while back I had to resize an ext3 logical partition which ended at the end of the last logical partition. I learned some usefull stuff but I only made some quick scratch notes and I don't remember all details so:
Do not expect a nice tutorial here, it's more of a commented dump of my scratch notes and some vague memories.
The information in this post is not 100% accurate
I wondered if I could just drop and recreate the extended partition (and if needed, recreating all contained logical partitions, the last one being bigger of course) but nowhere I could find information about that.


::Read from here

I did find various places where they said parted could "handle all partition and filesystem resizing at once".
this post was quite useful, but he was more lucky then me I guess.
In the parted documentation I couldn't find any restriction other then that xattrs don't work.
But it does not support the dir_index and resize_inode features (bug ticket)
You should be able to use tune2fs to remove these options, do the resize and then put them back. But tune2fs can't put them back and I even had problems removing resize_inode (see below)
Also, I falsely assumed parted would resize the extended partition when you tell it to resize the logical partition.

see here what i did, along with comments and remarks:
[code]
# what features are enabled?
linux-staging:~# tune2fs -l | grep -i feature
Filesystem features: resize_inode dir_index filetype sparse_super large_file [has_journal]

# remove resize_inode feature
linux-staging:~# tune2fs -O ^resize_inode /dev/hda9
tune2fs 1.40-WIP (14-Nov-2006)
Invalid filesystem option set: ^resize_inode # HUH ?

# okay then, lets try debugfs
linux-staging:~# debugfs -w -R "feature -dir_index -resize_inode" /dev/hda9
debugfs 1.40-WIP (14-Nov-2006)
Filesystem features: has_journal filetype sparse_super large_file

# lets do an e2fsck. It gave errors but maybe that's normal (?)
# I wonder whether debugfs just unsets the option flags or actually updates the filesystem to not use these features at all (in the latter case, e2fsck should be clean)
linux-staging:~# e2fsck -f /dev/hda9
e2fsck 1.40-WIP (14-Nov-2006)
Filesystem does not have resize_inode enabled, but s_reserved_gdt_blocks
is 176; should be zero. Fix? yes

Resize_inode not enabled, but the resize inode is non-zero. Clear? yes

Pass 1: Checking inodes, blocks, and sizes
Inode 58 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(5--180) -689 -(32773--32948) -(98309--98484) -(163845--164020) -(229381--229556) -(294917--295092)
-(819205--819380) -(884741--884916) -(1605637--1605812) -(2654213--2654388) -(4096005--4096180) -(7962629--7962804) -(11239429--11239604)
Fix?
Free blocks count wrong for group #0 (0, counted=177).
Fix? yes

# lets doublecheck the enabled features
linux-staging:~# tune2fs -l /dev/hda9 | grep -i feature
Filesystem features: has_journal filetype sparse_super # Hey ? where did 'large_file' go?

# do the resize of the logical partition in parted

# enable features
tune2fs -O dir_index /dev/hda9
debugfs -w -R "feature large_file resize_inode" /dev/hda9

# now all should be good, right? lets do an e2fsck
linux-staging:~# e2fsck -f /dev/hda9
e2fsck 1.40-WIP (14-Nov-2006)
Resize inode not valid. Recreate? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +689
Fix? yes

/dev/hda9: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda9: 132012/7038048 files (6.2% non-contiguous), 12076862/14368126 blocks

# I also got a lot of these errors:
Assertion (block < EXT2_SUPER_BLOCKS_COUNT(fs->sb)) at ../../../../libparted/fs/ext2/ext2.h:226 in function ext2_is_data_block() failed.

# now here are some more scratch notes. I forgot exactly why and what I did, so I'm just putting them here for reference.

#in fdisk, delete logical, recreate, reboot and do online resize with resize2fs
linux-staging:~# resize2fs /dev/hda9
resize2fs 1.40-WIP (14-Nov-2006)
Filesystem at /dev/hda9 is mounted on /home; on-line resizing required
old desc_blocks = 4, new_desc_blocks = 5
Performing an on-line resize of /dev/hda9 to 19872397 (4k) blocks.
resize2fs: Invalid argument While trying to add group #512

linux-staging:~# resize2fs /dev/hda9
resize2fs 1.40-WIP (14-Nov-2006)
Please run 'e2fsck -f /dev/hda9' first.

linux-staging:~# e2fsck -f /dev/hda9
e2fsck 1.40-WIP (14-Nov-2006)
Superblock last mount time is in the future. Fix? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Filesystem contains large files, but lacks LARGE_FILE flag in superblock.
Fix? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/hda9: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda9: 132012/8208384 files (6.2% non-contiguous), 12113624/16777216 blocks
linux-staging:~# resize2fs /dev/hda9
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/hda9 to 19872397 (4k) blocks.
The filesystem on /dev/hda9 is now 19872397 blocks long.

linux-staging:~# mount /dev/hda9

# suprisingly, all data looked still intact.
[/code]

After this experience I actually created a VM to do some testing and figured out this is the better way (no fsck errors, and goes much faster):

• use parted only to increase the extended partition
• drop and recreate logical partition with fdisk
• resize2fs the logical partition