On Tue, Jun 30, 2020 at 10:30 AM Antti <antti.aspi...@gmail.com> wrote: > > > Another way to consider this would be that we can stop arguing against these > > changes, let the GNOME folks run the ship aground, and hope that the user > > backlash will act as a wakeup call when it comes to these changes. I agree > > that btrfs is far too unstable to be made a default, and I also agree that > > ZFS > > would be a much better option. However, there is always going to be pushback > > on ZFS. If you want the best, there's a price to pay, and that's licensing > > headaches in this case. > > I understand you but I'd like to help btrfs guys to get their stuff working. > And for two days now I've tried to write a reasonable honest truthful reply > for their questions backed by facts and confirmed data unable to come up with > concise answers. After following this topic it became clear to me that I'm > not sufficiently prepared to give a proper technical presentation of my > issues or to have an in-depth discussion of btrfs while they are very well > prepared to defend their position. This is happening so suddenly too. I > didn't expect Fedora to start considering this at all because Red Hat isn't > at least publicly discussing it. I'd also like to avoid writing massive dozen > page emails about my personal issues with btrfs when the central question > here is if btrfs is good enough for majority of Fedora's user base. It could > be even if it isn't ready for my use. > > 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. >
There will likely be significant improvement with openSUSE Leap 15.2, as the kernel has been rebased from 4.12 to 5.4. With that rebase, virtually all the stabilization work done upstream that hasn't already been backported to the SUSE Linux Enterprise 15 kernel will be included. That said, as one of the change owners, I *want* to know about your issues. I want to be able to solve them. We have an upstream Btrfs developer who wants to resolve issues people discover, and the only way we can is if we know about them and get details to pin them down and fix them. It's how this goes with any piece of software, really. I've been using it for five years on desktops, VMs, and servers with no issues for at least the last three. But I am not so blind as to say that Btrfs is perfect. But there's nothing I can do about things I don't know about, and that's true for anything in open source. You should feel free to file bug reports so that we can address them. > 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. > > Like I explained in another message, btrfs to me is highly visible file > system and a source of stress as I have to eventually babysit it which to me > proves it is unstable and not production ready. And this variation in how > btrfs is experienced by different people is perhaps just another sign of it > not being production ready yet even if huge progress has been made recent > times. That is a good reason not to make it the default choice in Fedora. > > Yesterday I went through my past emails where I discuss btrfs with my > colleagues. It was some years ago but I had a similar freezing issues back > then as well as I had in 2019 and when asked about it btrfs supporters > explained to me that my particular workload which involves collection of > hundreds if not up to a thousand small C, Ruby, Python, PHP and C# files, > hundred GBs of image data split into maybe approximately 1MB files, and a two > large local databases is "poison to btrfs" to quote a friend of mine. I'm sorry that you feel that way. For what it's worth, my personal workload is very similar to yours. While it is true that databases are normally "poison", I've worked around it by using "nodatacow" for those portions, and in the further past, I used to split that out as an XFS partition. At least for the last couple of years, I've had a pretty good time with doing things like package builds, compilation, and such. However, I want it to be that we move towards making these kinds of "correct" decisions being made automatically without you having to think about it. For example, when you run the pgsql or mysql database init script we ship, it should probably set nodatacow for the folder if it's detected to be on btrfs. Nothing about this is me wanting to make it a burden to use Fedora because of Btrfs. I want to use Btrfs to open doors to all kinds of interesting possibilities to make Fedora a first-class integrated desktop Linux experience that competes on the same footing as macOS and Windows. > It was recommended that I run JFS instead which I've yet to touch but now > that I have time I should try it as well as other available options. I'm > highly interested of testing nilfs and bcachefs right now. > Well, huh, I've not heard of a recommendation about JFS in a long time. For heavy I/O database workloads, I suggest XFS, though Btrfs can be made to work quite well for database workloads with stuff like nodatacow as I mentioned earlier. NILFS (and NILFS2) are not usable on Fedora due to lack of SELinux xattr support, last I checked. BCacheFS is not in the mainline kernel and there doesn't appear to be much progress on a path to the kind of stability you seek, as the project still says that it is unstable and there doesn't seem to be a roadmap to get out of that state right now. > Furthermore even if Fedora were to set the btrfs as a default, I wouldn't use > it in my main PCs since btrfs doesn't enjoy my trust at all right now. > However I would stop recommending Fedora to my friends and family because > doing a custom partitioning in Anaconda using another file system is way too > complex and difficult task to perform. It's much easier to just recommend > Ubuntu or openSUSE where the partitioning using alternative file system is > much much easier and clear cut operation to do. > > 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. > It is actually quite easy to choose an alternative configuration if you want. When you go through Anaconda installation and go to storage, you can choose "Custom", and from there you have a drop-down list of partitioning schemes: plain, LVM, LVM-thin, and Btrfs. You can select any of those and have Anaconda do a default setup based on that. The current default is "LVM", and we're changing the default to "Btrfs". But it's straightforward to make this change yourself at install time. In my experience, YaST is actually pretty hard to use to switch to alternative configurations, so I'm surprised you say that it's difficult in Anaconda but not in YaST. > The zfs in my opinion isn't a perfect choice neither technologically or > legally. However it is the best thing out there for people who want an usable > production-ready advanced file system right now. The issues with zfs to me > present themselves as easier to solve than the problems with btrfs. But I'm > not a legal expert and it really is a shame that the licensing is an issue > with zfs. It's a very good file system and it didn't need to be forcefully > pushed to become a success story. This is opposite to btrfs since its > proponents constantly seem to want forcibly push it to people who don't want > it. That combined with its continued technical issues have turned my initial > positive enthusiasm towards btrfs into a very deep skepticism of it and its > promised capabilities. > I want to address this point specifically from the context of usability as you brought it up for btrfs. Both btrfs and zfs require the same kind of hand-holding in various configurations. When using complex storage configurations (multi-disk, raid, etc.), you do need to regularly do scrubs to verify that everything stays sane. A scrub is what lets you validate that you haven't suffered issues across the disk boundaries. Now, in "simple" setups, you can typically avoid needing to do this. With what we're trying to do here, Btrfs should be transparent to the user. That being said, documentation is something we are working on as the Change owners. I do not want people to feel helpless with this filesystem. > I wouldn't count for there being a backlash. Usually Fedora users are very > open to changes and used to living "near edge". If it is already been decided > to make the btrfs the default and this is merely a formality then I'm hoping > for the best case that they know what they're doing and that btrfs' very > latest version is usable for long periods of time and works through several > upgrade cycles without reformat even if last year it wasn't yet on openSUSE > Leap 15.1 release for myself. > This Change process exists precisely because so we can learn from the community to make our proposal better, or if it turns out to be unworkable, postpone or withdraw it. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
