Questions about fstab options on a fresh btrfs Manjaro installation


I recently installed Manjaro 21.2.3 on a workstation. I had a look on the default options in /etc/fstab right after the installation.
My root partition is BTRFS, so i have the following :

UUID=xxxxxxx / btrfs subvol=/@,defaults,discard=async 0 0

Could you please tell me if there is any reason why there is no :

  • Compression (as zstd)
  • Autodefrag
  • SSD (in my opinion it should be added if a SSD is detected)
  • space_cache
  • The last column is 0, so no verification at all. Isn’t it better to set it at 1 ?

For a workstation with a ssd, what would be the recommended options ?

Thanks for your help

You find good Information about Btrfs in the wiki


This said, this is your system, and it is up to you to tweak it to your needs. There is no “one fits all”.

  • Compression is good when the disk is slow, and the CPU is fast. But some people complain when compression is on :wink: see: New install with btrfs, is my filesystem compressed? If yes, how turn it off?
  • Autodefrag is good for some cases, but bad for others. So it is off by default
  • SSD this option is outdated. Btrfs will autodetect your ssd.
  • space_cache is best handled automatically by btrfs
  • The last column is 0 – This is the correct way to do it with btrfs, because btrfs itself does check the filesystem every time before mounting it. To set this to 1 will do nothing :wink:

my line looks like:

PARTUUID=...	/         	btrfs     	rw,noatime,compress=zstd:9,commit=300,subvol=@	0 0
1 Like

Thanks for you answer

  • noatime appears to be a good option to activate too according to what i read, as you did, effectively.
  • commit=300 although the default is 30. Is it for performance purpose you set it to 300 ?

Do you know the consequences if i had zstd compression now ? Only newly created files would be compressed no ?


But it is possible to recompress. I did this today to an bootable usb-stick that got to full.

If you have already snapshots

  • you need your filesystem to be at least 55% free !!!
  • or you need to remove all snapshots before you apply the following commands !!!

1. Change fstab with new compression (in my case =zstd:15)

2. Reboot

3. Run in an extra terminal

watch -d -n10 btrfs filesystem usage /

4. Run in an extra terminal

watch -d -n10 df / /boot

5. If there is enough unallocated space:

btrfs filesystem defragment -r -c [-v] /usr /var /etc /home /root /opt /srv

But be careful. This may take some time because every bit of data needs to be read->compressed->written.

5. If there is not enough space, or you are the careful type (like me), you can do this in smaller steps like:

btrfs filesystem defragment -r -c [-v] /bin

6. Optional: balance your btrfs

btrfs balance start -dusage=49 /
btrfs balance start -dusage=65 /
btrfs balance start -dusage=90 /
btrfs balance start -musage=90 /


If i understand well, what you mean is if i want to do btrfs filesystem defragment -r -c ...., i have to pay attention to the free space but why concretely ?
In theory, it will require less space

What could happen if i do only:

btrfs filesystem defragment -r -c [-v] /

Recompressing everything will break all reflinks to existing snapshots.

So while the actual subvolume @ will shrink, it will have nothing in common with the snapshots you made.
You may need double space until the snapshots are deleted.

And please do not try to compress /run /proc /sys ...
(This may be ignored, or lead to an error, or segfault :wink: )

1 Like

Oh oh, that’s a good point.
Currently, i have 3 snapshots of @/, they are located in


Do you mean i MUST NOT defragment/compress them ?

That’s also a good point because in the Wiki link to gave me above, what i read is the following :

Subvolume @snapshots, @home.snapshots

It is wise to “store” snapshots NOT inside the subvolume they where taken from. So this may be the right place to store your snapshots of @ or @home.

→ This is fine, but on my installation (a default btrfs installation), there is no subvolume for snapshots, so they are stored in the @/ subvolume. So, i do not get why there was no @snaphot subvolume created during installation. My installation is recent, i made it last week though.

The suggested layout may vary over time :wink:

The layout from the wiki is especially easy if you manually work with btrfs.

Timeline, snapper and other programs do differ in subvolume-layout at the time being. Even on they say different layouts are possible, and they do not prefer one over the other.

No, You should not compress /run

This sentence speaks about the layout inside the btrfs-volume. You do not see this unless you mount the volume-root of btrfs (which is not mounted in production)

1 Like

Thanks for all your answer, i feel a little bit better now :slight_smile:

By the way, do you think you could have a look on another question i asked this afternoon ? Thanks

I do not use Timeshift, but use snapper :man_shrugging:

Is it slow without two options async and auto?
Both options are included in defaults.

I found the default options in btrfs-man5(5) — BTRFS documentation
There are the certain options for defaults:

  • acl
  • barrier
  • commit=30
  • datacow
  • datasum
  • max_inline=2048
  • metadata_ratio=0
  • space_cache=v1
  • thread_pool=(default: min(NRCPUS + 2, 8))
  • treelog

If you removed defaults, that means datacow and datasum would be disabled? :thinking:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.