0

I used Clonezilla to clone a 1TB disk to a larger 2TB one, with the intention of making the 2TB my primary data drive. However, after performing the clone, I found that the cloned file system contains 928GiB of data, compared to just 922GiB in the source drive.

Is this normal, and if so, why? Where is the extra 6GiB coming from, and what could have been the catalyst for it?

Hashim Aziz
  • 11,898
  • 35
  • 98
  • 166
  • So did you **just** clone the drive. Or did you clone the drive and then afterwards expand the partition to fill the extra space? – gilgwath Nov 25 '17 at 07:27
  • Just a guess: You know on a normal file system (such as NTFS) files may become very disorganized in its position on a disk. That's why sometimes when (on Windows) if you see a folder's properties, the "Size on Disk" is much larger than "Size" - this is due to the disorganization. It might be when you cloned the drive you carried over the disorganization (~Size on Disk) which would be way larger than the Actual ~Size. The clone probably kept this extra worthless data between the files, which `paradoxon` calls expansion. – El8dN8 Nov 25 '17 at 07:30
  • If you got a file for the clone your cluster size on the 2TB drive might be bigger. As such the file might be taking up more space. On Windows you usually got a size and size on disk attribute in your file properties. – Seth Nov 25 '17 at 07:37
  • @Seth - What do you mean by a file for the clone? I'm not sure if the cluster size was changed, but it was on the default of 4096KB. I'd have thought as a drive cloning tool Clonezilla would keep the cluster size the same by default. – Hashim Aziz Nov 25 '17 at 16:10
  • @El8tedN8te I don't believe that's what @paradoxon is referring to by "expansion". Also, you seem to be confusing the concept of disk fragmentation with the reason for the difference between `Size` and `Size on Disk`. The actual reason for that difference is because of allocation unit size: https://superuser.com/a/66826/323079. – Hashim Aziz Nov 25 '17 at 16:19
  • @paradoxon I cloned the drive, but used [Clonezilla's `-k1` and `-r` options](http://drbl.sourceforge.net/faq/fine-print.php?path=./2_System/88_mbr_related_options.faq#88_mbr_related_options.faq) to expand the partition proportionally and then expand the filesystem to fit the partition, so I didn't need to do the extra step of expanding the partition manually after the clone. – Hashim Aziz Nov 25 '17 at 16:21
  • As I said, it was a guess. And I didn't realize what paradoxon was saying was likely unrelated to what I was saying until after I made the comment, but I decided not edit to fix my error as it was past 5 minutes. – El8dN8 Nov 25 '17 at 18:19
  • @El8tedN8te Wasn't meant as a dig, I was just clarifying. – Hashim Aziz Nov 25 '17 at 19:52
  • 1
    If you clone the disk this does not affect fragmentation, it is cloned as is. But I think what causes the 6G discrepancy is the expansion of the file system. NTFS uses inode tables spread through out the disk to organise itself. Making the FS bigger, will create more these tables entries. On large disks with small cluster sizes this can amount to some GB. If you format a drive you will notice that it is not completly free even if there is no user data on it. In addition windows reserves percentage per drive for the waste bin feature, this will be marked as used. – gilgwath Nov 26 '17 at 16:58

1 Answers1

0

After running Disk Cleanup on the source drive and using it to delete the listed files, and then clearing non-current restore points and shadow copies, I ran the clone again using the same settings.

This time I got much more reasonable results:

Source drive

enter image description here

Clone of source drive

enter image description here

There is still a ~35MiB discrepancy that is potentially worrying, not least because it has the potential to amount to a lot of important documents, but this could possibly be explained by Paradoxon's point on the space that inode tables take up on the file system when it's expanded. I wasn't aware that it was possible for drives and their file systems to have non-file structures that take up data, so this is news to me and I hope it's the case here.

Nonetheless, it's definitely disappointing that a bit-for-bit clone doesn't actually mean a bit-for-bit clone; for me, it tends to remove a lot of the ease of mind of creating drive clones and images instead of manual backups.

Hashim Aziz
  • 11,898
  • 35
  • 98
  • 166
  • 2
    By resizing the filesystem after cloning it, you did not create a bit-by-bit clone, because you changed the clone afterwards. – Daniel B Nov 26 '17 at 22:55
  • @DanielB Fair point. If I had the time or energy I'd test again without expanding the filesystem. – Hashim Aziz Nov 26 '17 at 22:57
  • 1
    In addition NTFS doesn't use Inodes but instead a MFT (which also takes up space but is a different concept). In addition you changed the parameters afterwards so the bit for bit clone might actually be one, you just modified it. – Seth Nov 29 '17 at 07:09