Does parted's resizepart command by default not modify or remove existing files on a partition? Furthermore, does it never modify or remove existing files on a partition (even by some option)?

Similar questions for resize2fs?


1 Answer 1


When shrinking a filesystem, resize2fs first checks if the part of the filesystem that is going to be cut away is free. If not, it can try to move those files out of the area that will be cut away, if there is space to do so. If this cannot be done, it stops and reports an error without shrinking the filesystem.

resizepart does not care about the filesystem at all. It just changes the partition table to specify a new location where the partition now ends. It does not overwrite anything at or near that location. After modifying the partition table, it will signal the kernel that the partition table has been changed. The kernel will read the new table and apply it if possible.

But for the filesystem driver, the end of the partition will be a hard wall. If the filesystem was not shrunk before the partition was, or the partition was accidentally shrunk more than the partition was, a part of the filesystem will now be cut off from the rest.

The filesystem will assume that the cut-off space is still available, until it actually attempts to use it. At that point the part of the kernel that is responsible for mapping any partition-relative block numbers to actual whole-disk block numbers will return an error to the filesystem driver, as the filesystem is trying to access beyond the end of its partition. The filesystem driver will usually drop to read-only mode as such an error tends to indicate that the filesystem may be corrupted. At that point, the system administrator usually gets involved.

At this point, if the sysadmin realizes that the partition resize operation has cut off part of the filesystem, and undoes the partition resize operation, the filesystem can be fully accessed through the partition device again, and everything may still be just fine: the filesystem may need a fsck to clear the error flag, but the files will still be there. After mounting the filesystem again, the files that were bisected by the partition resize operation will be fully accessible again.

But if the sysadmin simply runs a filesystem check on the partition in its shrunken state, the filesystem checker will see that there are files that appear to continue beyond the end of the partition, and say to itself: "Let's amputate". Since it takes the partition size as a solid fact, it has no choice but to truncate or delete the files that seem to go beyond the end of the partition. This is where the actual damage is done. The filesystem metadata will also need some adjustment to remove the space that is beyond the end of the partition from the "books".

After the filesystem checker is done, the cut-off parts of the files are still there on the physical disk, beyond the new end of the partition, unchanged... but the parts of the files still inside the filesystem are now truncated into stumps.

  • 1
    If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether. Feb 19, 2019 at 9:03
  • 1
    Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
    – telcoM
    Feb 19, 2019 at 9:11
  • Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data. Feb 19, 2019 at 9:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .