> 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

> 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

LCP [Stasiek]
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to