And you are taking his quote out of the context, which is in the
message
you quote: the false / unsupported claim of data loss.
That context includes that he trusts Btrfs more than other file
systems, and he's been using Btrfs in production all day long for a
long time now. By all means go ask him yourself what he thinks.
I'm not sure if you understood me correctly since you seem to misunderstand the full
context yourself. The context is explained in the message but allow me to summarize it
here. They're talking about a fictional scenario where inexperienced openSUSE user
"Joe Bloggs" wants to make more room for himself and finds an utility from a
wiki which enables him to do this. The claim is that the use of btrfs-dedupe utility could
potentially lead to data loss for this imagined inexperienced user "Joe". And
Blaxell quite correctly writes that:
Joe Bloggs will not lose any data from btrfs-dedupe. He'll waste
his
time and run out of disk space, and maybe switch filesystems due to
frustration, but Joe will not lose any of his data.
Which I agree with. After that Blaxell also correctly states that:
btrfs-dedupe has not had new commits in years and no longer builds
on
today's Rust. Those facts alone would have been sufficient to justify
removing it from the wiki. We have far too many real data loss bugs in
btrfs already. There is no need to spread rumors about new ones just
to push changes through.
If you carefully read through the whole message, it is obvious that Blaxell indeed does
trust btrfs and probably does use it in production. And I think this is a very good thing.
Developers of product x must have faith in what they're doing and use their own
software.
However the most commendable thing he wrote here is the part where he honestly admits that
they also do have many real data loss bugs in btrfs and wishes that people would not
spread rumors of non-existential ones. I can testify that this is true even if it's
anecdotal and as a developer I also share his wish that people would not spread rumours of
non-existential issues. And I feel that way no matter what project it is.
My point being that there are unresolved major issues in btrfs which should be fixed
before Fedora can even consider making btrfs the default file system. Issues which
aren't present in alternatives to btrfs. I don't "hate" btrfs. I merely
"dislike" it and this stems from my own negative experiences with it from having
used it every now and then probably around since 2009–2010 when it was first introduced to
the kernel and actively every day since 2014.
Best file systems are invisible to end-users. That's also where I've set the bar
for when the file system is "ready for production" in desktop environments. It
is my lowest expectation for a file system. And btrfs still falls short of this after many
years of full corporate support. Yes, it has made huge progress since the early days I
must write. I'm very impressed of some of the things btrfs can do when things work as
intended. Furthermore nowadays I don't have to once a year do a full reformat of my
Sailfish OS device because of btrfs which is absolute relief and concrete example that
progress has been made.
But btrfs is still not invisible. Meaning that when I do use it I actively have to think
about using btrfs-check, btrfs-balance, btrfs-filesystem, etc. every now and then and
cannot just use the system without a worry of something breaking up. And as a person who
likes Fedora, who wants more people using Fedora, I also worry about the user experience
and how btrfs is going to change the life for users if it becomes the default choice.
--
Antti (Hopeakoski)