> I can only offer descriptions of symptoms of trouble from the web back-end developer / > desktop end-user PoW which starts to appear in personal computers where I have used or > currently do use btrfs if not full-time. I made a long list of these yesterday and only > some of them can be linked to existing known issues which are yet to be fixed so I > didn't send that list to Chris Murphy and Stasiek Michalski yet and might not do so. > Not publicly at least. Some of the issues have been fixed but not yet present in openSUSE > Leap 15.1 where I previously experienced just how broken btrfs can be at its worst and I > don't have that particular setup right now to even test if these changes would aid me > in upcoming openSUSE Leap 15.2 release. I just have to let my head cool down before trying > btrfs full-time again in a year or two. Leap 15.2 might be a good choice in this case, since it will suffer that mid-life kernel rebase of Leap 15. You kinda got me, because despite technically being a Leap developer, I don't use it, because I don't have any use for it anywhere outside of the parts I contribute to. My experience with Leap might therefore be limited. Whatever isn't being posted on Reddit, Bugzilla, Discord or Matrix about btrfs on Leap I am going to miss, because my entire experience of btrfs has been through interacting with Tumbleweed and derivatives (Kubic, MicroOS). Considering the schedule at which Fedora and Tumbleweed upgrade the kernels is closer, this should actually be a more fair comparison though. > Furthermore some of the things the proponents of this change have written just throw me > back into my chair because after all I've gone through with btrfs and after all the > lost time I could have spent better producing code, I know what they're writing is > simply not true. Or not true in my case and I have major disbelief regarding for example > there being no need to run btrfs balance when on my ThinkPad T430 I know for a fact that > btrfs constantly will start running out of disk space and the solutions to it only > temporarily solve it through regular use of btrfs balance, disabling snapshots which tend > to get corrupted anyway and fine tuning the file system. But then again I don't think > they're lying and I don't want to accuse them of that. There are visibly big gaps > in how btrfs is experienced by different people in different working environments on > different hardware. Based on what I've read lately, btrfs seems to work at really big > scales very well. Where it fails to work are smaller > individual setups and small businesses. This makes it a controversial file system. Snapshots aren't a part of this proposal, and frankly they do require a little bit more UX work, since they tend to cause people to run out of space too, because we don't cap that well enough. You can make snapshots work in a way that won't annoy you, because there are ways to set them up correctly, but for that you shouldn't rely on openSUSE distros defaults in that regard. Also I doubt openSUSE distros are used on big scale very often, I can think of very few examples, but they certainly don't match the sheer amount of users we have on various communication channels otherwise. > If it was easy to choose e.g. plain lvm+ext4 or Stratis lvm+xfs instead of btrfs during > Fedora installation like it is in openSUSE I probably wouldn't be in total opposition > to this proposal. I still would be against it but I wouldn't be here writing these > messages about this issue and expressing my opposition to this proposal. And it would have > to be fixed first before making btrfs the default file system. Which openSUSE do you mean, our custom partitioning is a nightmare, to the point that even YaST developers started to want to make it easier recently. LCP [Stasiek] https://lcp.world _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
