Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Clonezilla shrinks data on root partition

  1. #1

    Default Clonezilla shrinks data on root partition

    I just got a new SSD drive and used Clonezilla to do a disk to disk transfer to copy my old hard disk to the SSD. Everything seems to have gone fine and the system boots perfectly (and much faster) to the new drive. The only thing that seems odd is that while the separate root partition on the old drive and the new drive are the same size, 150 GB, the used portion on the old drive is 147 GB and on the new drive is 46 GB. The old has 3 GB free, the new 100. Everything seems to work fine and the file system looks the same. For the other partitions the used and free portions are the same on both disks. What could have caused the shrinkage on root?

    I want to use the old drive as extra storage and don't want to delete the old root partition until I know I won't need it. If the shrinkage is normal, I'm good to go.

  2. #2
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    27,667

    Default Re: Clonezilla shrinks data on root partition

    That is a nice story, but nothing to show the information you based the story on.

    Please show things like (with both disks attached and as root):
    Code:
    lsblk -af
    And maybe other things you showed yourself to come to yout conclusions.
    Henk van Velden

  3. #3
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    14,731
    Blog Entries
    3

    Default Re: Clonezilla shrinks data on root partition

    Are you using "btrfs"?

    If so, did the cloning include all subvolumes? Did it include snapshots?

    If you kept the subvolumes but lost the snapshots, that might explain the reduction is size. And that's probably okay (not a problem). But if you missed some of the subvolumes, that could be a problem.
    openSUSE Leap 15.2; KDE Plasma 5.18.5;

  4. #4
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    27,667

    Default Re: Clonezilla shrinks data on root partition

    Quote Originally Posted by nrickert View Post
    Are you using "btrfs"?

    If so, did the cloning include all subvolumes? Did it include snapshots?

    If you kept the subvolumes but lost the snapshots, that might explain the reduction is size. And that's probably okay (not a problem). But if you missed some of the subvolumes, that could be a problem.
    I am not sure because I never used Clonezilla. But when it does what the name implies, it should be a byte for byte copy and thus have everything, file system or not, Btrfs or not, free space or not.
    Henk van Velden

  5. #5
    Join Date
    Jul 2018
    Location
    Loma Linda, Mo
    Posts
    410

    Default Re: Clonezilla shrinks data on root partition

    No - Clonezilla only copies allocated file spaces - not bit by bit.
    If you want bit by bit you need to use dd to copy each file system.
    OpenSUSE 15.2 with VirtualBox VM's (XP, 10, Ubuntu MATE 20.04, OpenSUSE 15.2)
    Pi4 with Ubuntu MATE 20.04
    Unix since 1974 (pdp-11, Interdata, AT&T, Tandy, Convergent, Sun, IBM, NCR, and HP)
    Linux since 1995 (Mandrake, Redhat, Fedora, CentOS, OpenSUSE)

  6. #6
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    27,667

    Default Re: Clonezilla shrinks data on root partition

    Quote Originally Posted by larryr View Post
    No - Clonezilla only copies allocated file spaces - not bit by bit.
    If you want bit by bit you need to use dd to copy each file system.
    Oh, then I completely misinterpreted what Clonezilla does by interpreting the name .

    Personally I only use dd for such things since more then 40 years (not to copy file systems, but to copy files, and that includes partitions and disks).
    Henk van Velden

  7. #7
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,106
    Blog Entries
    2

    Default Re: Clonezilla shrinks data on root partition

    Quote Originally Posted by larryr View Post
    No - Clonezilla only copies allocated file spaces - not bit by bit.
    If you want bit by bit you need to use dd to copy each file system.
    That's an interesting statement I wasn't aware of, so did a little investigation.
    A critical concept is that File Space Allocation is logical assignment of physical blocks instead of physical blocks only. In my mind, when the logical assignment of data is moved, there is a possibility(maybe likelihood?) of defragging files by aggregating partially filled blocks into fewer fully filled physical blocks which would be a great benefit.

    Clonezilla describes what it uses to clone data

    From https://clonezilla.org/

    • Based on Partclone (default), Partimage (optional), ntfsclone (optional), or dd to image or clone a partition. However, Clonezilla, containing some other programs, can save and restore not only partitions, but also a whole disk.


    The technical descriptions of these individual projects say
    Partclone - Unclear whether it supports File Space allocation, description seems to lean towards physical blocks. Since this is the default, it's likely the most important function that needs to be clarified.
    Partimage - Clearly physical blocks
    dd - Physical blocks

    I don't know of any universal defragmentation tool in Linux, only what is available in BTRFS
    https://wiki.archlinux.org/index.php...efragmentation
    The following example defragments the root partition recursively
    Code:
    btrfs filesystem -r /
    Even the above BTRFS command AFAIK doesn't have a "Read but don't do anything" option so it's likely the only way to test whether defragmentation has actually occurred is to read filesystem usage initially followed by defragging the files by either running the above command or performing the time-tested method of moving all the files to a different partition(or disk) and back, then taking another filesystem usage reading. Note that this file moving using filesystem tools is completely different than bit moving by an app like dd.

    Note though that there can be other reasons for different filesystem usage...
    Temporary files may be excluded by an intelligent "clone" that isn't by bit.
    "Trashed" files residing in a Desktop temporary buffer may not be transferred.
    When you delete a file, ordinarily only the File Allocation pointers are removed, and not the data. It shouldn't show up in your filesystem disk usage, but would make a big difference in the time required to clone and would mean that the files could be recovered forensically. This is why a SOP of disk cloning and shrinking virtual disks is to over-write all your free space with a repeatable character so that if compression is utilized, your operation is quick and efficient.
    (To the @OP, this is an easy test if you have enough free space on another disk, just boot to your SSD, mount the old disk, move all the files on that disk to another disk using the cp command or a graphical file manager and back again. You can verify if your disk usage on the disk is similar to your new SSD, and maybe even boot off it)

    So, although File Space Allocation is a possible factor,
    Without more definitive testing or technical descriptions by the projects, this needs some verification(I didn't find any authoritative statement posted).

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  8. #8
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    2,206
    Blog Entries
    1

    Default Re: Clonezilla shrinks data on root partition

    Quote Originally Posted by bearymore View Post
    I just got a new SSD drive and used Clonezilla to do a disk to disk transfer to copy my old hard disk to the SSD. Everything seems to have gone fine and the system boots perfectly (and much faster) to the new drive. The only thing that seems odd is that while the separate root partition on the old drive and the new drive are the same size, 150 GB, the used portion on the old drive is 147 GB and on the new drive is 46 GB. The old has 3 GB free, the new 100. Everything seems to work fine and the file system looks the same. For the other partitions the used and free portions are the same on both disks. What could have caused the shrinkage on root?

    I want to use the old drive as extra storage and don't want to delete the old root partition until I know I won't need it. If the shrinkage is normal, I'm good to go.
    You treat properties of source and target partition as classified information. Thus an answer to your question would be pure guesswork. What are your partitions?

    Code:
    3400G:~ # df -h /home       
    Filesystem      Size  Used Avail Use% Mounted on 
    /dev/sdb3       428G  292G  115G  72% /home 
    3400G:~ # file -s /dev/sdb3 
    /dev/sdb3: Linux rev 1.0 ext4 filesystem data, UUID=18e63751-b483-4422-b10d-6b896681ee64, volume name "Home" (needs journal recovery) (extents) (64bit) (large files) (huge files) 
    3400G:~ # df -h /HDD 
    Filesystem      Size  Used Avail Use% Mounted on 
    /dev/sdc2       1.8T  1.4T  283G  83% /HDD 
    3400G:~ # file -s /dev/sdc2 
    /dev/sdc2: Linux rev 1.0 ext4 filesystem data, UUID=08fb3e4e-133d-4b2d-96a0-0a1e0a3381d8, volume name "Home-HDD" (needs journal recovery) (extents) (large files) (huge files) 
    3400G:~ #
    
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  9. #9
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    290

    Default Re: Clonezilla shrinks data on root partition

    How could CloneZilla possibly know what's free and what's allocated storage?
    Not even the actual btrfs tools (let alone df) seem to be able to give accurate answers due to the complexity of btrfs.

  10. #10
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    27,667

    Default Re: Clonezilla shrinks data on root partition

    Quote Originally Posted by unix111 View Post
    How could CloneZilla possibly know what's free and what's allocated storage?
    Not even the actual btrfs tools (let alone df) seem to be able to give accurate answers due to the complexity of btrfs.
    Triggered by this thread I visited the Clonezilla website https://clonezilla.org/ .
    There they say:
    Many File systems are supported: (1) ext2, ext3, ext4, reiserfs, reiser4, xfs, jfs, btrfs, f2fs and nilfs2 of GNU/Linux, (2) FAT12, FAT16, FAT32, NTFS of MS Windows, (3) HFS+ of Mac OS, (4) UFS of FreeBSD, NetBSD, and OpenBSD, (5) minix of Minix, and (6) VMFS3 and VMFS5 of VMWare ESX. Therefore you can clone GNU/Linux, MS windows, Intel-based Mac OS, FreeBSD, NetBSD, OpenBSD, Minix, VMWare ESX and Chrome OS/Chromium OS, no matter it's 32-bit (x86) or 64-bit (x86-64) OS. For these file systems, only used blocks in partition are saved and restored by Partclone. For unsupported file system, sector-to-sector copy is done by dd in Clonezilla.
    So they claim to have inside knowledge about how those file system types function.

    And I agree with you that I also do not call that "cloning". But hey, what is in a word.
    Henk van Velden

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •