Comments on How To Resize ext3 Partitions Without Losing Data

Many thanks. Works like a charm!

No.  It appears that resize3fs may not support ext3 in any way for some or all of the 2.4.xx kernel series.  The man page says it  supports 'onlne' (ie while mounted) resizing of ext3 with 2.6.xx - implying (I thought) but not saying that it swould support umounted resizing of ext3 for other kernel series.

Certainly it borked ext3 filesystems several times on the 2.4.31 kernel in my tests - clearly it had destroyed the journal.  fsck reported lots of errors and the data was maimed or gone.

This could mean that removing the journal before resizing and recreating it afterwards is the way to go in this case - I will try that.

 Suggest: Try it out on test partitions before trying this on real data with the 2.4.xx kernel.

 I'm also looking for another tool.

Uhhh.. who the hell is running 2.4 kernels in 2009?  If you want to run unsupported ancient kernels then go ahead -  but it's not the fault of current software.

 resize2fs works fine for ext3.  Stop trying to scare people.

Off topic:

This is a common but uninformed misconception about 2.4.xx.  The 2.4 kernel series is still in development with the last stable release on 2009-08-13.

There is better driver support for hardware in 2.6.xx and these kernels have significantly different internals but it would be a misnomer to describe 2.4.xx as obsolete just yet.  Less popular, yes.

I have followed all steps mentioned in the article ...good article thanks for that.

My initial size of / partition was 14GB by command 'df -kh'

I reduced it by 5GB by following all steps and now when I do 'df -kh '

my size of / partition is 9GB ....its OK...but when I do check it by command 

#fdisk -s /dev/sda1 .......its again showing 14GB....

 Thats why I am so confused... and still no one has given answer for it.

Any help should be appreciated.

Thanks.

it' work.

 sda7 210Gb to 180Gb, only display 175Gb

df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             9.7G  2.0G  7.3G  21% /
/dev/sda8             996M   55M  890M   6% /tmp
/dev/sda7             175G   49G  118G  30% /home
/dev/sdb1             227G  163G   53G  76% /backup
/dev/sda3             9.7G  7.9G  1.4G  86% /usr
/dev/sda2             9.7G  8.8G  425M  96% /var
/dev/sda1              99M   23M   72M  24% /boot
tmpfs                 2.0G  7.9M  2.0G   1% /dev/shm
 

Problem can't detect free space.

fdisk /dev/sda

The number of cylinders for this disk is set to 30515.
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): n
No free sectors available
 

Embedded devices :P And for me as regular user, it is my router with custom firmware based on linux 2.4..

"resize2fs can resize ext2 file systems, but not ext3 file systems" That's strange, looking at resize2fs man page that starts like: "The resize2fs program will resize ext2 or ext3 file systems." and includes even this: "As of this writing, the Linux 2.6& kernel supports on-line resize for filesystems mounted using ext3 only." So ext3 seems to be supported better than ext2, not vice versa!

Support for ext3 was added to resize2fs in version 1.19, more than 7 years ago.  There is no reason to convert to ext2 first unless you are running a REALLY old system.

For ext3 only growing can be done online; for reducing ext3 you have to unmount filesystem and to remove journal too, removing journal drives ext3 to ext2 - that`s author mentioned, and that`s right. Nice article ("for text users").

The command: resize_reiserfs /dev/hda4 will resize a partition image in /dev/hda4 (which is smaller than /dev/hda4) to fill out the partition. It takes one or two seconds. Jade @ http://m.domaindlx.com/LinuxHelp/

Yeah, but messing with REISER could kill you (pun intended).

Hey, this howto is great. I don't do resizing of partitions often enough to remember all the necessary steps. ;) One comment I have though: you describe above a security margin of 3%-5%. But in fact, computers are precise. So when the filesystem is n 4k-Byte-Blocks, then indeed the partiton size can be set exactly to that length. In my case, the blocks given with the ext2 resizer were 4k blocks. The blocks given in fdisk were 1k blocks. So all I had to do to get the right partition size is to multiply the block number given from resize2fs by 4 to have it fitting exactly. I ran a `fsck -f` on the filesystem afterwards without problems. To verify my claim you can resize2fs on your 3%-5% larger filesystem and then take the number of blocks returned by resize2fs, multiply them by 4 and you will see your actual partition size in fdisk.

The way I get around this is to shrink the filesystem to less than my final desired size, then resize the partition to the final size, and issue one last resize2fs to expand the filesystem to fill the paritition.  This is one more step, and is more time consuming if you have a large partition, but it reduces the chance of making an error in the size calculation.

Hi

I'm afreaid this failed - I got a kernel panic and dont have any more time to spare in a recovery - I HAVE to do a re-install...

