I shrunk my root partition and it seems nice. But I am thinking about overwriting now at least the most important files from the backup copy (external drive, rsync, weekly backup) in order to be sure that none of my files got corrupted during the shrinking. That is probably a waste of time (and perhaps it may result in more fragmentation).

I can check that the files are OK after moving them during the shrinking by means of a CRC comparison with those in the backup (e.g. with md5sum) as one unser kindly says in his answer.

But specifically I would like a short explanation on the algorithm that GNU Parted uses in order to ensure that no data corruption happens while moving information from one sector of the disk to another, prior to the shrinking of the partition. Is there such algorithm, or the program copies bytes blindly? I would like to read a simple explanation.


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 NOTES):

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).

When resizing, (g)parted only moves the END position of partition NUMBER. It does not modify any filesystem present in the partition. Underneath, gparted uses 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 calibrate&fsck steps):

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)
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
              new ones.
       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.
Once 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.

  • Ok, so the question is how does step 2 take place, the copy operation done by resize2fs, if this copy operation is safe, if the information chunks are checked somehow for integrity. – Mephisto Feb 25 '15 at 16:11
  • @don_crisstl So there could be data corruption that goes undetected. That is the point. No error messages, everything apparently OK, but files altered. Right? - That means, either I CRC compare everything in the backup with the shrunken partition (see the other answer) or I directly overwrite with the backup to be on the safe side... – Mephisto Feb 26 '15 at 20:37
  • I've done rm * -rf in the partition, and right now rsync is restoring the files from the backup. After that I will install grub again. Perhaps you'd like to add a few words at the end of your answer with a summary of this discussion, it definitely helps. - Thank you! :) – Mephisto Feb 27 '15 at 7:00
  • There is also the option -c in Rsync, that compares files based on a crc check instead of timestamp, but for a whole hard disk it is horribly time-consuming. – Mephisto Feb 27 '15 at 7:07

There are several utilities that function in a similar way that you can use for this: md5sum, sha1sum ... sha512sum:

On your current partition:

find . -type f -print0 | xargs -0 md5sum > /var/tmp/checksum.lst

and then in the directory of your backup:

< /var/tmp/checksum.lst md5sum -c 

You can replace md5sum with any of the other commands. Although md5sum and sha1sum are no longer secure (e.g. a different file can be forged giving the same hash), the extra computing time for the longer hashes don't give you much more confidence about the files being identical or not.

  • With your edit you have turned my question into a very interesting but different one. I wanted to know if GNU Parted uses some algorithm to check the integrity of the data being moved between different sectors, and have some rudimentary explanation on such mechanism. Quite different from "How can I check that the contents of my hard drive and the external backup are identical?", which is a very interesting and useful thing to know, but not was I was asking for. (Nevertheless I wrote down the syntax you give because it is very useful), +1. – Mephisto Feb 25 '15 at 13:07
  • @Mephisto I am sorry I was understanding that you were talking about an external algorithm to check. AFAIK Gparted just shrinks offsets after the filesystem on it moves blocks (to free up space at the end. And as Gparted has no knowledge about the files on the filesystem, I never considered it as the algorithm owner. – Anthon Feb 25 '15 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.