On Wed, May 26, 2021 at 5:30 AM Peter Boy <pboy@xxxxxxxxxxxxx> wrote: > > Am 26.05.2021 um 08:51 schrieb Chris Murphy <lists@xxxxxxxxxxxxxxxxx>: > > What controversial discussion is being referenced? Currently before us > > is a proposal to switch to Btrfs for Cloud edition. > > I’m quite sure you know that discussion. Part to it was Red Hat’s decision to drop BTRFS in RHEL 8 (to my dismay, by the way, because I used it for some file systems on our servers). And because there is that decision and that discussion, I expect it will take a longer time to switch e.g. server to BTRFS as system wide default. So my casual 10-year forecast is not an overreaction as Neal put it (at most some pessimism). I understand you think it will take longer. What I don't understand is why you think this, but I guess we can just skip over that. But let's keep the Red Hat aspect of the storyline in context though. And not extrapolate beyond the available facts. https://news.ycombinator.com/item?id=14907771 Whereupon Server SIG/WG perform an evaluation of Btrfs for their use cases, and decide Btrfs should be the default in a compelling manner, FESCo will approve it. And this plausibly could still happen for Fedora 35, if folks really want it to happen. But I think it's neither urgent nor requires a long delay. Server SIG can do anything they want. Red Hat is doing the same. > I think we have a misunderstanding here. My argument refers to expected hurdles of a possible changeover process, not to technical features. My opinion is to not worry about the process in advance of arriving at the hurdle. You jump over the hurdle at the proper time. The vast majority of the process is about technical features liabilities. For example, I expect Server folks probably prefer LVM LV's for backing virtual machines, rather than raw or qcow2 no matter the file system. Even if this can be approximated by fallocate (raw and qcow2 support it, as as well as ext4, xfs, btrfs) to preallocate the backing file, it's likely a lot of Server folks will just prefer using LVM for this case. That's fine. A good question is to what degree can Server edition, via Anaconda kickstart, divvy up a drive in boolean fashion? I know there's some thresholds like, if the drive is below a certain size, don't create /home, and so on. Could Server default installations default to a ~20G Btrfs system volume; and either leave the rest unallocated (not partitioned)? Or make all remaining space an LVM PV, added to a single VG? And then just not create any LVs? I think I'd like to see each: unallocated, PV only, PV + VG, in Cockpit's UI and get some feedback from those folks because it'd be ideal if the overview of the initially installed system can clearly show the layout, whatever it is. Not often but sometimes folks ask "where has all the space gone?" following a Server installation. They're not expecting or maybe not discovering, that quite a lot is held in reserve in the VG. > Again, it’s not about technical properties. We have (or probably had?) an agreement to align (or try to align) Server Edition and Cloud. That was 2 or 3 months ago. Regarding to that agreement, it is a step into the wrong direction. Is there a Server or Cloud meeting with minutes that this discussion happened in? Or email thread you can point to? -- Chris Murphy _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
