Enable Btrfs Transparent compression on Fedora 33

Discussions in English on using Fedora
,
#1

I am trying to enable transparent compression
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#How_to_test

  1. I opened the fstab and added compress=zstd:1 to both / and /home as thats how its done in Fedora 34.

  2. Updated fstab and also rebooted the machine to ensure that daemons reload.

Everything is working nicely until now but now to convert existing things into btrfs compression, How to test tells us to btrfs filesystem defrag -czstd -r

so do I have to sudo btrfs filesystem defrag -czstd -r / and also sudo btrfs filesystem defrag -czstd -r /home

1 Like
#2

I (conveniently) just figured this our for myself: Mention btrfs transparent zstd compression in 34 release announcement - #2 by nickavem - Magazine - Fedora Discussion

3 Likes
#3

Ya I figures this our too but just had some doubts, thanks ! I got into a small issue, my system is showing 0 in available space, all tho total and used is great and I can install everything so its just a cosmetic issue but still any idea ? @nickavem

#4

Apparently same for me, solved with df -H or duf. But this “100% used” has not been indicated with the compression but with a Fed34 install in Gnome-Boxes (Machines). I suppose it is a bug in gnome-monitor. Ouups sorry, correct, but I have performed the step compress/decompress as indicated and it is ok now.

#5

@jatin1812 @jcvminou

du, df, and other utilities can be somewhat funky with the compression. The best utility to use is compsize which I mentioned at the end of the other post.

#6

Ya, gnome-system-monitor may have a bug, df -H is fine and also compsize(more accurate)… also @jcvminou how did you solve this in system monitor ?

Also disk usage analyzer is fine ! not as accurate as compsize tho. Its just a system monitor bug.

#7

It sounds like this bug?

Maybe it’s transient.

1 Like
#8

Its a libgtop issue rather than gnome system monitor issue, i opened this and it was moved to libgtop for that reason :slight_smile:

1 Like
#9

Hello Jatin (and Chris), yes it is ok now. I thought gnome-system-monitor had a bug, as it indicated 100 % used. But after application of the other Jatin’s post (sudo btrfs filesystem defrag -czstd -rv / /home/jcvminou), same results as df -H are now indicated. Thank you.

#10

xref: Mention btrfs transparent zstd compression in 34 release announcement - #8 by boricua - Magazine - Fedora Discussion @boricua

Is your backup drive BTRFS as well? If so your ftsab should just look like I pointed out with the backup drive having the compress option as well.

#11

A backup drive can be either compressed or not. I have two backup drives which are compressed. And one backup drive that isn’t, mainly because it has a ton of free space on it, and most files are formats that are already compressed.

1 Like
#12

It was not; but after seeing your response I decided to reformat the entire drive into BTRFS. I will then apply the changes to fstab.

#13

OK; it´s done. I followed all steps and applied compression to both drives and all looks fine. In the case of the backup drive and as anticipated, I applied a full reformat to BTRFS. Then, I used Deja-Dup as backup tool, instead of Timeshift. Once backup was completed, modified fstab. So far, so good. Thanks for your support.

#14

I didn’t use the -v argument while doing this, is it recommended ? What this argument does as it was not previously there in
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#How_to_test

Also you said you did (sudo btrfs filesystem defrag -czstd -rv / /home/jcvminou) , Thats what I did to convert existing system. Is it fine to redo this command (I think it will just compress again) but if someone can confirm.

gnome-system-monitor should change the backend from libgtop to something used by baobab (disk usage analyzer).

#15

It’s just a verbose switch if you want to see what it’s doing.

Also you said you did (sudo btrfs filesystem defrag -czstd -rv / /home/jcvminou) , Thats what I did to convert existing system. Is it fine to redo this command (I think it will just compress again) but if someone can confirm.

It’ll submit everything for defrag/compression again.

It’s not strictly necessary to do this step. You can just leave things uncompressed, and change /etc/fstab to enable compression for all new writes.

#16

@chrismurphy I was kind of able to re produce the issue, I did defrag and compression again and it solved my gnome system monitor issue. And I saw that live in action as I kept my system monitor on and it fixed it in between. However on my other system I did defrag and compress and kept my eye on the system monitor, it created the same bug but during the same run it fixed it as well. So maybe re iterating defrag and compression on some systems can reproduce this bug. On my laptop I was not able to reproduce the bug tho I did defrag and compression 5 times and couldn’t reproduce the issue.

Pass this info to the same bugzilla issue. Currently the solution is just defrag and compress again :slight_smile:

#17

Hopefully, this helps :grinning_face_with_smiling_eyes:

2 Likes
#18

Thanks for this post. However we were discussing issue with gnome system monitor (specifically libgtop) showing 100 percent disk usage after enabling compression on some systems. We solved this by doing defrag/compress again. This also happens on few newer installations as well. Just a cosmetic issue. But we have an issue on on bugzilla and gitlab. @nickavem

#19

I still can’t reproduce it. If it happens again, the best thing to do is try to get some debugging information out of system-monitor/libgtop rather than stomping on things with a heavy weight operation like defragmenting again. That just makes it harder to find someone who has the problem to get us the debugging information we need.

#20

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