Bcachefs Multi-Device Users Should Avoid Linux 6.7: "A Really Horific Bug"

[Quackdoc]

I've been using btrfs for 2 years and it works fine for me

good for you, sadly it seems like unless you have every single person on the exact same machine, different issues can crop up to different people

[andyprough]

As if the "EXPERIMENTAL" markings on every single step of the way were not enough?

You know, the entire point of a "beta" is to conduct wider testing, but at the same time reserve the right to fix things where they need to be fixed, not where it would be most convenient or least breaking.

It's a file system. Shouldn't it at least be expected to do file system things, even in beta? If users wanted a "file deletion system", it seems like they would have used one of those instead.

[partcyborg]

I like bcachefs, but that's pure mental gymnastics. By this measure btrfs, too, never eats your data because btrfs check can almost always recover it :-)

You obviously don't actually use btrfs because that is 100% false. Btrfs check with repair actually CORRUPTS your filesystem in 99.9% of cases, even the docs say don't run it unless a dev tells you it is ok to. I have had numerous single disk btrfs filesystems destroyed by a power event. None were recoverable beyond running btrfs recover and dumping about 30% of the data on the fs to another drive

[intelfx]

You obviously don't actually use btrfs because that is 100% false. Btrfs check with repair actually CORRUPTS your filesystem in 99.9% of cases, even the docs say don't run it unless a dev tells you it is ok to.

That was a typo; I meant to say btrfs restore which is a better analogy for "rebuilding all B-trees by scanning the partition". But no, btrfs check is moderately useful. Perhaps it's you who are not actually using btrfs and instead judging by random internet comments?

[intelfx]

It's a file system. Shouldn't it at least be expected to do file system things, even in beta? If users wanted a "file deletion system", it seems like they would have used one of those instead.

You are being obviously facetious, so I see no point in responding.

[Old Grouch]

Re: Eating your data

I make no distinction between metadata and data. They are both data. Filenames, last modification dates, and the directory structure have meaning for me, so a guarantee that only the contents of files is 'safe' is not worth much to me.

I quite like Apple's approach of having resource forks that hold file metadata. NTFS can do similar stuff with 'alternate data streams'. In general, Linux applications don't use them as much, which is a bit of a pity. I found it convenient that Apple would store the URL where a file was downloaded from in the resource fork of the downloaded file. As a result, my filenames tend to be long, include manual creation dates and version numbers, and have some clues as to where in my directory structure they live.

Organising metadata, and making sure it stays associated with/attached to the data it describes is a hard problem. The concept of the directory structure is good, but not as flexible as people actually want in reality - people want file versioning, file tracking (URL it was downloaded from) and much other rich data, and there's no widely used generic solution.

Data storage (which includes metadata) should be robust and easily fixable.

[mrg666]

I am starting to think nothing more than ext4 is really needed for my personal use. I would rather have the user-space sync utility that does incremental (local or network) backups ... and, RAID 1 if if extra-extra safety is needed.

[Nozo]

You obviously don't actually use btrfs because that is 100% false. Btrfs check with repair actually CORRUPTS your filesystem in 99.9% of cases, even the docs say don't run it unless a dev tells you it is ok to. I have had numerous single disk btrfs filesystems destroyed by a power event. None were recoverable beyond running btrfs recover and dumping about 30% of the data on the fs to another drive

I can confirm that, it happens often on HDDs, also if you have a dying disk basically say goodbye to your files, with XFS and est4 you have the possibility to repair the file system to save some time and backup them. BTRFS is still unstable and unreliable in some use case scenarios at best, that is the reality, meanwhile ZFS continues to be the de facto option in most scenarios and is one of the few aspects in which Linux is behind FreeBSD.

[carewolf]

good for you, sadly it seems like unless you have every single person on the exact same machine, different issues can crop up to different people

Sounds like you either have bad hardware or are doing something that isnt well tested. The latter is the most common issue with developing systems, and the former just because testing for hardware failures is hard, so often recovery doesn't work as well in practice as it should on paper.

I have lost three drives of data to BTRFS, but those were all ~10 years ago. I am still using it today (only for git sources, so nothing can be lost), but haven't had failure in 10 years. *shrug*

[fitzie]

Sounds like you either have bad hardware or are doing something that isnt well tested. The latter is the most common issue with developing systems, and the former just because testing for hardware failures is hard, so often recovery doesn't work as well in practice as it should on paper.

I have lost three drives of data to BTRFS, but those were all ~10 years ago. I am still using it today (only for git sources, so nothing can be lost), but haven't had failure in 10 years. *shrug*

btrfs still occasionally introduces bugs, but I've found the mailing list great for getting developers attention. I even got a reported-by for a bugfix last year. luckily, I always have backups, no filesystem will save your data from a disk that stops working.