You are not logged in.
I recently discovered BTRFS and have been reading up about its advantages and disadvantages. I am especially interested in the snapshot capabilities. But apparently those work the same way even if CoW is globally turned off.
So why doesn't everyone use BTRFS with CoW turned off, which would mitigate disadvantages like fragmentation (and maybe write amplification which I don't really understand) without losing the advantage of having snapshots? What use is there in CoW vs overwriting when the old data has no metadata pointing to it?
Apparently, disabling CoW also disables checksums so data corruption can't be detected by the filesystem anymore? That seems to just be a lacking feature though, and not an issue that is fundamentally associated with disabled CoW.
Last edited by GearMic (2024-05-06 17:48:35)
That bench may be iron, but I assure you it's quite comfortable.
Offline
I like CoW because it confers immunity to power-loss induced filesystem corruption.
A quick search reveals some other potential advantages, for example: https://storagegaga.wordpress.com/2011/ … e-systems/
But I'm no expert.
Para todos todo, para nosotros nada
Offline
I'm not an expert on BTRFS either, but I like to use it. Please don't take articles and tests from 2011 seriously. Since then BTRFS has done a lot of development and is now completely different. Much more refined and reliable.
Read this - it will help you a lot:
https://wiki.archlinux.org/title/btrfs
https://btrfs.readthedocs.io/en/latest/
https://gist.github.com/braindevices/fd … 77562aafec
Offline
I like CoW because it confers immunity to power-loss induced filesystem corruption.
A quick search reveals some other potential advantages, for example: https://storagegaga.wordpress.com/2011/ … e-systems/
But I'm no expert.
Could a power loss cause corruption of the whole file system or only something that is being written at that time? Do "ordinary" filesystems like Ext4 have any mechanisms to prevent this or are they completely vulnerable?
The link you posted makes an interesting point, though it only explains things very loosely imo.
That bench may be iron, but I assure you it's quite comfortable.
Offline
I'm not an expert on BTRFS either, but I like to use it. Please don't take articles and tests from 2011 seriously. Since then BTRFS has done a lot of development and is now completely different. Much more refined and reliable.
Read this - it will help you a lot:
https://wiki.archlinux.org/title/btrfs
https://btrfs.readthedocs.io/en/latest/
https://gist.github.com/braindevices/fd … 77562aafec
I already read through most of the Arch Wiki article and some of the relevant BTRFS documentation entries. I might have missed something but I didn't really find any proper comparison between COW and NOCOW.
Another question: Have you ever had problems with a BTRFS SSD becoming slow or causing a lot of CPU overhead due to the amount of fragmentation? Fragmentation is my main concern and is one of the reasons why I'm considering to disable CoW.
That bench may be iron, but I assure you it's quite comfortable.
Offline
You have to realize one important thing, and that is that there is no one-size-fits-all scenario. We all have different requirements for what we want from the system. Speed, reliability,... and everything has its advantages and disadvantages.
In fact, copy on write (COW) is the main advantage of Btrfs, so it's pointless to turn it off - choose another filesystem instead.
You haven't written if you are dealing with a desktop, workstation, server, database intensive, etc. What kind of modern hw do you have? For my idea.
I use Btrfs with NVMe drives and have not observed any problems or fragmentation. If you don't have any problems - don't worry about it those SSD/NVMe are just common consumables that last a lot and if not they get replaced with new ones.
I spent some time debugging the parameters for the mount and in the end this worked best for me:
rw,noatime,compress=lzo,ssd,discard,space_cache=v2,commit=120
For me, the huge advantage is reliability + the ability to work with snapshots at atomic speed. It's saved my ass many times in production.
If you don't know, check it out: https://github.com/Antynea/grub-btrfs | https://archlinux.org/packages/extra/any/grub-btrfs/
Last edited by vecino (2024-05-09 20:35:41)
Offline
I'm planning to set up my Desktop PC with Arch, which I mainly use for coding aside from browsing the internet. I'm using an NVMe SSD too.
The reason why I'm interested in BTRFS are the snapshots because I want to be able to mess around with my system without the risk of causing lasting harm.
Thanks for the mount options. Have you done anything to deal with databases on your system? I read that most kinds of databases, including those used by firefox for example, can cause lots of writes leading to significant fragmentation with CoW enabled. But of course CoW could be disabled individually for those folders.
That bench may be iron, but I assure you it's quite comfortable.
Offline
There is no database like a database. There is a difference between some corporate / server db where several hundred gigabytes are written daily. On a home workstation where your FireFox uses a local mini database with little data/few writes - that's nothing. Please don't worry about it at all.
The lifespan of an NVMe SSD, like any other solid-state drive, is determined by the number of write and erase cycles it can endure before it starts to fail. This metric is often referred to as the drive's endurance or total bytes written (TBW) rating.
The endurance rating of an NVMe SSD can vary depending on the specific model and manufacturer. Typically, consumer-grade NVMe SSDs have endurance ratings that range from tens of terabytes written (TBW) to hundreds of terabytes written. Enterprise-grade NVMe SSDs tend to have higher endurance ratings, often in the hundreds or thousands of terabytes written.
It's important to note that endurance ratings are estimates based on industry-standard testing methodologies and assumptions about typical usage patterns. In real-world scenarios, the actual lifespan of an NVMe SSD can vary depending on factors such as workload intensity, write amplification, and temperature.
Modern NVMe SSDs also incorporate various technologies like wear-leveling, over-provisioning, and error correction to help prolong their lifespan and ensure data integrity.
In general, for typical consumer workloads, a modern NVMe SSD should last for many years before reaching its specified endurance limit. However, it's always a good idea to monitor the drive's health using tools provided by the manufacturer and to maintain regular backups of important data to guard against unexpected failures.
Last edited by vecino (2024-05-12 20:17:58)
Offline
Did you post that text somewhere else before? It seems familiar somehow.
Either way, thank you for the explanations
That bench may be iron, but I assure you it's quite comfortable.
Offline
I used google - there is a lot on this topic. Try: https://www.google.com/search?q=ssd+lifespan+tbw
Offline