Questions about fstab options on a fresh btrfs Manjaro installation

Support
,
1

Hi,

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

2

You find good Information about Btrfs in the wiki

https://wiki.manjaro.org/index.php/Btrfs

and

https://btrfs.readthedocs.io/en/latest/

https://btrfs.readthedocs.io/en/latest/Administration.html

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
3

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 ?

4

Yes

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 /

:sunglasses:

5

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] /

6

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
7

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

/run/timeshift/backup/timeshift-btrfs/snapshots/

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.

8

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 btrfs@kernel.org 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
9

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

10

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

11

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

Edit:
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:

12

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