Considering some btrfs optimizations

My installation is a few months old, maybe 4 months.
Decided to run the first defrag yesterday, but before I checked the disk usage, it was about 21GB.
After the defrag, noticed that the space used increased to 26GB.

Since the info above is specifically saying about “break” links, I decided to test my system and everything was working perfectly.

In my opinion, which could be premature and with little knowledge about the technical stuff, is that these links that “break” are only for the snapshots, but they still work, they just consume more space after the defrag.

Decided then to erase my snapshots and my system is now using 16GB of space…

1 Like

Thanks for sharing! It confirms then:

indeed, that is exactly what appears to me that happened

1 Like

Just speculating: I wonder if there might be possible to exclude some volumes from defraging to workaround this increase of space usage :thinking:

edit- I don’t think so. I am out of my depth of course :sweat_smile:

Isn’t it better to defragment only the really fragmented data?

1 Like

You can, but I don’t think its going to help.

btrfs-assistant (dalto’s app)

See, I’m taking snapshots from /, which allows me to recover my system, to boot into snapshots and etc.

So, assuming that every user also takes snapshots from / so they can be able to perform the tasks above, and the fragmented data is located in / which contains the system, how not to defrag / ?

1 Like

Not sure:

btrfs filesystem defragment [options] <file>|<dir> [<file>|<dir>...]

Could it be possible to specify explicitly the directories to be defraggede and leave out some?

This certainly makes sense. Just don’t know how to go about in practice to do so.

1 Like

I have managed with the autodefrag mount setting and the instructions on this page:

I have found that I don’t need to use the defrag command.


Sounds great!
Thanks for the link! I’ll look int it.

The autodefrag was the default in the previous EnOS installation (calamares)
However there was a regression with that option in kernel as per image below.

Since then I decided not to use it anymore…
Also, keep in mind that if you monitor the disk usage by typing: iotop -a, you will see that btrfs is writing to the disk more often with the autodefrag option.


Yes. I know the topic. As far as I know it has been fixed long ago.

I haven’t noticed a noticeable difference on my machine when I’ve looked into it with iotop.
I don’t run torrents on btrfs file system, it may be one reason why usage is not rising.

But I noticed several gigabytes of writing with the iostat program (before and after) the defrag command.

Choices, choices.


Yes, it is fixed…
But still, it writes constantly to the disk, same happens with the discard async option, thus I prefer to run both once in a while…

Exactly :slight_smile:


A bit off-topic but related to btrfs and mounting.

I use to mount the root of a btrfs partition into a directory in order to being able to browse all the contained subvolumes like you would with “regular” directories. I use the following line:

sudo mount -t btrfs /dev/nvme0n1p2 /btrfs

I wonder if (some of) the mount options for mounting subvolumes should be applied here as well. Or any others?

I look forward your suggestions.

If you use the same options on all your subvolumes, you should use those options there as well. It may or may not make much difference depending on how you use that mountpoint.

Many of the btrfs options actually apply to all subvolumes of the same filesystem. For example, if you look at findmnt /btrfs you will probably see that compression and some other options are being applied to it even though you didn’t specify them explicitly.

If you want to explicitly mount the root you should probably use subvolid=5. What you are currently doing is mounting the default subvolume which is currently set to /. If you ever changed the default subvolume, what you have mounted there would change too.

1 Like

Thank you @dalto for the reply!

Here is findmnt /btrfs from how I usually mount the partition as mentioned above:

/btrfs /dev/nvme0n1p2 btrfs  rw,relatime,compress=lzo,ssd,space_cache,subvolid=5,subvol=/

Mounting it with subvolid=5:

mount -o subvolid=5 /dev/nvme0n1p2 /btrfs

gives the exact same output for findmt /btrfs as above.

For comparison:

findmnt /
TARGET SOURCE                            FSTYPE OPTIONS
/      /dev/nvme0n1p2[/@arch-gnome-root] btrfs  rw,noatime,compress=lzo,ssd,space_cache,subvolid=256,subvol=/

The only difference, as far as I can see, is between relatime and noatime (which I have in fstab).

I just use /btrfs occasionally to copy some file or folder into the running system.

/dev/nvme0n1p2 contains some subvolumes for other Arch systems with different DEs (Plasma and Cinnamon) and one with WM (i3).

Should I be specifying noatime in the mount command for it to match the mount options for the subvolumes in /etc/fstab?

Yes. That just guarantees it won’t change later if the default subvol changes.

I would match them.

1 Like

Great! I’ll do so!
Thanks for the support! I appreciate it.

1 Like