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
  • Ananace@lemmy.ananace.dev
    link
    fedilink
    arrow-up
    39
    arrow-down
    2
    ·
    11 months 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
      14
      arrow-down
      1
      ·
      11 months 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?

      • Ananace@lemmy.ananace.dev
        link
        fedilink
        arrow-up
        13
        ·
        edit-2
        11 months 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.