Too bad...

Click!

Thor

Hi,

I have to say that this article was written for the more seasoned user, I tried it only "two" days adter a very-first-"virgin" install - usefull as the info is, it should NOT be tried by inexperienced users, yet...

Nonetheless, briliant article! Belongs in a "bible" of sorts!

Thanks for this info!

Thor

Worked fine for me. Thanks a lot!

Thank you for this how-to, it work great for me

 Once you've booted of knopix, why not just use gparted?

 It's got a nice graphical interface, never failed me, and takes care of resizing file system and partition all in one?

For one, gparted doesn't support LVM

I found the 'calculation' and fudge of 3-5% to not work for me. I did the following, instead of 'resize2fs /dev/sda1 600M', I ran 'resize2fs -M /dev/sda1'. This makes a minimum size. This can take some time. Then I ran fdisk and re-partitioned. After this fsck (which failed using the other method complaining about a mis-match between the device and file system sizes.), I re-ran 'resize2fs /dev/sda1', resizing the ext2 filesystem to use the full size of the allocated partition. I then re-ran the fsck command and followed all the steps. The 2nd resize doesn't take long (for me). This method allows all disk space to be used.

It works great with primary partitions but not for extended. Do you know how to solve for the those?

Dangerous HOWTO.

All the messing about significantly  increases risk of dataloss; use gparted and do it right.

For lvm it's trivial, just:

lvextend /dev/xenvg/everything -L +5G
resize2fs /dev/xenvg/everything

I'd just like to say that this information allowed me to merge 2 partitions and ths make use of some unused space.

For historical reasons I had a 1Tb disk wih a 150Gb partition (/dev/sda8) followed by a 750Gb partions (/dev/sda9). sda8 was mostly unused, but sda9 was filling up.

The procedure I used was:

1, Move as much as possible from sda9 to sda8

2. Shrink sda9 and create a new empty partition (sda10).

3. Move as much as possible from sda9 to sda10.

4 Shrink sda9 and create a new empty partition (sda10 again, te old sda10 got renumber to sda11!).

5. Move as much as possinle from sda9 to new sda10.

6. Repeat until sda9 is empty.

7. Merge sda8 with sda9 and resize.

8 Move contents of the next partition (sda12 as I recall) to the expanded sda8.

9. Repeat for each partition until sda8 covers all the space of the old sda8+sda9.

10. Fix up mount points and references. :-)

Thanks for documenting the process. It definitely helped me out!

Hi

Thanks for the great HOWTO! 

Knoppix does not work for me cos i got a console-only system (nslu2) where i wanted to resize. I do not have a LVM on it and im happy to, bacause i need a real physical partition for DRBD (if i'm right...)

So the HOWTO worked just well - a bit risky i think, but with a proper backup....

Greez

Arnd

this looks very confusing.. i couldnt do it...

Why does the resize2fs command took so long? even more than 15minutes..

It's literally moving all the bits on disk so that they are in the right place after the resize. Given that disks don't fill up linearly, the section at the end could be full.

Hey so, I just followed your tutorial on a non-critical system.  I was using a gparted rescue CD to do the work.  I had 2 partitions.  a primary and a swap.  I wanted to shrink the primary, trash my swap, and recreate both at a smaller size and location.

 resizing the fs worked just fine and dandy.  but then I got to the part where you say to delete and recreate partitions.  I did this all through fdisk as described, but after I wrote the partition table, I went into gparted to view everything and make sure it worked right, well guess what, my sda1 partition was completely empty.  Just straight up showed as blank.  When I tried to mount it, I got all the regular unrecognized fs type errors you get when you try to mount an unfortmatted partition.

 I don't think I skipped a step, but maybe I did.  Seriously though, what is up with that?!

Hi,

What's the purpose we run fsck -n /dev/sda1?

Why I got error after it.

The superblock could not be read or does not describe a correct ext2 filesystem. ..........

Thanx!

Didn't work for me.  Any ideas?

[root@syxift01 ~]# umount /opt/iress_ftp
[root@syxift01 ~]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              6190664   3231964   2644232  56% /
none                    517268         0    517268   0% /dev/shm
/dev/sda2             10309828    794716   8991396   9% /opt
/dev/sda3              3099292    741312   2200544  26% /var
[root@syxift01 ~]# fsck -n /dev/sdb1
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
/iress_ftp: clean, 664/30277632 files, 53626986/60548889 blocks
[root@syxift01 ~]# tune2fs -O ^has_journal /dev/sdb1
tune2fs 1.35 (28-Feb-2004)
[root@syxift01 ~]# fdisk /dev/sdb

The number of cylinders for this disk is set to 45689.
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): d
Selected partition 1

Command (m for help): 1
1: unknown command
Command action
   a   toggle a bootable flag
   b   edit bsd disklabel
   c   toggle the dos compatibility flag
   d   delete a partition
   l   list known partition types
   m   print this menu
   n   add a new partition
   o   create a new empty DOS partition table
   p   print the partition table
   q   quit without saving changes
   s   create a new empty Sun disklabel
   t   change a partition's system id
   u   change display/entry units
   v   verify the partition table
   w   write table to disk and exit
   x   extra functionality (experts only)

Command (m for help): p

Disk /dev/sdb: 375.8 GB, 375809638400 bytes
255 heads, 63 sectors/track, 45689 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System

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

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

Calling ioctl() to re-read partition table.
Syncing disks.
[root@syxift01 ~]# partprobe
[root@syxift01 ~]# resize2fs /dev/sdb1
resize2fs 1.35 (28-Feb-2004)
resize2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
[root@syxift01 ~]# e2fsck -f /dev/sdb1
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[root@syxift01 ~]# e2fsck -f /dev/sdb
e2fsck 1.35 (28-Feb-2004)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[root@syxift01 ~]# e2fsck -b 8193 /dev/sdb1
e2fsck 1.35 (28-Feb-2004)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[root@syxift01 ~]# dumpe2fs /dev/sdb1
dumpe2fs 1.35 (28-Feb-2004)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock

Thanks for this article.
I had to share a big partition with ext4 fs from a netboot on my server and had only an old version of parted, not handling ext4. And no way to upgrade it on the reasd-only rescue system. I followed these instructions (except for the 'margin', 3% of 1 TB is much space !!!, I simply added about 1Mo, just in case...) and it worked perfectly.

This HOWTO is dangerous.  Ditto.  It *might* work for a primary partition but it would fail for an extended partition. In my case, it did.  The step right after writing the table, And seeing all the other comments of things gone wrong, I should have been more careful. Now trying to savage my partition with TestDisk...  wish me luck, i need it.

I'm sorry to hear about your bad luck.  I actually skipped the comments for I cared not for the contents of the partition or the whole drive really.  I even skipped the parts of turning off the journalling seeing as I was figuring in seven years they'd be able to get it to work with more than just ext2.  And also when I had to create the new partition it was originally partition number 8 turned into 10 and then I had to figure out what the beginning was seeing as I deleted the OLDER partition 8 previously then I just input what was shown before deleting it and instead of doing complicated math I just hit +8000M seeing as I'd resized it to 8000M and it was the same number so why not.  I even skipped fsck -s by accident.  What does it do ?

The number of inodes seems to be lower than they were if I remember correctly but 0.5M is still more than I'll ever need can someone tell me if this is correct ?  Because in mkfs.ext4 it says that you can't change the number of inodes once the process is finished.

Boy this stinks. Wish something had gone wrong for me seeing as all valuables are off that drive.  Hopefully you are able to recover some stuff!  I'm wondering I have no tech background but if it was the tuning of the system that messed it up.  Oh and in case it's not clear anything over 4 isn't a primary so no clue how I got it to work.  Wait did you say extended ?  You mean logical right ?  Not the partition that gets created to create logical partitions and seems to just be a container for them right ?  Hmm...maybe this is a different case then ?  Primary/Logical is alright to change but not Extended ?

Seams like this page is outdated (?). I used this to resize my root partition on ubuntu 12.04 and it was working good BUT: 

 When fdisk ask you for cylindars according to the guide.. it will ask you for Sectors instead and it looks like it calculates the default values for you that you could use

My LiveUSB disn't find fack but instead I could use fsck.ext4. 

Great guide hower!

God kills a kitten each time you use sudo su.

Please learn to RTFM and use sudo -i instead.

Not much more to say than thank you for the perfect solution. I tried this on a raspberry PI+. Had a Rasbian OS on a SD-Card added to the USB-Port. Followed the instruction exactly as outlined and everything worked well on first try. Resized a linux (Raspian) ext3 Partition (second Part.on SD) from 15.1GB down to 7.1GB. It booted without any problems.

Really good and clean, thanks.
Peter

my df shows this now:

Filesystem      Size  Used Avail Use% Mounted on

rootfs           46G   27G   17G  63% /

/dev/root        46G   27G   17G  63% /

at what point did you mean to add that step?

Dear Falko, i want 

Extend to 100GB as you can see my space going Redline and my websites giving me problems to load... please help me for linux...

Thanks in Advance

Dear,

May i know if i use "D" to delete root partition into fdisk command. after that, use "N" for create new partition for increase the volume.the data will keep into partition or deleted?

thanks

doesnt work for me please help