Btrfs for daily driving

2026-10-23T00:00:00+00:00

Initially I wanted to name this post "btrfs for desktop use" to create contrast with server scenarios, but I realized it may be confusing because the term "desktop" is sometimes also used in contrast to "laptop", but in this case I actually mean both desktops and laptops and probably some other personal devices. "Daily driving" might sound a bit "too memey", but it feels like a better choice here.

I first encountered btrfs when I used Bazzite - gaming-oriented atomic immutable distro - a heavily customized Fedora Atomic. I didn't think much of it and the only thing I noticed is that this filesystem was used by default on such a "set it and forget it" distro for gamers. Never had any major issues during my year of using that distro other than being annoyed by needing to use things like distrobox and rpm-ostree to get anything that's not covered by just flatpaks and brew.

Later, when I moved to Gentoo I also picked btrfs for my system volume because it was one of recommended and well-supported options and I already had an impression of it being a good modern general-purpose filesystem after seeing it used in Bazzite. At that point I wasn't really aware of properties of btrfs on deeper level, so it wasn't super deliberate. However, I started discovering them very soon.

Because of Gentoo not being atomic itself, it means things like kernel and driver updates, or just global software updates in general, are more risky: if something goes wrong during update process, there is a possibility of system ending up in broken inconsistent state. Different ways to make it safer exist, the one I decided to try is to use snapshots which btrfs supports natively. Because this filesystem uses copy-on-write (COW), it naturally makes snapshots zero-cost: they don't copy anything until you change any of the files at which point new modified copy of the file will be created while the old one will stay in place, still referenced by snapshot. Many tools exist to automate creating snapshots, however I decided to stick to native btrfs cli, because it turned out very easy to use - I simply have to invoke a single command before doing system updates or anything risky:

btrfs subvolume snapshot / /snapshots/2026_10_16

And that's basically it: zero-cost = no copying anything without need = no disk space wasted (and no LLMs, even though I written "no" quite a few times). What's the catch though, why wouldn't anyone just use filesystems like btrfs universally? That's where I started researching more and got surprised by how unstable and experimental it was considered in its early days according to decade old posts and discussions. Most of those early issues, however, were addressed and fixed long time ago and nowadays the most problematic aspect turns out to be fragmentation which only happens during very specific circumstances. This issue is rather fundamental and stems mostly from COW itself and from other similarly fundamental filesystem design choices. So what are those conditions and how to deal with them?

1. Big files that are modified often and in random order (DB & VM volumes)

This is the edge case that is well known on the internet, and is one of the first things to find when looking for problematic btrfs scenarios. The root of the problem is that due to COW, btrfs can't perform random writes in place: each write will allocate new data and old block becomes dead space. Over time this leads to massive fragmentation: the file's physical content gets scattered across the disk as many small extents.

I personally stumbled upon this one in my bitmagnet setup: turns out it uses postgres database for bookkeeping and even though I only kept it spinning for a week or two, when checking fragmentation these postgres files were at multiple dozen thousands extents.

Fortunately, there is a solution to this problem: disable COW! Yep, turns out btrfs supports disabling COW for individual files and folders, and in the later case, all new files and folders created within such a folder, will also have COW automatically disabled.

# disable COW
chattr +C ~/bitmagnet/data
# check flags (big letter 'C' means COW is disabled)
lsattr ~/bitmagnet/data

2. Big files that are initialized in small chunks in random order (torrented media)

This one is more tricky, initially I expected +C to solve all problems with COW-related fragmentation, but this is not the case unfortunately: when checking my media drive for files with heavy fragmentation, to my surprise the worst cases were all torrented videos. The problem with those is that in many cases torrent clients by default work with sparse files, and when new data arrives in random order those arrivals are not overwrites to existing data, instead it's new allocations which create fragmented extents. In some torrent clients it's possible to configure them to preallocate the whole file beforehands, which will fix the problem when combined with +C. Otherwise, the solution would be to defragment torrented files manually as a periodic maintenance.

# defragment file
btrfs filesystem defrag -v -t 32M file
# check file fragmentation
filefrag file

Snapshots and +C

Another important concern is that in case of snapshots, copy-on-write will still happen on the first write to files that are referenced by snapshots even if they have +C flag. So if your DB or VM files live on btrfs volume that you are snapshotting, you might lose quite some disk space after every new snapshot (on the next write to corresponding DB or VM files). The best solution to this I am aware of is to create separate subvolumes for those DB/VM files, because when snapshotting a volume, btrfs will simply ignore any subvolumes and not include them into snapshots. It's not as annoying as it sounds because btrfs makes it easy to create arbitrary subvolumes at arbitrary paths - so that you can have for example ~/bitmagnet/data as a separate subvolume, while / is the main volume that you take snapshots of.

btrfs subvolume create ~/bitmagnet/data
chattr +C ~/bitmagnet/data

