Resizing Ext2 Ext3 Partitions: resize2fs and fdisk

[Sepero]

:
(At the time of this writing, I had tried gparted and parted. They didn't work, and qtparted was (is?) still quite dangerous.)




I've been struggling with this for a couple hours now and I finally figured it out, Again. I say it like that because I figured out the math once before on resizing, but I never wrote it down (so I friggin forgot). I figured that this is as good a place to record my notes as any.

Anyway, here is my goal:
To resize (shrink) an ext3 partition from 50Gb to... as small as possible!
(These instructions should work for ext2 also.)

By the way: I am actually doing this to my system as I type this. Hopefully it will make for a more interesting HowTo. (Hopefully, I won't destroy my system. ;) )
First thing to do:
FORCE a file system check on the partition (Make sure you put YOUR correct partition!).
# fsck.ext2 -f /dev/hda3

After the filesystem check, it will print some info like this:
/dev/hda3: 25218/6099296 files (1.6% non-contiguous), 8860236/12199359 blocks

I should be able to shrink it to at least "8860236" (the second number from the right).
So, resize the filesystem:
# resize2fs /dev/hda3 8860236

Now run file system check again (force isn't needed unless you mount it):
# fsck.ext2 /dev/hda3

And I see something different:
/dev/hda3: clean, 25218/4431392 files, 8807906/8860236 blocks

Ah, now I can shrink even more, so we do it again:
# resize2fs /dev/hda3 8807906


To shrink your filesystem more, you might be able to repeat the above processes another time or two. Additionally, you might be able to save a little time by trying to resize with a smaller number on the first resize operation.


OK, FILESYSTEM HAS BEEN RESIZED. NOW TO FIND OUT HOW THE PARTITION SHOULD BE RESIZED.


Run file system check to see the size of our filesystem:
# fsck.ext2 /dev/hda3
e2fsck 1.38 (30-Jun-2005)
/dev/hda3: clean, 25218/4398688 files, 8806880/8806880 blocks

Ok, take the far right number "8806880". This is the current size of our filesystem in 4k units (4096 byte units). Multiply this by 4096 to give us the actual number of bytes used: 36072980480. Record this number for later use, it is exactly how many bytes the filesystem uses.

:
Your filesystem might Not be in 4K units! To be certain run this command:
tune2fs -l /dev/hda3 | grep "Block size"

It will output your units in bytes. If it shows:
Block size: 1024
-or-
Block size: 2048

Then your filesystem uses 1K or 2K block size. Be sure to make appropriate changes when following this HowTo.




Now run fdisk to see our current partitions
# fdisk -l /dev/hda

Disk /dev/hda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 486 3903763+ 83 Linux
/dev/hda2 * 487 1220 5895855 83 Linux
/dev/hda3 1221 7295 48797437+ 83 Linux

Ok, now there are only 3 areas of useful information here for us. The "Start", "End", and "Units" information. I can see that my partition (hda3) starts at 1221 and ends at 7295. There is a bit of a catch here though, the partition INCLUDES 1221. So in counting, it is actually from 1220 to 7295. So to find out how big the current partition is, we subtract: 7295 - 1220. Giving us 6075.

The Units are 8225280 bytes each. If we multiply 6075 by 8225280, it gives us the size of our current partition in bytes 49968576000. We want to change this to the lowest possible number of bytes, but it Must be larger than our filesystem.

Now take the number from earlier (bytes used by the filesystem 36072980480). Divide this number by the Units used in fdisk (for me 8225280). And we get "4385.623404917522565". Ok, this will be the size (roughly) we need to change our partition to.

First we round it UP from the decimal to make sure there is room for our filesystem, changing it to 4386. Now we need to calculate: If the partition starts at 1220, and is 4386 long, then it must end at: 1220 + 4386 = 5606. So that's it, we 've done the math. My new partition must start at the same place as my old partition (1221), and it will now end at 5606.

:
In recap, for resizing the partition, the only things you really need to know are the "current partition start point" and the "new partition end point". The formula for finding the new partition end point for fdisk is this:
partition_start = 1221
partition_unit_size = 8225280
filesystem_blocks = 8806880
filesystem_block_size = 4096

filesystem_bytes = filesystem_blocks * filesystem_block_size

required_partition_units = rounded_up( filesystem_bytes / partition_unit_size )

new_partition_end = required_partition_units + partition_start - 1When using fdisk, you will keep 'partition_start' the same, and 'new_partition_end' will be the new ending point.




The filesystem has been resized. The new partition end location is known. It is now time to take out the scalpel and recarve the harddrive. :)


CAUTION: Make BACKUPS. Partition resizing can potentially erase large parts (or all) of your system. Be careful!
I will walk you through how I ran fdisk on my system.
I start up fdisk with hda (not hda3), like so:# fdisk /dev/hda
(NOTE: You may enter "q" before step 11 to have fdisk forget your changes and not write them to disk.)
1. Press "m" then enter, to see my options.
2. Enter "p" to see my current partitions.
3. Enter "d" to delete a partition.
4. It asks for the partition number. I enter "3".
5. Enter "n" to create a new partition.
6. Enter "p" to create a primary (hda1-hda4) partition.
7. Enter "3" to (re)create the partition I deleted (hda3).
8. It asks me for the first cylinder. I enter "1221". Same as the original partition!
9. It asks me for the last cylinder. I enter "5606". This is the new End calculated earlier.
10. Enter "p" to make sure everything looks correct.
11. Enter "w" to write the modified partition table.

Reboot (or use the program "partprobe") so that the Kernel (Linux) can read your new partitions.


After running partprobe. I ran "fsck.ext3/dev/hda3", just to make sure everything was good. After mounting, I now see a 34Gb partition where a 50Gb partition used to be.
# df -h /dev/hda3
Filesystem Size Used Avail Use% Mounted on
/dev/hda3 34G 34G 0 100% /home/


/me takes a deep sigh of relief, then takes a bow...

[Sepero]

In case anyone was wondering, this is not the first (or probably last) ext3 resize I have ever done. It's just the first time I've ever written about it.

For the sceptics out there: Yes, there was actual data on the partition. Yes, the data did survive.

EDIT:
I'm considering writing a script to automate all or most of this HowTo. If you would like to see that, make a post saying so.

[XiaoKJ]

Yes, I'll like to see that.

However, I thought fdisk is rather dangerous even to the project maintainers? (IIRC, I read this from this very forum.) Have you thought of moving to sfdisk? esp since sfdisk is more for these stuff?

[saikee]

If one does not need to have the content of partition hda3 operational then it is possible to cheat when resizing say hda3 from 50Gb to 10Gb with these steps

(1) Boot up a Live CD
(2) Using cfdisk to create another temporary partition from any disk with size sufficient to hold the data in hda3, say it is sdb9 which could come from an external disk hooked up to a USB port.
(3) Format sdb9 to the same filing system as hda3 and then mount it say on /mnt/sdb9, using commands "md /mnt/sdb9" and then "mount /dev/sdb9 /mnt/sdb9".
(4) Duplicate the content of hda3 into sdb9 with Bash commands
md /mnt/hda3
mount /dev/hda3 /mnt/hda3
cd /mnt/hda3
tar cf - . | (cd /mnt/sdb9; tar xvf -)
ls /mnt/sdb9
The last command is optional just to check if I have duplicated successfully all the files and directories.
(5) The hda3 is then deleted and re-created to the new desired size (of say 10Gb) using say cfdisk program again and then formatted to the same filing system.
(6) May be it isn't technically needed (as no Dos partition is involved) but it is a good practice to reboot the Live CD to ensure the new partition table is working.
(7) The content of sdb7 is then copied back to the new hda3 by similar commands
md /mnt/hda3
mount /dev/hda3 /mnt/hda3
md /mnt/sdb9
mount /dev/sdb9 /mnt/sdb9

cd /mnt/sdb9
tar cf - . | (cd /mnt/hda3; tar xvf -)
ls /mnt/hda3
The above is a lazier method involving less work on determining the size of the smaller partition as the user does not have to bother with the exact partition size. It is the method showed by moderator DMR in Post #23 of this thread. (http://justlinux.com/forum/showthread.php?threadid=96938&perpage=15&highlight=tar&pagenumber=2). I followed his steps and have moved hardreds partitions around without any problem.


I am biased to cfdisk as it is more widely available than sfdisk which is favoured by the Red Hat family. In cfdisk one can see each partition in the partition table as it is created but more importantly it has the following features:-

(1) To automatically stop a user from creating more than 4 primary partitions and shows the explanation.
(2) To show the name of the extended partition in the order according to its creation. Say if a user creates from new a logical partition then the first hda1 will be used up as the extended partition without user intervention and the new logical partition will be assigned hda5. The first primary partition created afterward takes up the position as hda2.
(3) A deletion of a logical partition in the middle will cause the following logical partitions re-number automatically (the latter half shift up by one to maintain the continuous chain relationship).
(4) It is generally possible to see how the partitions were created originally in cfdisk (by the partition names and the addresses in the hard disk), find out why empty spaces become dead (not usable) and the principle how an extended partition works.
(5) In cfdisk a user can specify the partition size to be displayed in different formats ( in sectors or in cylinders) and enable a user to create a partition to match a desired size exactly.
(6) cfdisk is the next most widely available partitioning program after "fdisk".
(7) A user can physically see the limits of an IDE disk can have up to 63 partitions and a Sata 15 partitions, as cfdisk will refuse to accept any more partition afterward when the limits have been reached even there is ample space left in the hard disk.

[Sepero]

However, I thought fdisk is rather dangerous even to the project maintainers? (IIRC, I read this from this very forum.) Have you thought of moving to sfdisk?Where did you read that fdisk is dangerous? It is true that fdisk is not as well maintained as it once was, but that doesn't render it bad. I have used fdisk many, many times before, and Never has it given me problems. I have even used fdisk to successfully create partitions on mutiple SDCard's with my PDA. -Talkk about pushing the limits.

saikee, good info, but you should put a top notice: "A second partition with size equal to your saved data is required".

I would rather have used cfdisk. I didn't really try (I think I tried once before and determined it unsuitable for this type of operation). The default units in cfdisk tend to be too "human", and not easily measurable in actual bytes.

[saikee]

I did state in Point (2) that the new partition needs to be large enough to hold the data. Although the partition is compressed into a tar ball but it is only in transit and expanded immediately in the new partition.

It is true that the unit in cfdisk can be difficult to relate exactly even it is quoted in Mb. I normally use 1000 for 1Gb and 5000 for 5Gb and so on. I believe it could be due to after the booting sector is excluded the final size available for the filing system has to be adjusted. It works for me as I use cfdisk exclusively.

I haven't investigated deep enough but it appears to me each partitioning tool (including non-Linux) has its own way of quoting the partition size and so it pays to stick with only one partitioning program.

[XiaoKJ]

Where did you read that fdisk is dangerous? It is true that fdisk is not as well maintained as it once was, but that doesn't render it bad. I have used fdisk many, many times before, and Never has it given me problems. I have even used fdisk to successfully create partitions on mutiple SDCard's with my PDA. -Talk about pushing the limits.

I would rather have used cfdisk. I didn't really try (I think I tried once before and determined it unsuitable for this type of operation). The default units in cfdisk tend to be too "human", and not easily measurable in actual bytes.

Well, the units in cfdisk can be easily changed. This makes your argument not so strong. However, I know that it is unsuitable as it does not allow resizing --- it would rather totally destory and rebuild the partition, a bit like the windows installer cd's partitioning tool.

Yet again, I shall restate that I don't remember the exact posting for fdisk. But, if you are going to do these kind of in-place resizing, sfdisk should be a better idea because it is designed to do these obscure stuff. Anyway, I'll also need a good guide into sfdisk (never used it reliably).

Thanks

[saikee]

"fdisk" may be regarded as dangerous as it allows a user to change things that could render the disk unreadable in a wrong move, like altering the /cylinder/head/sector. fdisk does declare the commands that need extra attention and in that respect it is not dissimilar to sfdisk.

"fdisk" happens to be the most robust partitioning program I have come across. If a disk become unreadable other programs, including cfdisk, will refuse to have anything to do with it by claiming the partition table is corrupt and no repair is possible or something like that. "fdisk" is the last line of defence as it could still be used to delete the troubled partitions, re-create them in different settings and bring the disk back to a healthy state. When fdisk can't repair a hard drive then it is truly dead to me. It is really a good part of the Bash shell that I can always rely on. I am sure many experienced Linux users can make it sing and dance too.

To me any program dealing with creating partitions in a hard disk is dangerous if the user does not have the basic concept of how the partitioning convention in a PC works even though we are playing only with 16 bytes of data for every partition in the partition table. Once a user knows the 16 bytes can be completely messed up but the data inside the partition is still untouched then it is only a simple matter of rebuilding the partition table again. In that respect it pays to keep a record the partition sizes or keep the partitions in easily remembered sizes.

[retsaw]

However, I know that it is unsuitable as it does not allow resizing --- it would rather totally destory and rebuild the partitionThat doesn't really matter, it can still be used for resizing as long as you make sure when you create the new partition in place of the old one you wanted resized that the start of the new partition is the same as the start of the old one. I always use cfdisk rather than fdisk even when resizing partitions because I prefer the interface. You don't have to worry too much about accidentally making partitions smaller than the filesystem because running fsck on the partition afterward will throw up an error if the partition is smaller than the filesystem (at least it does for ext2/ext3) and you can then make it bigger to fix the problem. When resizing I generally make the filesystem smaller than I want it, resize/recreate the partition to the size I want then resize the filesystem again to fill up the partition, this way I don't have to worry about calculating exact sizes.

[bwkaz]

You don't have to worry too much about accidentally making partitions smaller than the filesystem :eek: :eek: :eek:

Yes, you do! If you make the partition smaller, then running fsck may destroy the data that's past the new end of the partition. If your FS already has errors on it, then fsck will try to fix these errors, but if the end of the device has been moved out from under the FS, fsck will throw up its hands in defeat -- and your data will be either half-recovered, not recovered at all, or overwritten.

Neither ext2 nor ext3 allocate blocks in order on the disk; it's quite possible that you have files in the space at the end of the partition. The resize2fs program already handles this for you (by moving the blocks).

running fsck on the partition afterward will throw up an error if the partition is smaller than the filesystem (at least it does for ext2/ext3) and you can then make it bigger to fix the problem. Why don't you just resize2fs before resizing the partition? You need the FS to be unmounted anyway. resize2fs can handle moving blocks around if needed.

(And actually, I am pretty sure that GNU parted runs resize2fs when it has to resize a partition with an ext2 or ext3 FS on it. It'll run resize2fs, then modify the partition table, then tell the kernel to re-read the partition table.)

[Sepero]

No reason to get wacked out, bwkaz. I think you may have misread what retsaw what saying. (He didn't word it very well.) He does use resize2fs before shrinking the partition. Also, he is right about fsck.ext2 throwing a warning/error when the partition is too small.
(But I would rather not use this method, because if you accidentally put "resize2fs -f", things might go "Real Bad, Real Fast". Plus, cfdisk is way too sloppy for the resize that I did.)

Well, the units in cfdisk can be easily changed. This makes your argument not so strong. However, I know that it is unsuitable as it does not allow resizing --- it would rather totally destory and rebuild the partition...Ok, good point about Units being changed in cfdisk, so I checked it out. Unfortunately, cfdisk will only change it's Units for display, it won't change for actually creating a partition. As I originally thought, it is unsuitable for fine operation.

Second, minor point, I actually did destroy and rebuild(recreate) the partition with fdisk. Partitions technically cannot be resized, only filesystems can be resized.

Deleting/Changing a partition does not affect any data on your disk, it only affects where the system is supposed to find data.

PS.
XiaoKJ, I do not care for sfdisk, but if I create this as a script, I may have to use sfdisk because fdisk may not be script-able. As retsaw said, fdisk is THE STANDARD partitioning tool. I have used fdisk MANY, MANY, MANY times for "regular" partitioning (deleting and creating partitions), and it has always worked perfectly for me.

[crow2icedearth]

usally shrinking your drive is you wont have data lost. the problem lies when you increase the partation . of coarse make sure to make a backup of the partation before you move it.

[Sepero]

Why do you say that crow2icedearth? Given that you actually have the freespace, enlarging the partition and filesystem of Ext2/3 (and most others) is as easy as this:
1. Use cfdisk to delete and recreate the partition bigger.
2. Run the command "resize2fs /dev/hdaX". (It automatically fills the entire partition.)

[XiaoKJ]

XiaoKJ, I do not care for sfdisk, but if I create this as a script, I may have to use sfdisk because fdisk may not be script-able. As retsaw said, fdisk is THE STANDARD partitioning tool. I have used fdisk MANY, MANY, MANY times for "regular" partitioning (deleting and creating partitions), and it has always worked perfectly for me.

I know... and I can read it from the way you write...
Anyway, I'm looking forward to your script.

And crow2icedearth, I've never heard of enlarging partitions and having data lost... I tend to agree with sepero

[bwkaz]

He does use resize2fs before shrinking the partition. Oh. Uh... never mind then. :o

;)