Disclaimer

Flatpak uses OSTree, like Fedora Atomic Desktops (Silverblue, Kinoite etc) and similar to BTRFS snapshots.

So many files are deduplicated and linked, not actually there

https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker

50GB without
31GB with deduplication
21,4GB with BTRFS compression
  • AnanaceA
    link
    fedilink
    arrow-up
    45
    arrow-down
    2
    ·
    1 year ago

    A lot of that data doesn’t actually exist, ostree hardlinks data blobs internally, so the actual size on disk is much smaller than most disk usage tools will show.

    • Pantherina@feddit.deOP
      link
      fedilink
      arrow-up
      15
      arrow-down
      1
      ·
      1 year ago

      Thanks! The same goes for ostree system versions and BTRFS snapshots probably.

      I have a similar problem with virt-manager and I think that doesnt create dynamically allocated qcow2 containers?

      • AnanaceA
        link
        fedilink
        arrow-up
        17
        ·
        edit-2
        1 year ago

        Flatpak uses OSTree - a git-like system for storing and transferring binary data (commonly referred to as ‘blobs’), and that system works by addressing such blobs by hashes of their content, using Linux hardlinks (multiple inodes all referring to the same disk blocks) to refer to the same data everywhere it’s used.

        So basically, whenever Flatpak tells OSTree to download something, it will only ever store only copy of that same object (.so-file, binary, font, etc), regardless of how many times it’s used by applications across the install.
        Note that this only happens internally in the OSTree repo - i.e. /var/lib/flatpak or ~/.local/share/flatpak, so if you have multiple separate Flatpak installations on your system then they can’t automagically de-duplicate data between each other.