I worked for SUSE from 2017 to 2021. Because of that, I ran openSUSE on my work computer. Btrfs self-destructed on me, on 3 different PCs, about twice a year in that 4-year period.
Not myth. Not from t'Internet. Direct personal experience.
Btrfs `df` lies. You, and programs, can't get an accurate estimate of free space. OS snapshots fill the volume, volume corrupts, new install time. Over and over again.
I do not trust Btrfs and since the Btrfs zealots are in denial and will not confront the very real problems, I don't think it will ever get fixed.
Yah well. Do some housekeeping then? I mean if the Distro delivers automagically snapshotting in intervals, during installation of packages, or whatever they fancy?
It's not like you'd need those for all eternity. By housekeeping I meant deleting them from time to time, with easily clickable tools, which exist(now/meanwhile), and DO give an overview. Maybe have to 'rebalance' afterwards, which can go wrong if the 'housekeeping' was too late, or something. OTOH the 'rebalancing' can be automated, from the beginning.
I'm sure similar haphazards (regarding common tools like df/du not being able to give an exact overview of remaining capacity) exist under ZFS, at least when your'e using compression.
> One of those filesystems is likely more stable than the other, but the image of perfect zfs is tiring.
I didn't say perfect, I just said, querying for FS to use, everyone recommends ZFS, over Btrfs. Even if not perfect, it seems to have left a better impression than Btrfs.
I've had btrfs loose my laptops root filesystem, it just wouldn't mount anymore for no apparent reason. This was ~6 or 7 years ago. Reading the fs with some rescue command worked fine, the ssd continued to work for a few more years after formatting.
I've also had a weird situation after that where a micro SD formatted with btrfs on my desktop PC wouldn't mount on a raspberry pi, and vice-versa the same micro SD formatted on the pi wouldn't mount on the desktop. This was apparently caused by a difference in the used block sizes, which were mutually incompatible.
So I'll quote myself on this.
But also, my server is running a btrfs raid 1 due to the flexibility for resizing and that has been just fine for a few years now. It's not black and white and with backups I am not really worried.
fill your btrfs with "dd if=/dev/urandom of=./testfile" as a normal user then "rm ./testfile && sync" then reboot. 6 month ago i could brick btrfs with that "trick".
I have a broken (parent transid verify failed on logical) btrfs RAID5 here that I can't mount anymore even with the recovery commands and google shows many results about it from less than a decade ago.
lproven|1 year ago
I worked for SUSE from 2017 to 2021. Because of that, I ran openSUSE on my work computer. Btrfs self-destructed on me, on 3 different PCs, about twice a year in that 4-year period.
Not myth. Not from t'Internet. Direct personal experience.
Btrfs `df` lies. You, and programs, can't get an accurate estimate of free space. OS snapshots fill the volume, volume corrupts, new install time. Over and over again.
I do not trust Btrfs and since the Btrfs zealots are in denial and will not confront the very real problems, I don't think it will ever get fixed.
LargoLasskhyfv|1 year ago
It's not like you'd need those for all eternity. By housekeeping I meant deleting them from time to time, with easily clickable tools, which exist(now/meanwhile), and DO give an overview. Maybe have to 'rebalance' afterwards, which can go wrong if the 'housekeeping' was too late, or something. OTOH the 'rebalancing' can be automated, from the beginning.
I'm sure similar haphazards (regarding common tools like df/du not being able to give an exact overview of remaining capacity) exist under ZFS, at least when your'e using compression.
viraptor|1 year ago
Ygg2|1 year ago
I didn't say perfect, I just said, querying for FS to use, everyone recommends ZFS, over Btrfs. Even if not perfect, it seems to have left a better impression than Btrfs.
matrss|1 year ago
I've also had a weird situation after that where a micro SD formatted with btrfs on my desktop PC wouldn't mount on a raspberry pi, and vice-versa the same micro SD formatted on the pi wouldn't mount on the desktop. This was apparently caused by a difference in the used block sizes, which were mutually incompatible.
So I'll quote myself on this.
But also, my server is running a btrfs raid 1 due to the flexibility for resizing and that has been just fine for a few years now. It's not black and white and with backups I am not really worried.
BSDobelix|1 year ago
bauruine|1 year ago