this post was submitted on 23 Nov 2024
36 points (83.3% liked)

Linux

48328 readers
617 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
36
[rant] everytime i give it a chance, btrfs lets me down (lemmy.eco.br)
submitted 22 hours ago by bunitor@lemmy.eco.br to c/linux@lemmy.ml
24 comments fedilink hide all child comments
 

i've instaled opensuse tumbleweed a bunch of times in the last few years, but i always used ext4 instead of btrfs because of previous bad experiences with it nearly a decade ago. every time, with no exceptions, the partition would crap itself into an irrecoverable state

this time around i figured that, since so many years had passed since i last tried btrfs, the filesystem would be in a more reliable state, so i decided to try it again on a new opensuse installation. already, right after installation, os-prober failed to setup opensuse's entry in grub, but maybe that's on me, since my main system is debian (turns out the problem was due to btrfs snapshots)

anyway, after a little more than a week, the partition turned read-only in the middle of a large compilation and then, after i rebooted, the partition died and was irrecoverable. could be due to some bad block or read failure from the hdd (it is supposedly brand new, but i guess it could be busted), but shit like this never happens to me on extfs, even if the hdd is literally dying. also, i have an ext4 and an ufs partition in the same hdd without any issues.

even if we suppose this is the hardware's fault and not btrfs's, should a file system be a little bit more resilient than that? at this rate, i feel like a cosmic ray could set off a btrfs corruption. i hear people claim all the time how mature btrfs is and that it no longer makes sense to create new ext4 partitions, but either i'm extremely unlucky with btrfs or the system is in fucking perpetual beta state and it will never change because it is just good enough for companies who can just, in the case of a partition failure, can just quickly switch the old hdd for a new one and copy the nightly backup over to it

in any case, i am never going to touch btrfs ever again and i'm always going to advise people to choose ext4 instead of btrfs

all 25 comments
sorted by: hot top controversial new old
[–] blackstrat@lemmy.fwgx.uk 5 points 5 hours ago

You're right to give up on btrfs. It's been so long in development and it just isn't ready. Ext4 or ZFS are mature and excellent file systems. There's no need for btrfs these days. It always has and always will disappoint.

Everyone singing the praises of it are the sysadmin equivalent of the software engineer yelling 'it works on my machine' when a user finds an issue.

[–] BCsven@lemmy.ca 11 points 9 hours ago (1 children)

My system has been btrfs since 2017. No issues. Maybe you have random powerloss?

[–] dwt@feddit.org 4 points 4 hours ago (1 children)

You know, protecting against Powerloss was the major feature of filesystems in a time gone by…

[–] BCsven@lemmy.ca 1 points 28 minutes ago

Yep, this entry explains about btrfs zfs and powerloss reovery, but that buggy hardware could mess with that system. https://unix.stackexchange.com/questions/340947/does-btrfs-guarantee-data-consistency-on-power-outages#520063

[–] Endymion_Mallorn@kbin.melroy.org 7 points 11 hours ago

This is just telling me that my loyalty to FAT(32) is valid.

[–] zarkanian@sh.itjust.works 11 points 15 hours ago (1 children)

Have you tested your RAM?

[–] bunitor@lemmy.eco.br 1 points 12 hours ago (2 children)

not sure what the relation would be. my ram is fine afaik

[–] zarkanian@sh.itjust.works 2 points 6 hours ago

Run memtest86+. I had similar issues and it was due to faulty RAM.

[–] WalnutLum@lemmy.ml 11 points 11 hours ago

Typically when there are "can't mount" issues with btrfs it's cause the write log got corrupted, and memory errors are usually the cause.

BTRFS needs a clean write log to guarantee the state of the blocks to put the filesystem overlay on top of, so if it's corrupted btrfs usually chooses to not mount until you do some manual remediations.

If the data verification stuff seems more of a pain in the ass than it's worth you can turn most of those features off with mount options.

[–] jaypatelani@lemmy.ml 3 points 12 hours ago (1 children)

Get on FreeBSD + ZFS

[–] Mwa@lemm.ee 1 points 7 hours ago

You can use Linux with zfs if you install open zfs.

[–] dingdongitsabear@lemmy.ml 34 points 21 hours ago (1 children)

I realize this is a rant but you coulda included hardware details.

I'm gonna contrast your experience with about 300 or so installs I did in the last couple of years, all on btrfs, 90% fedora, 9% ubuntu and the rest debian and mint and other stragglers, nothing but the cheapest and trashiest SSDs money can buy, the users are predominantly linux illiterate. I also run all my stuff (5 workstations and laptops) exclusively on btrfs and have so for 5+ years. not one of those manifested anything close to what you're describing.

