Hi @lord_valarian , I read the discussion here (Tue Jan 30 08:26:17 CET 2024) . Im somewhat familiar with the concerns and experiences of yours and of other authors here, too. I want to offer some comments about thoughts I had when reading posts and replies to this topic.
Since 2016 and to this day I have worked with BtrFS on Samsung 850 PRO SSDs in Lenovo W530 Thinkpads.
VERY happy with my hardware ever since. However, because of bold experimentations (compliled newer GNU glibc’s as there were initially on my openSUSE Leap 42.3 OS’es) my OS’es have become more vulnerable by 2020. The Leap 42.3 OS’es began to freeze, so that I pulled the plug on them on a daily basis.
Updating/upgrading was no longer possible, however, switching to openSUSE Leap 15.x was imminent these days anyway. So was it the fault of BtrFS, or - asked more precisely - was it the fault of BtrFS ALONE?
WHY might BtrFS be recommended for SSDs anyway? - I asked this question at Phind.com.
Answer | Phind V9 Model
BtrFS is recommended for use on SSDs due to several reasons:
-
Copy-on-Write (COW) Mechanism: BtrFS uses a COW mechanism for writing data. Instead of updating data in place, it writes a new copy to a different location and then atomically switches the pointers. This method is beneficial for SSDs because it reduces the risk of write amplification, which can significantly decrease the lifespan of SSDs 4.
-
Error Correction: BtrFS includes built-in mechanisms for error detection and correction. For instance, it uses checksums to detect and repair torn writes, which are writes that are partially completed due to power glitches or other electronic failures. This feature helps maintain the integrity of data on SSDs 4.
-
Reduced Metadata Writes: SSDs are sensitive to metadata writes, which can quickly deplete their write cycles. BtrFS’s features like DUP block group profiles can help reduce these writes, thereby extending the lifespan of SSDs 4.
-
Data Consistency: BtrFS ensures data consistency through its generation-based approach. Logical data updates are grouped into a generation, written on the device, and then the super block is written ending the generation. This approach helps maintain data integrity and prevents data corruption 4.
-
Deduplication and Compression: BtrFS supports data deduplication and compression, which can help optimize the usage of SSD space. These features can reduce the amount of data written to the SSD, prolonging its lifespan 4.
Remember, while BtrFS offers many advantages for SSDs, it’s crucial to regularly monitor the health of your SSDs and ensure they are functioning correctly to extend their lifespan.
So, next I asked this: BTRFS is recommended for SSD’s. But, ext4 is used on many servers for file stability. Is using EXT4 on SSDs recommended, too, and if, why? What else could make sense on SSDs?
Answer | Phind V9 Model
Yes, using ext4 on SSDs is also recommended, although it might not provide all the advanced features that BtrFS does. Here’s why:
-
Simplicity: Ext4 is simpler and more mature than BtrFS. It has been around for a longer time and is more widely supported across various systems. This simplicity can make it easier to manage and troubleshoot issues 4.
-
Stability: As you mentioned, ext4 is commonly used on servers for file stability. It provides robust support for large file systems and handles errors well, making it a reliable choice for critical applications 1.
-
Compatibility: Ext4 is compatible with a wide range of Linux distributions and other operating systems, which can be advantageous when working in heterogeneous environments 4.
Other filesystems that could be considered for SSDs include F2FS and XFS. These filesystems have specific advantages over ext4 and BtrFS depending on the use case:
-
F2FS: This filesystem is designed specifically for NAND flash memory-based storage devices (like SSDs). It supports wear leveling and bad block management, which can help extend the lifespan of SSDs 4.
-
XFS: XFS is known for its high performance and scalability. It supports large files and file systems, and it can handle large amounts of data efficiently. However, it lacks some of the advanced features found in BtrFS 4.
In conclusion, the choice between ext4, BtrFS, F2FS, and XFS depends on your specific needs and the nature of your workloads. Each filesystem has its strengths and weaknesses, and understanding these can help you make an informed decision.
So far to my encounter with Phind.com of today.
One last point comes to my mind. In my view, it would probably be beneficial if we mentioned more the reasons WHY we did what we did when issues would arise. The topic here reads “Best backup format for SSD’s - KDE”. However, nobody complains about KDE here if I am correct. If that’s true then let’s focus on “backup” for my closing remark here.
As Phind.com says, the choice between Btrfs, EXT4 or others depend s on the specific needs and the nature of workloads. However, in reality, in my view it depends also on our current state of knowledge and experience with certain technologies. What if BtrFS is new to you but it’s EXT4 that is mastered by you? How detrimental can it be if you use EXT4 instead of BtrFS? How much time is really to be saved if using X is said to be produce faster outcomes than Y? All to often manifest advantages are there, sure, but what if doing it the old-fashioned way is doing okay, too?
@lord_valarian , did you compare using BtrFS AND EXT4 on two separate partitions on your SSD? What if the driver or at least only the current VERSION of it in use just isn’t a good fit for using BtrFS on it, but using EXT4 would be somehow okay, even if we had no immediate explanation at hand why that might be so? Can we rule out such from the beginning?
Even if I did not provide all the answers - or any answer for that - I still hope that my comment might be of some faint inspiration. Maybe searching for the “best” solution for one’s problem is worth while indeed. And maybe doing just okay with the “second best” solution - at least for the time being - is no shame either?
Regards, M.
