Background: Four or five years back, I decided to try btrfs because the snapshot feature looked really good. Over some months, I ran it on my usual set-up … as in the root filesystem on a software mdraid level 1 device. During that time, the btrfs became horribly corrupted on several occasions, leaving no choice but to re-install the OS, which was whatever the equivalent of “leap” was at that time.
At that time, I did come across some documentation that stated something along the lines of “run btrfs on mdraid, it WILL become irreparably corrupted”. Unfortunately, I don’t remember where I found this, nor am I amble to find it today. In the btrfs documentation, I am unable to find any use of the words “mdraid” or “mdadm” or similar. Searching for “btrfs best practices” hasn’t helped either.
I am still intrigued by btrfs, even though I don’t use it. A genuinely opensource answer to ZFS perhaps?
I am interested in knowing if there is any good information about using btrfs in conjunction with mdraid. When I next try using btrfs for those cool snapshots, I will do so with built in btrfs mirroring, which seems to be stable at this point in time.
Yes, this is the best practice. Use btrfs with its own volume management and RAID 1 profile using SSDs, you should be good
Not recommended to use other RAID profiles, mismatched data/metadata RAID profiles, with mdraid for volume management, with slow HDDs, etc.
My experience with btrfs is that if you stick to the happy path then all will be good. Try weird but totally valid stuff (like mismatched HDDs or RAID profiles) and you will run into filesystem breaking issues.
LUKS + btrfs is OK for encryption.
openSUSE automatically enables btrfs scrub to fix data/metadata errors from good copy and rebalance to balance data equally across drives every month. I recommend changing it to every week by editing /etc/sysconfig/btrfsmaintenance.
Yep, there is a certain metadata cost to all the awesome features btrfs provides over a more traditional filesystem like ext4. When both the data and metadata live on a slow 5400 RPM HDD (commonly found in laptops and external drives) this has the potential to slow operations to a crawl and in my case have gone on to corrupt data.
Thank you for the clarification! It makes me wonder how opensuse can justify using btrfs as the “default” file system for a yast guided newbie install.
Perhaps it is just a bit of maverick suse culture … remember reiserfs?
I must preface what I’m about to write by first saying I’m a happy btrfs user and have it as the default FS on both my primary and secondary openSUSE machines.
I specifically chose openSUSE due to its awesome btrfs/snapper integration and prepped for at least a month by testing it out and making sure my backup & restore strategy was working before I made the move in early 2024. But even I was unprepared for my btrfs FS imploding in less than a month, all because I was a few inches off the happy path envisioned by the devs and testers.
TL;DR: openSUSE enables btrfs quota/qgroups by default, I enable timeline snapshots on all my machines (for all subvolumes) as they’re an easy restore point if I mess something up which causes a lot of snapshots to be created and that’s all it took for the implosion. I reproduced the issue in a VM but that Bugzilla report is still active and I don’t think anyone really cares.
I’m not saying this to scare anyone away, it’s just the reality of using a bleeding edge filesystem that does make you bleed. Carry your own medkit
I thank you ten times over for writing such a candid and honest response. I don’t remember when it happened, but somehow some time ago it became “controversial” to write anything even vaguely honest.
The only thing that irritates me more than ignored bug reports, are bug reports that I file with a patch file … the SOLUTION … and they are still ignored. And the only thing that irritates me EVEN MORE, when the solution I provide is risk free and trivial. opensuse is actually better than most about fixing bugs, especially if you can provide and explain the patch. MUCH BETTER THAN MOST!