We have been using btrfs on around 30,000 devices since 2016. And it works very well. The number of devices with a corrupted file system is minimal. The file system can even survive power loss without any significant problems.
However, we do not cram the btrfs file system full either. Having too little free space is something btrfs does not like at all.
Tip:
Use snapper or timeshift with btrfs, and keep it under 90%
Only users who consume 50 to 100% of the SSDās actual lifetime writes need to be concerned by the write amplification of btrfs DUP metadata. Most users will be far below 50% of the actual lifetime, or will write the drive to death and discover how many writes 100% of the actual lifetime was. SSD firmware often adds its own write multipliers that can be arbitrary and unpredictable and dependent on application behavior, and these will typically have far greater effect on SSD lifespan than DUP metadata. Itās more or less impossible to predict when a SSD will run out of lifetime writes to within a factor of two, so itās hard to justify wear reduction as a benefit.
30 000 devices is a big number and did you have a lot of sata ssds or nvmes?
If yes where there some optimisations for flash based storage?
I will be building also a small Server/Nas next year that could also useful for that.
Make sure to enable it. To my knowledge, there was no way this got enabled through upgrades (even with properly dealing with pacnew files.)
sudo systemctl enable fstrim.timer
We do.
You can just choose btrfs in the pull down for the installer. There are 4 choices for the file system type there.
Whether you use the automatic partition layout, or use the installer to make a btrfs root partition manually (through the GUI installer). Both are essentially an easy way to install btrfs.
I will be anyway reinstalling on my desktop soon but I should check that on my laptop.
As I was booting with the lives USB I was not going that far but then today I tried in a Virtualbox VM and had some problems like Calamers was mirroring the GUI and could not see everything that was strange so that is why I thought the option was not there.
I will try in a few days with the live USB again to take a look.
A problem with your Virtualbox guest configuration most likely. I do advanced things with Qemu, but I havenāt touched Virtualbox in decades.
But a misconfigured emulated video adapter could cause this in either scenario.
With video issues with Qemu, I start with a plain VGA adapter with no more than 16M of VRAM. (This isnāt even enough memory to support 1080p, but it will work in lower resolutions. And itās the most compatible.) And Virtualbox has their version of this too.
This is just to get it working, and your OS installed. Then you can proceed to get more advanced types of video working. Whether it be SPICE, (virtio?), and Virtualboxās other video adapters.
No, BTRFS is not recommended; however it has reached a level of maturity to be considered a valid option for those who are comfortable with managing it.
What is recommended is to read, learn and understand not only the differences in filesystems, but also the ramifications of making bad choices during installation.
This kind of knowledge is extremely important from the onset, and you already know this, otherwise you would not be here seeking additional guidance. Instead, you might have joined so many others who blindly configured BTRFS, expecting it to be set-and-forget, and later reaping the consequences of poor decisions.
Disclaimer:- I have never used BTRFS. My knowledge of the topic does not extend beyond what Iāve read, and that personal knowledge base has increased in recent months while Iām considering using BTRFS for a future Manjaro installation. Thus far, I have used EXT4 on (Samsung) SSDās and have found this sufficient for my needs.
I have noticed that some have difficulty with software not detecting/recognising NVMe devices, even though there is no issue during installation. My technical term for this is ātoo new, too soonā; a new NVMe device is installed to equally new hardware, and the Linux community (generally) hasnāt yet caught up. This may not affect you at all, but itās something to be aware of.
As far as I am aware F2FS was originally intended for USB flash disks ā much like Microsoftās FAT32 and EXFAT ā though I do recall random references online by people claiming to use is for other purposes.
My opinion is that while F2FS can perform better on some Android devices (the data partition is typically F2FS on more recent devices) this is not an indicator that it could/should be used in more performance-intensive environments ā we already have better suited filesystem choices.
For your purposes, Iād suggest remaining with EXT4 rather than attempting to use F2FS for your Steam Library might be the smarter choice. I would certainly weigh the (likely minimal) performance gain against the risk of failure before committing to using it.
I doubt there are many who tried this, though I suspect those who may have, soon returned to a more familiar Linux filesystem.
An additional SSD always has some value; and can be used for many purposes:
To keep /home separate ā itās handy to know your personal data is safe if/when you need to reinstall or perform other potentially risky disk operations.
/temp, /var et. al., might be better served on another disk (or partition); there are no doubt many possibilities, depending upon the use case. With careful consideration you might create several of these, and even a 64 GB swap partition on that same SSD. Obviously, this would require a hands-on approach, and use of the manual partitioning method during installation. Iād suggest playing with a few VM installations using this method to better understand the outcomes of choices made.
I personally use a separate (HDD) partition for housing any Virtual Machines I use; for convenience; a separate SSD could be just as effective.
A separate disk is a valid consideration for backups, no matter which tools you might use.
Allows a multiboot scenario between Manjaro and [Foreign OS] the safest way possible ā on separate disks.
Many of the possibilities mentioned might take a finer grained control of your installation options; especially in the case of BTRFS; so, Iād likely disagree with @BG405 on that point.
However, regarding swap, not having any defined at all can potentially leave bite marks on oneās derriere at some point. If you had wished to use hibernation since your 2019 install, for example, you would have had no success without sufficient swap being configured ā hibernated data must have somewhere to go ā and that place is swap (this is true no matter the amount of system RAM).
My personal rule-of-thumb; Iād much rather have all the swap space I could ever need, and rarely need it, than to not have enough when itās needed, and suffer the consequences.
In Calamares (Manjaro installer ISO), choosing the erase disk partitioning method during install will show a dropdown that allows to choose your swap options. With those options selected, installation will continue and automatically create swap as per your requirements; if no selection is made, no swap is configured. The manual partitioning method is entirely hands-on (nothing is automated).
Itās possible you missed it (as others clearly have) in the excitement of installing a new OS.
Maybe so. Remember that so-called flash storage is only a distant cousin of NVMe based product.With NVMe you are effectively using the same technology as RAM, only the data written isnāt lost if you reboot; this is inferred by Non-Volatile Memory. Iām sure there are better ways to say that, but in my Covid-ridden state, itās the easiest that comes to mind.
Thatās much like asking āHow long is a ball of string?ā ā we never know until we reach the end. In the case of F2FS it could mature but still not be any more useful than giving Android devices a competitive advantage. I imagine that if EXFAT was available (open-source) in 2012 we might be seeing that used instead, but that miracle of M$ generosity didnāt happen until some years later: exFAT in the Linux kernel? Yes!.
Or, sometimes never.
This List of filesystems on Wikipedia may give the OP a fair overview of filesystems, and their intended usage.
Disclaimer:-
These opinions are my own;
Tomorrow, they may may be different; or, I may have none at all.
Yes that why I am careful and seek advice.'from other Linux users.
Well yes but Steam game Data is not that important if it goes wrong I can format it again and re download
Why would you consider Btrfs for your next installation?
Does someone know which is superior Btrfs with its Btrfs snapshots and Grub option to boot in to the snapshots in case of something goes wrong or Ext4 with Rsync via Timeshift but then we need to chroot via a Live USB if something goes wrong?
This is more a question of taste, and you will get many different answers to this.
My opinion:
Snapshots are a memory-saving and elegant way of doing rollbacks. (applies to btrfs and snapshots) But this does not save you from having to do proper backups.
Timeshift with rsync is more like a type of backup / restore
You have to weigh up the advantages and disadvantages yourself After all, you have to bear the consequences of your decision yourself.
I will go with Ext4 with as swap file on my Desktop to be sure and the quality of a Drive is also a factor so a Samsung 980 PRO NVME gen4 is pretty good and I should not worry too much if my Samsung 860 EVO Sata drive survived for over 5 years and probably longer.
I am testing Btrfs on a small Fedora-Sever on a separate Server Board for a NAS and I have it on Nobara Linux on my Samsung 970 EVO PLUS gen3 NVME drive so if do not get any big problems I will consider it for a future Reinstall on my Laptop that way it is safer.
I am testing F2fs on my new Patriot P210 sata drive and if I do not like or get problems I can easily reformat it to Ext4 or Btrfs or maybe something else
I am in the process of considering BTRFS for my next Manjaro installation, and I have the same amount of information available to me as you do.
I expect the entire process will involve several VMs over time, while trying my best to break each BTRFS installation and subsequently attempt recovery. If I am ultimately satisfied that BTRFS suits me, and that Iāve gained enough knowledge on the possible pitfalls, only then will I commit to a hard install.
Sounds about right a lot of testing then decide if is good or not
I had the same thought about breaking it on purpose in a VM then recover but did not have the time to do it and not really a good idea how to simulate that
Itās not easy to break it (since the problem that i broke mine with, is now fixed). If you decide to go with the hard install, I suggest using btrfs-raid with 2 SSDs (from different manufacturers ). That seems to be almost indestructible.