cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=CDC4-BD71 /boot/efi vfat umask=0077 0 2
UUID=3e4fdbeb-2901-4b6d-af93-6235da8fbfc2 / btrfs subvol=/@,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=3e4fdbeb-2901-4b6d-af93-6235da8fbfc2 /home btrfs subvol=/@home,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=3e4fdbeb-2901-4b6d-af93-6235da8fbfc2 /var/cache btrfs subvol=/@cache,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=3e4fdbeb-2901-4b6d-af93-6235da8fbfc2 /var/log btrfs subvol=/@log,defaults,noatime,autodefrag,compress=zstd 0 0
According to fedora wiki remove compress=zstd as root and reboot. I am not sure if the compressed files will be reverted back to normal or not once the parameter is removed. Maybe new ones won’t compress. @Aragorn can help.
I have now removed the compression from the fstab. The files then remain compressed. I made them normal again with “btrfs filesystem defragment -v -r -f /home/user”.
@philm
Don’t you think filesystem compression should be optional? An option in the installer or as a preference item in Manjaro-settings?
I make regular backups to hard disks. Now if my file system compresses, I can’t make sure the backup disks have enough space.
First a little word of explanation. The OP is wrong in assuming that the filesystem itself would be compressed. It is not.
btrfs simply applies compression upon storing a new file if compression is enabled in the mount options. It also supports three types of compression, of which zstd is the most efficient and best performing.
When compression is disabled in the mount options, the existing compressed files will still remain compressed ─ and with whatever algorithm was used for compressing them when they were created ─ unless they are being rewritten to different drive blocks/extents. Compression and decompression are transparent in btrfs, and given that disk I/O is a bottleneck, it costs less time to read a compressed file and decompress it than it does to read an uncompressed file.
It would be pretty silly to choose btrfs as the fileystem that you’re going to install your system on if you don’t make use of any of its features. Then you might as well choose ext4.
Use the same filesystem on the drive for the backups as you use for the system. My system is installed on an SSD, and I back up to an internal HDD. The backup partition on the HDD also uses btrfs.
Besides, if you’re using Timeshift for backups, then you’re using far less space than what you might think, because Timeshift uses rsync, which in turn uses hard-linking against the original backup for files that have not been modified. Hard-links don’t take up any space ─ they are merely additional directory entries for already existing inodes.
Every file compressed by btrfs is compressed transparently.
A du will show the size you need on your backup.
In every single point in your linux you will see the size of the file mentioned with its uncompressed size
If you use btrfs and disable features you do not know anything about, it is useless to use btrfs at all.
I know. But what makes you think I would do backups with timeshift? I never talked about that.
By the way: A backup is in my understanding, on another data medium, preferably somewhere else protected from fire or something. But let’s not talk about differences between snaphots and backups anymore.
If you do not care about the compression but you want better performance, then just use compress=zstd:1 which corresponds to level 1 (bad compression ratio, good speed)