4 ms·

From the blog post: > Even if your btrfs, after almost 18 years, still eats data in spectacular fashion. Is this (by now) an urban legend ? Is btrfs any less

From the blog post: > Even if your btrfs, after almost 18 years, still eats data in spectacular fashion. Is this (by now) an urban legend ? Is btrfs any less reliable than, say, xfs/ext4 etc. nowadays ?

zorked 11mo ago
No, Linux is made of legends that never die.
XorNot 11mo ago
I wouldn't know I've been running ZFS for well over a decade.
alrs 11mo ago
Traditionally it was btrfs RAID5/6 that really sucked. I've not played with it.
Propelloni 11mo ago
SUSE is using btrfs as the default filesystem in all their offerings. I think that SLES is less widespread than RHEL, but I also think those people at SUSE know what they are doing. It's not like we hear of massive data loss from SLES environments all the time.
kiney 11mo ago
for features declared stable it's been an urban legend for a long time. I use BTRFS in prod since I think 2016 which was also the last year I lost data to an BTRFS Bug
chao- 11mo ago
I used btrfs for most of the 2010's. I nearly lost some data once, and was able to recover it. Afterwards, I moved to ZFS and never looked back. btrfs may be great now, and more power to people who use it and are happy. However, I am so used to the ergonomics of ZFS (and zed, and ZFS integrated encryption) that I don't see a reason to migrate back.
5d41402abc4b 11mo ago
BTRFS is fine if you use it on enterprise grade hardware, if you use it on consumer hardware expect to lose data.
- tasuki 11mo ago
  Why and how does enterprise vs consumer hardware make a difference wrt btrfs data loss?
b2ccb2 11mo ago
The RAID 5 and RAID 6 modes of Btrfs are fatally flawed, and should not be used for "anything but testing with throw-away data." From the ArchWiki: https://wiki.archlinux.org/title/Btrfs#Multi-device_file_system https://wiki.archlinux.org/title/Btrfs#Multi-device_file_sys...
lloeki 11mo ago
Even the much-maligned raid5/6 is basically fine†. If you're concerned about the write hole, use -m DUP/raid1/raid1c2 instead of -m raid5. Plus raid-stripe-tree†† is coming - didn't check the status of it recently. Many horror stories are because, while btrfs is fine, the operational model and tooling have some footguns which can cause either straight up data loss (due to operator error, but arguably that's really due to bad UX) or possible-but-hard-to-get-out-of situations. I use btrfs because using zfs has been painful for me, for two reasons: - btrfs can "shapeshift": I progressively moved _live_ from 2hdd raid1 to 5hdd raid5 data + raid1c2 meta with varying experiments in between. Probably five or six rebalance to change its shape over the years. - the zfs module situation: when I tried it, the module silently failed to build properly and this resulted in a broken system til I fixed it; this happened twice over six months. Luckily I anticipated this failure mode and only the data array (not the root fs) was zfs, so I could still boot and login into a full system to fix. Compared to zfs, btrfs is slow to scrub and rebalance though. † https://unixdigest.com/articles/battle-testing-zfs-btrfs-and-mdadm-dm.html#btrfs-the-write-hole-issue https://unixdigest.com/articles/battle-testing-zfs-btrfs-and... †† https://lore.kernel.org/linux-btrfs/cover.1698679287.git.dsterba@suse.com/T/#u https://lore.kernel.org/linux-btrfs/cover.1698679287.git.dst...
matrss 11mo ago
I've lost my laptops SSD (as in: no longer mountable, only got data out of it with some rescue tools) at some point between 2017 and 2020, don't remember when exactly. I've also had a weird experience where a btrfs filesystem formatted on my desktop PC was not mountable on a Raspberry Pi, and vice versa formatted on the Pi was not mountable on the desktop. That didn't instill confidence either. On the other hand, I've been running a btrfs RAID1 on two HGST datacenter drives for a few years and haven't had issues with that.

zorked 11mo ago

No, Linux is made of legends that never die.

XorNot 11mo ago

I wouldn't know I've been running ZFS for well over a decade.

alrs 11mo ago

Traditionally it was btrfs RAID5/6 that really sucked. I've not played with it.

Propelloni 11mo ago

SUSE is using btrfs as the default filesystem in all their offerings. I think that SLES is less widespread than RHEL, but I also think those people at SUSE know what they are doing. It's not like we hear of massive data loss from SLES environments all the time.

kiney 11mo ago

for features declared stable it's been an urban legend for a long time. I use BTRFS in prod since I think 2016 which was also the last year I lost data to an BTRFS Bug

chao- 11mo ago

I used btrfs for most of the 2010's. I nearly lost some data once, and was able to recover it. Afterwards, I moved to ZFS and never looked back. btrfs may be great now, and more power to people who use it and are happy. However, I am so used to the ergonomics of ZFS (and zed, and ZFS integrated encryption) that I don't see a reason to migrate back.

5d41402abc4b 11mo ago

BTRFS is fine if you use it on enterprise grade hardware, if you use it on consumer hardware expect to lose data.

tasuki 11mo ago
Why and how does enterprise vs consumer hardware make a difference wrt btrfs data loss?

b2ccb2 11mo ago

The RAID 5 and RAID 6 modes of Btrfs are fatally flawed, and should not be used for "anything but testing with throw-away data." From the ArchWiki: https://wiki.archlinux.org/title/Btrfs#Multi-device_file_system https://wiki.archlinux.org/title/Btrfs#Multi-device_file_sys...

lloeki 11mo ago

Even the much-maligned raid5/6 is basically fine†. If you're concerned about the write hole, use -m DUP/raid1/raid1c2 instead of -m raid5. Plus raid-stripe-tree†† is coming - didn't check the status of it recently. Many horror stories are because, while btrfs is fine, the operational model and tooling have some footguns which can cause either straight up data loss (due to operator error, but arguably that's really due to bad UX) or possible-but-hard-to-get-out-of situations. I use btrfs because using zfs has been painful for me, for two reasons: - btrfs can "shapeshift": I progressively moved _live_ from 2hdd raid1 to 5hdd raid5 data + raid1c2 meta with varying experiments in between. Probably five or six rebalance to change its shape over the years. - the zfs module situation: when I tried it, the module silently failed to build properly and this resulted in a broken system til I fixed it; this happened twice over six months. Luckily I anticipated this failure mode and only the data array (not the root fs) was zfs, so I could still boot and login into a full system to fix. Compared to zfs, btrfs is slow to scrub and rebalance though. † https://unixdigest.com/articles/battle-testing-zfs-btrfs-and-mdadm-dm.html#btrfs-the-write-hole-issue https://unixdigest.com/articles/battle-testing-zfs-btrfs-and... †† https://lore.kernel.org/linux-btrfs/cover.1698679287.git.dsterba@suse.com/T/#u https://lore.kernel.org/linux-btrfs/cover.1698679287.git.dst...

matrss 11mo ago

I've lost my laptops SSD (as in: no longer mountable, only got data out of it with some rescue tools) at some point between 2017 and 2020, don't remember when exactly. I've also had a weird experience where a btrfs filesystem formatted on my desktop PC was not mountable on a Raspberry Pi, and vice versa formatted on the Pi was not mountable on the desktop. That didn't instill confidence either. On the other hand, I've been running a btrfs RAID1 on two HGST datacenter drives for a few years and haven't had issues with that.