On aurora, I noticed that /usr/lib/locale/locale-archive is extremely fragmented (1700+ extents in my case). Since this file is accessed by many applications, this seems like a performance issue — but because it’s part of the OSTree-managed, read-only /usr, there’s no way to defragment it.
I understand that immutability is a core part of the design, but I’d like to ask:
How can this be fixed or improved?
Could image builds defragment certain files ahead of time?
Is it possible to request OSTree to optimize key files for read performance?
Are there safe ways to override it with a defragmented local copy?
I’m open-minded about solutions — I just want to understand if this is on anyone’s radar and whether there’s a path forward.
In short, an extent is a contiguous area of storage. For performance reasons, ideally you’d want a file to all be in one contiguous area of storage, aka 1 extent. By having more extents, the file is more spread out across the disk, making access slower.
@inffy — By “fragmented” I’m referring to the number of extents (non-contiguous storage blocks) used to store the file. In this case, /usr/lib/locale/locale-archive is stored in over 1700 extents, meaning the file is split across many locations on disk, which can negatively impact performance during reads.
@evanmohr — Yep, exactly. More extents = more scattered reads, which especially matters for frequently accessed files like this one.
How I measured it:
/var/home/gebruiker
❯ filefrag -v /usr/lib/locale/locale-archive
Filesystem type is: 794c7630
File size of /usr/lib/locale/locale-archive is 233242544 (56944 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
…
/usr/lib/locale/locale-archive: 1779 extents found
This isn’t about micro-optimizing random binaries, it’s about a central, frequently accessed file that appears to be persistently fragmented in the immutable image, with no way to fix it locally due to OSTree.
So I’m curious whether:
The build process for Aurora/ublue images could include a btrfs filesystem defragment pass on key files like this
Or if there’s another technical path forward (e.g., temporary bind mounts, overrides, or upstream defrag-aware packaging)
Appreciate the insight from maintainers and happy to test if there’s something I can try locally.
locale-archive is a memory mapped file, so the sections needed are loaded on demand by the kernel, and are kept in the page cache, so fragmentation isn’t something to worry about.
You’re right that locale-archive is memory mapped and cached, so fragmentation isn’t a big issue after the pages are loaded.
But the problem is broader, many large, read-heavy files (locale-archive, libicudata.so, Qt libraries, input method data) are heavily fragmented at build time, and on immutable systems like Aurora/ublue, we have no way to fix that.
So while it’s not catastrophic, it’s still baked-in I/O inefficiency that affects cold boots, first launches, and low memory setups, and most likely it could be avoided entirely with a defrag pass during image build.
I have experienced poor performance with Aurora for a while now, and have been entertaining the idea of posting a question about it. I have found that it can take several minutes to boot to the login screen, then another long wait until the system comes up after entering the password. Also applications take an abnormally long time to start. Vivaldi can take well over a minute, and ditto Thunderbird. Mint, on the other hand, boots in maybe ten seconds tops, and Vivaldi and Thunderbird both start almost before I’ve taken my finger off the mouse button. Ditto CachyOS and Nixos. (Yes, I have them all installed…) Could this problem be related to the multiple extent problem?
But, most of all: is defragmentation a serious issue in modern SSDs? Can it cause any real performance issue? I doubt it to be honest, but I’ll leave this question to more expert people.
@shishimaru You’re probably right but I don’t have Aurora on an ssd. In fact it’s on a 3Tb USB drive, so probably lots of latency. But then, CachyOS is on the same drive. No problems there.
Aurora/Kinoite’s immutability means you can’t defrag /usr in place, but you can still prove whether fragmentation on your USB HDD is the real slowdown: boot the live ISO, mount your installed root read-write just once, run btrfs filesystem defrag -t64M on only the big hot files (locale-archive, libicudata.so*, libQt6*.so*), then reboot normally. If boot/login times collapse to Mint-like speeds, fragmentation is the culprit; if they don’t, we need to look elsewhere (USB UAS quirks, services, entropy). One quick test tells us whether to push for a compose-time defrag fix or dig into other bottlenecks.
On SSDs, fragmentation is mostly a metadata blip. On rotational media each extra extent is another ~5 ms seek, so it can matter there. That’s why the issue shows up for @mogplus8 but not for most NVMe users.