SSD vs HDD

I use btrfs both for my system SSD and external HDD, and there are some important differences. Because SSDs are very fast, they are more forgiving to fragmentation, but because they also wear off, they benefit from minimizing writes by using compression. This is why I ignore some mild cases of fragmentation on SSD - those where files are not frequently written - and use it with zstd compression:

UUID=...   /   btrfs   rw,relatime,ssd,compress=zstd:3,space_cache=v2,subvol=/ 0 0

On my external HDD there is a lot of space and it's significantly slower than SSD. Btrfs compression also leads to some additional fragmentation in certain scenarios, so using compression would be a bad choice for HDD:

UUID=...  /mnt/expansion  btrfs  defaults,noatime  0  0

noatime flag prevents rewriting metadata on file access which improves performance in some cases and it might be useful on HDDs. On my main system SSD I decided to leave the default relatime in place because some sources say certain system software may need proper access times.

Impressions so far

It really does feel great to be able to instantly create snapshots that take zero extra disk space (until later). But it's definitely not without a price, and in this case the price is maintenance. I don't see btrfs as a filesystem you can just use and never think about it, in my opinion you need to pay attention: at the very least check fragmentation periodically, move specific types of files into subvolumes and set certain flags when needed. But when used properly, it does have many nice properties, and snapshotting is only one of them.

Useful scripts

# print fragmentation for all files in folder (recursively)
find /mnt/expansion/videos -type f -exec filefrag {} +

# find files larger than 10M that have >= 1000 fragmentation extents
sudo find / -xdev -type f -size +10M -exec filefrag {} + |
	sed -nE 's/(.+): ([0-9]+).*/\2 \1/p' |
	awk '$1 >= 1000' |
	sort -nr

Why I moved from Trilium Notes to Obsidian

2026-08-23T00:00:00+00:00

I've been using Trilium for a while and I really enjoyed it:

Hierarchic notes
Rich text formatting
Embedded media formats support
Templates
Properties
Scripting and customization

However, after some time, some weak points also showed up:

Database-backed, which means you won't see your note hierarchy as normal folders and files in filesystem, which has its pros and cons, but for me cons are overwhelming because it means I can't use regular tools, for example grep, or opening notes in other editors easily, or symlinking a folder from elsewhere as child items of the note
No plugin infrastucture: even though Trilium is open-source, there's no built-in plugin support and rich plugin ecosystem like in Obsidian
Even though rich text formatting is cool, it isn't great for compatibility, because it isn't always possible to convert this formatting to pure text formats: lossless export requires xml/html in general
Theming isn't great, weak support to popular themes like Rose Pine, compared to Obsidian

Obsidian solves all those pain points for me. It also comes with its own set of issues though, and I'd like to address them:

Built-in features are very lacking compared to Trilium: for example, folders by default can't be notes themselves, there's also no gallery view for folders of images, no custom sorting for notes, etc - all those issues are solvable with plugins thanks to the powerful plugin ecosystem, however it takes some time to set them up correctly
Proprietary codebase: even though plugins are opensource, the Obsidian core app is proprietary, which is very unfortunate, but it is somewhat balanced out by its simple and open-ended architecture - the fact that everything in the vault is just regular folders and files makes it easy to create alternative frontends for the same vault format which don't even need to be associted to Obsidian itself in any way, and there are already examples of such projects: basalt (tui) and obsidian.nvim

Special mention needs to be made regarding embeds and backups:

In Trilium I had to back up the whole vault, including any embedded images, atomically, as a single archive, my single backup size lately was exceeding 1GB, which is crazy for something that is supposed to be mostly about text, it happened because of images and media embeds ofc, but those in my case don't really belong to notes themselves and would benefit to be references to separate places in filesystem
Because in Obsidian vault is just normal files, it becomes possible to bring images in by symlinking picture folders elsewhere in my filesystem, backup strategy also becomes more open-ended and even allows using VCS, and there are already plugins for git and such

Notable plugin mentions:

Folder notes by Lost Paul - allows folders being notes themselves (actually there will be md file with the same name as folder either inside or outside of the corresponding folder depending on selected options, but Obsidian will show them as a single item in a smart way thanks to this plugin)
Custom File Explorer sorting by SebastianMC - allows custom sorting of items in folders in multiple different ways, I use sortspec based approach which is very flexible and allows things like combining adhoc order for few items and then sorting the rest by metadata such as specified date property field in notes
Gallery View by mkshp - allows using ```obs-gallery ...``` blocks in notes to render image galleries, I use it with image folders elsewhere in my filesystem symlinked into vault/Symlinks/..., I then use path: "Symlinks/some_folder" and it just works
Iconize by Florian Woelki - allows adding icons to folders and notes
Minimal Theme Settings by @kepano and Style Settings by mgmeyers - for nice and easy theme customizations

ivxvm.github.io