Why can I rest assured that GNU Parted has not corrupted a single bit
after shrinking my partition?
You can't, in fact,
gparted man page clearly says (under
Editing partitions has the potential to cause LOSS of DATA.
You are advised to BACKUP your DATA before using the gparted application.
Reboot your system after resizing the partition and run
fsck. If it doesn't find any errors then the operation was successful and the data is intact.
There have been issues in the past with
gparted corrupting data when resizing partitions even though it wasn't reporting any error (e.g. see this thread on their forum and the warning linked there).
moves the END position of partition NUMBER. It does not modify any filesystem present in the partition. Underneath,
fs specific tools to grow/shrink the filesystem.
You can get detailed information for each operation, as per the online manual:
To view more information, click Details. The application displays more details about operations.
To view more information about the steps in each operation, click the arrow button beside each step.
Let's see what it actually does when shrinking an
ext4 partition (skipping the
shrink file system 00:00:02 ( SUCCESS )
resize2fs -p /dev/sdd1 409600K
Resizing the filesystem on /dev/sdd1 to 409600 (1k) blocks.
Begin pass 3 (max = 63)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/sdd1 is now 409600 (1k) blocks long.
resize2fs 1.42.12 (29-Aug-2014)
As you can see,
gparted does nothing, it just calls
resize2fs -p with the specified device and new size as arguments.
If you're interested in the algorithm you could look at
resize2fs.c. In short:
Resizing a filesystem consists of the following phases:
1. Adjust superblock and write out new parts of the inode table
2. Determine blocks which need to be relocated, and copy the
contents of blocks from their old locations to the new ones.
3. Scan the inode table, doing the following:
a. If blocks have been moved, update the block
pointers in the inodes and indirect blocks to
point at the new block locations.
b. If parts of the inode table need to be evacuated,
copy inodes from their old locations to their
c. If (b) needs to be done, note which blocks contain
directory information, since we will need to
update the directory information.
4. Update the directory blocks with the new inode locations.
5. Move the inode tables, if necessary.
Filesystem resizing should be a safe operation, as per one of the authors, Ted Tso:
resize2fs is designed not to corrupt data even if someone hits the Big
Red switch while it is operating. That was an explicit design goal.
but like all code, it isn't bug-free.
fs resize is done,
gparted shrinks the partition:
shrink partition from 500.00 MiB to 400.00 MiB 00:00:00 ( SUCCESS )
old start: 2048
old end: 1026047
old size: 1024000 (500.00 MiB)
new start: 2048
new end: 821247
new size: 819200 (400.00 MiB)
Bottom line: always backup your data before altering partitions/filesystems and run
fsck after making the changes.