3

From this FAQ:

Why Clonezilla can NOT restore an image which is saved from a large drive to a smaller drive? Any workaround?

It's not easy to implement such a feature, since Clonezilla now is a partition "imaging" tool, by "imaging", it means clonezilla actually does not know the files themselves, clonezilla just knows where the used blocks are. Because of this reason, the target partition size must be equal or larger than the original one so that clonezilla can restore the used blocks on that partition. If the target partition size is smaller, then it will go wrong. Unless Clonezilla has file-based function in the future. Maybe...

From what I know, a file is a list of pointers which point to one or many continuous blocks (or clusters). How can a software know which blocks are in used without understanding the filesystem?

1 Answer 1

2

Simple answer: No.

The same is true for any data structure. If you don't understand the data structure you can't find anything in it.


For data recovery purposes there are tools which will scan data (a drive) and search for signatures it understands (eg the start of a jpeg file). One example tool is photorec

This technique lets the software find some files without understanding the file system. But it's messy and unreliable. This technique can't handle fragmentation well and only works for some file types. It can often result in corrupted files.


There are cloning tools which are file system specific. For example if you know the partition type is ext2/3/4 you can use a tool like e2image to copy files across without using the Kernel's file system driver.

You could also resize the file system before cloning with clonezilla. Eg: use resize2fs to shrink the file system first.

Beyond that, your only real option is to mount the file system and copy the files across with cp, tar or rsync.


Regarding CloneZilla's decision not to implement resizing: Filesystems are generally very complex. There are some simpler ones but ext2/3/4, reiserfs, etc. are't the simple ones.

It can be simple to parse enough information from a file system to determine which blocks it's using. Some file systems even have a nice neat table just marking which bocks are used / not used. Parsing this would not require knowledge of files at all.

As an example, ext3 by default uses blocks of 4096 bytes and block groups of 32,768 blocks. Each 128MiB block group contains a "Data Block Bitmap" showing which blocks in the group are in-use (see reference). So without knowing anything about the files themselves, a program can parse just which blocks are in-use.

However resizing a file system requires a much more robust knowledge. Without knowing specifics of ext2 etc, possible snags include

  • failing to update cross reference pointers or pointers to / from meta data
  • failing to update checksums
  • failing to update block usage bitmaps correctly

It would be very easy for a naive developer to implement a resize in a way that corrupts the file system or destroys meta data.

2
  • Looks like CloneZilla does understand the file system: If file system is supported (ext2, ext3, reiserfs, xfs, jfs, fat, ntfs), only used blocks in harddisk are saved and restored. This increase the clone efficiency. For unsupported file system, sector-to-sector copy is done by dd in Clonezilla. I am now wondering why it does not perform a file-based clone. Maybe it wants to retain all kinds of fragmentation on the destination partition as they were on the original one?
    – Livy
    Aug 5, 2020 at 9:22
  • @Livy edited to clarify. It's one thing to parse some small information out of a file system, it's quite another to know enough to edit it safely without destroying data. I doubt retaining fragmentation would be desirable. The issue is more likely about the developers ability and the cost-benefit of implementing this feature. It's too easy to get wrong, and a lot of reading and understanding required to get right. Aug 5, 2020 at 10:04

You must log in to answer this question.

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