The main thing that bogs down btrfs is having a ton of snapshots that you don’t need. If you just make snapshots and never clean any of them up your gonna have a big issue at some point. I recommend keeping at most 20 snapshots at any one time.
Usually my rule of thumb is 1 snapshot a month keep and than several weeks of past snapshots. If you do a lot of stuff in one day than I would trade all the monthly snapshots for hourly snapshots just in case you would need to go back to something in the last hour.
If you don’t care about a minor slowdown you can keep up to 50 snapshots at that point it starts to slow significantly.
I think that btrfs is super user friendly. Most things can be done with a single command and the documentation is top notch. For being terminal driven it’s really simple.
You need to set the right options on mount. Before I did that I was just using the default and on my nvme it sucked but than I optimized it with some nvme/ssd friendly options.
ssd: use SSD specific options for optimal use on SSD and NVME
noatime: prevent frequent disk writes by instructing the Linux kernel not to store the last access time of files and folders
space_cache: allows btrfs to store free space cache on the disk to make caching of a block group much quicker
commit=120: time interval in which data is written to the filesystem
compress=zstd: allows to specify the compression algorithm which we want to use. btrfs provides lzo, zstd and zlib compression algorithms. Based on some Phoronix test cases, zstd seems to be the better performing candidate.
Lastly the pass flag for fschk in the fstab is useless for btrfs and should be set to 0.
But it is picky about its friends. If you look it from the point of view of a sysadmin operating from command line and compare it with lvm+ext4, it is just a delight to use, super simple and understandable and efficient. If you look it from perspective of a windows refugee or a casual user, it is too complicated to even understand its awesome features and it comes with some pretty severe caveats that can leave their system unbootable beyond their ability to repair. It’s this latter issue I wish to tackle.
I want to have a default setup that guides new users away from the caveats and automates the necessary maintenance work, so for simple users it just works and does not do anything weird.
I do agree with you. Even just having to install an operating system is too much for most people let alone manage a file system.
I think if there were more distros that used btrfs by default and more gui applications were developed for it oh and the file managers actually reported the right data used on the partions than it would be super user friendly.
I use Btrfs on all my machines, with compression, snapshots, subvolumes. This system is not for newbies. There is no mature disaster recovery tools like for ext4 or even windows systems. And most importantly Btrfs tends to crash hard once run out of space. Tell that to ex-Windows users, that once you exhausts space by accident, you can’t just delete few files and reboot and everything is back to normal.
Until this is solved I don’t think it should be a default FS for Manjaro.
This. Also it does not help that most tools are going to report the free space wrong, and if not kept in check the metadata will fill up the disk. This is where btrfs-maintenance comes in, doing the space management tasks automatically on the background. Probably also still needs some kind of service to warn about low disk space with desktop notifications.
That’s still not enough. Imagine you are newbie to Linux, installed Manjaro, all is well, you decided to download game overnight, you wake up and it stopped downloading as hard drive is full. OK, darn, let’s delete partial downloaded file and reboot. Space will be back. On Windows, yes, on Btrfs, black console screen and your system is f**ked.
For newbies this will mean format and install Windows 10, problem solved.
It would be back if there are not snapshots inbetween. In the default configuration there would be snapshots only on boot and pacman actions.
Now, let’s say that system is slow or unresponsive because of the missing disk space and user tries to fix it by rebooting. Now we are at your scenario
What other remedies would be useful? You could get some more disk space to get some breathing room by temporarily adding part of your ram to your btrfs volume, but there is no safe or sane way to automate that
Yes, my 12 year son did exactly that on his Linux Mint machine. Btrfs / on SSD was toasted, despite my setting up additional HDD for games etc. I had to add RAM disk to Btrfs, rebalance, delete some files, rebalance back, remove RAM disk. This should be automatically detected and fixed by Btrfs, but it’s not. That’s why I think that from newbie perspective, risks of defaulting to Btrfs outweigh benefits.
I got you, but first opening post asked “Im curious will Manjaro make BTRFS a default file system?” Well answer today to that is no (I hope so).
I will gladly see more options in the installer though. Like
Erase and install Manjaro using Ext4 partitioning (default)
Erase and install Manjaro using Btrfs partitioning (advanced)
(…)
For example.
I think I’ve tried those tweaks but don’t remember. I’ll try creating a partition now with those options and test it with fio, and other stuff. I hope I remember to put my findings here
Funny thing about this is they said they needed to revert it and I bet they used snapshots to revert it which is another function of btrfs for this exact purpose.
No, they are using proper tools for version control (git in the case of kernel development).
Filesystems and their ability to snapshot and revert to an earlier point in time are not suitable for such cases: one does not want to revert all changes, only the ones regarding the problem.
You can snapshot individual subvolumes and subvolumes within subvolumes so it is possible to just use btrfs snapshots to do that kinda thing if you wanted. I do see what you mean though and your probably right that it’s git or something.
@Chrysostomus A question: Is it possible to have btrfs only on the main drive (say SSD, for instance) and ext4 on the back up disk / disks (HDD and/or SSD) ? What about external back up disks?
Yes that’s possible, but then you don’t get the nice feature of BTRFS to make differential backups with btrfs send | btrfs receive combination. Such backups, i let made daily, need 5-15 seconds for the entire system, including home, and with ssh tunnel over wlan. On the last bigger manjaro update (1.5GB changed) it needed 3-5 minutes in background. Another feature set you don’t get, are the BTRFS main features, like compression and so on. With backups into BTRFS backup partition you get all nice features you have with snapshots in common. Today on my 1TiB BTRFS backup drive i use 10% of real space for 4 computers, but the space computed by Dolphin are 1.3TiB
PS: another nice feature, if btrfs is correctly setup’ed, is the possibility to boot into backups. My backup drive contains a fully working and bootable Manjaro system. The backup drive is a USB attached SATA3 SSD. Because all may systems use a identical Manjaro-Setup i can now boot a backup made from another machine with this external Manjaro setup from the backups made Realy nice!
