> Am 26.05.2021 um 08:51 schrieb Chris Murphy <li...@colorremedies.com>:
> 
> On Tue, May 25, 2021 at 5:52 PM Peter Boy <p...@uni-bremen.de> wrote:
>> 
>> 
>>> Am 25.05.2021 um 23:20 schrieb Neal Gompa <ngomp...@gmail.com>:
>>> 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@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to