Item — HN Reader

I recently looked into disk usage of journald and was also shocked. My next step towards peace of mind is https://www.devuan.org/os/init-freedom

Will try it out as next distro for my Debian system, longtime experience with Void Linux (runit) on another box is great.

4 comments

Many applications hammer the disk even if the developers don't believe this is an issue, not only journald, unfortunately.

It's my third attempt to make my regular Linux desktop less disk-chatty. This is a huge issue for btrfs and for COW FS in general, because they have massive write amplification for small and frequent writes (38,7 TB written to my idle desktop SSD in 2 years).

If you're interested, here are my findings this time so far:

    - workrave: 60 second stat sync https://github.com/rcaelers/workrave/pull/717
    - kde klipper: saves to disk on every copy, even if permanent storage is disabled https://bugs.kde.org/show_bug.cgi?id=501030
    - kde plasmashell: saves qt shader cache each time notification popup disappears https://bugs.kde.org/show_bug.cgi?id=523805
    - bitwarden firefox extension: tries to connect to desktop application every 10 seconds, writes about every failure to browser's WebStorage 14+ KB https://github.com/bitwarden/clients/issues/22192
    - firefox datareporting/glean: very chatty .mozilla/firefox/xxx/datareporting/glean/db/data.safe
    - ipfs: writes every received DHT announce to disk, 20 GB in 3 hours https://discuss.ipfs.tech/t/constant-writes-to-datastore-log/20316
    - mailcow: redis saves data every 5 minutes https://github.com/mailcow/mailcow-dockerized/pull/7405

I noticed plasmashell is write heavy and logs to journald a lot so I have just switched to XFCE partly for that reason.

The two I most often see in Ubuntu's dmesg are:

audit - appears to be some sort of AppArmor logging?

br[] - bridge interface docker uses consistently rebuilds itself? May be related to docker compose networking.

Yeah docker does a ton of network stuff when you start/stop containers, depending on your configuration. It's extra fun because it can drop existing connections when that happens.

Had a process quietly in a crash loop for a solid month on my workstation until I figured out what was causing my random network outages.

> This is a huge issue for btrfs and for COW FS in general, because they have massive write amplification for small and frequent writes

Have you considered using a different fstype like XFS for this? btrfs is good for homedirs, but I wouldn't necessarily use it for other filesystems (/usr, /var, etc.)

I don't have experience with xfs or zfs, and I don't have a free stand for experiments right now unfortunately.

You lose rollbacks, superior syncing, redundancy and data integrity assurance and add complexity for what deceased ssd wear which is hardly an actual problem.

Unfortunately it's not always easy to move away from systemd. I still run void on one of my machines, but aur make things so much easier.

systemd-journald has one of the most deranged log file formats I have ever dealt with, and one of the worse user interfaces, too.

I am not again binary logs, or logs in a database. It's just yet another time I deal with good ideas implemented horribly, horribly badly when it comes to systemd.

I wish Qubes Domain-0 was a customized Gentoo with OpenRC. Fedora with systemd was a poor choice to base off. Nobody should have let Poettering have the influence he was given over userland, systemd is an almost irrevocable mistake.

I’ve been using devuan more or less since day one. I highly recommend it.

FreeBSD isn’t too shabby these days either.