so I hope the people that get your recommendations also take into consideration your sample size.

[–] WalnutLum@lemmy.ml 7 points 11 hours ago* (last edited 11 hours ago)

I run btrfs on every hard drive that my Linux boxes use and there's the occasional hiccup but I've never run into anything "unrecoverable."

I will say that compared to extfs, where the files will just eat shit if there's a write corruption, because btrfs tries to baby the data I think there appear to be more "filesystem" issues.

[–] fmstrat@lemmy.nowsci.com 3 points 13 hours ago (1 children)

Won't say it.. Won't say it.. ZFS!! Oops.

[–] bunitor@lemmy.eco.br 1 points 12 hours ago (1 children)

i've been meaning to try it, but i installed freebsd to an ufs partition instead of zfs because ufs was marked by default in the installer 🤦

[–] fmstrat@lemmy.nowsci.com 1 points 12 hours ago* (last edited 12 hours ago)

It's fantastic, IMO. Still use LUKS and software raid for root, but everything else is encrypted raidz.

[–] WalnutLum@lemmy.ml 9 points 16 hours ago

I've had btrfs go into an error state because of a bad write before, but it was pretty easy to recover from

[–] Atemu@lemmy.ml 19 points 22 hours ago (2 children)

could be due to some bad block or read failure from the hdd (it is supposedly brand new, but i guess it could be busted)

I'd suspect the controller or cable first.

shit like this never happens to me on extfs, even if the hdd is literally dying

You say that as if it's a good thing. If you HDD is "literally dying", you want the filesystem to fail safe to make you (and applications) aware and not continue as if nothing happened. extfs doesn't fail here because it cannot even detect that something is wrong.

btrfs has its own share of bugs but, in theory, this is actually a feature.

i have an ext4 and an ufs partition in the same hdd without any issues.

Not any issue that you know of. For all extfs (and, by extension, you) knows, the disk/cable/controller/whatever could have mangled your most precious files and it would be none the wiser; happily passing mangled data to applications.

You have backups of course (right?), so that's not an issue you might say but if the filesystem isn't integer, that can permeate to your backups because the backup tool reading those files is none the wiser too; it relies on the filesystem to return the correct data. If you don't manually verify each and every file on a higher level (e.g. manual inspection or hashing) and prune old backups, this has potential for actual data loss.

If your hardware isn't handling the storage of data as it should, you want to know.

even if we suppose this is the hardware's fault and not btrfs's, should a file system be a little bit more resilient than that? at this rate, i feel like a cosmic ray could set off a btrfs corruption.

While the behaviour upon encountering an issue is in theory correct, btrfs is quite fragile. Hardware issues shouldn't happen but when they happen, you're quite doomed because btrfs doesn't have the option to continue despite the integrity of a part of it being compromised.
btrfs-restore disables btrfs' integrity; emulating extfs's failure mode but it's only for extracting files from the raw disks, not for continuing to use it as a filesystem.

I don't know enough about btrfs to know whether this is feasible but perhaps it could be made a bit more log-structured such that old data is overwritten first which would allow you to simply roll back the filesystem state to a wide range of previous generations, of which some are hopefully not corrupted. You'd then discard the newer generations which would allow you to keep using the filesystem.
You'd risk losing data that was written since that generation of course but that's often a much lesser evil. This isn't applicable to all kinds of corruption because older generations can become corrupted retroactively of course but at least a good amount of them I suspect.

[–] pupbiru@aussie.zone 3 points 13 hours ago

I don't know enough about btrfs to know whether this is feasible but perhaps it could be made a bit more log-structured such that old data is overwritten first which would allow you to simply roll back the filesystem state to a wide range of previous generations, of which some are hopefully not corrupted. You'd then discard the newer generations which would allow you to keep using the filesystem.

i’m not sure i understand quite what you’re suggesting, but BTRFD is a copy on write filesystem

so when you write a block, you’re not writing over the old data: you’re writing to empty space, and then BTRFS is marking the old space as unused - or in the case of snapshots, marking it to be kept as old data

[–] data1701d@startrek.website 6 points 18 hours ago

Sad to hear. I don’t know if it’s luck or something else.

I’ve been running Debian on btrfs on my laptop for 3 months without issue; I still use ext4 on my desktop, as I just went with defaults when I installed the operating system.

[–] bad_news@lemmy.billiam.net 1 points 22 hours ago

I've had some issues with btrfs. I have a Fedora 41 box where the 1TB drive just magically lost 300+GB of capacity that shows up in use but there is nothing using it, and I used to have a 39/40 box where booting would take like 3+ mins that was all btrfs being unhappy with the primary drive on initial mount. Snapshots and the duplicate stuff are pretty killer features, though...