> 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) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
