> Am 26.05.2021 um 08:51 schrieb Chris Murphy <lists@xxxxxxxxxxxxxxxxx>: > > On Tue, May 25, 2021 at 5:52 PM Peter Boy <pboy@xxxxxxxxxxxxx> wrote: >> >> >>> Am 25.05.2021 um 23:20 schrieb Neal Gompa <ngompa13@xxxxxxxxx>: >>> Cloud images never had such separation. It was always one big ext4 >>> partition. With Btrfs, we can introduce subvolumes so user data can be >>> trivially managed separately without losing the benefits of a single >>> pool of storage. >> >> That’s the difference: As a server sysadmin I would rather consider potential risks of a single pool of storage. :-) > > OK, let's consider 2-3 potential risks. > > Hard drive mechanical failure (spindle, motor, actuator, rw head), no > matter what file system and partitioning you use, you are out of luck. > ... > > What are the potential risks you are concerned about in the cloud and > server use cases? Please be specific. That sounds very promising. But I wanted to emphasize something else: The criteria and the point of view are different. For logical reasons, an argument from one context has no assertiveness in the other context. The same detail is evaluated differently in a different context. >> What I get from the controversial discussion about BTRFS is that there is doubt about how really clean that "cleanly isolate" is, at least compared to LVM. But if important data is (supposed to be) on additional external storage, that's perfect. > > 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 think we have a misunderstanding here. My argument refers to expected hurdles of a possible changeover process, not to technical features. >> Regarding that idea, the switch to BTRFS tends to be a step in the wrong direction. > > Cloud and Server editions have had different file system and > partitioning strategies since day 1. Today is the first I've heard > that there should be, could be, would be, some kind of realignment > where Cloud uses LVM or Server uses ext4, or some other combination. > But you are now asserting that this alignment should happen? And are > you asserting that this is a central question needing an answer as a > prerequisite for evaluating this Fedora 35 change proposal? 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. But maybe in the meantime we had another trend coming up. Neal came up with some arguments about a general difference between both so an alignment is seen as not possible or not useful. I’m not a stakeholder for any decision about that. And I have no intention of missionizing for any of the options. I’m just the bookkeeper and try to ensure that nothing is forgotten and everything follows a solid and consistent logic. And because I am not a native English speaker, some wording may be misleading, much to my chagrin. So we may drop it from the table. I’ve put it on the agenda of todays Server IRC meeting. Best Peter _______________________________________________ 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
