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. It's a 100% fail. But if it's a media defect, torn or misdirected write, it's quite different. Btrfs is the only linux filesystem that has a chance of surviving such cases while remaining in normal operation. That's because by default on hard drives, it keeps two copies of file system metadata in different locations on the drive, and can self-heal so long as there's one good copy of a block. If the problem results in corruption of data, only Btrfs checksums data, so it unambiguously knows if the data lacks integrity, and will refuse to propagate corrupt data to user space. In the case of SSDs and virtual block device backed by multiple physical drives, duplicate metadata may not help anyway. But since data is by far the biggest portion of a file system volume other than free space, it's a much bigger target for any problems that occur with the storage stack. Btrfs is the best early detection system for such problems, which can only get worse. Early detection is the benefit. Btrfs is like a canary in a coal mine, even if it can't self-heal or stop the impending doom. What are the potential risks you are concerned about in the cloud and server use cases? Please be specific. > > > The net effect of the subvolume setup is that people who had > > individual user data on the OS volume could now cleanly isolate that > > from the rest of the data on the OS volume without worrying about > > space contention. > > 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. There isn't a proposal for Btrfs for Server edition, nor is there a proposal to use LVM in Cloud edition. So I'm kinda confused about what you want to discuss. If the case for Btrfs for Cloud isn't strong enough in the proposal; it's most helpful if you could directly criticize what's wrong, missing, or unpersuasive about it. > >> That’s fine for me. Practically, this means putting that plan on hold for the next 10 or so Fedora releases. > >> > > > > Why would we wait 5 years? That seems like a weird overreaction here. > > No overreaction, just a little sense of reality. I see a lot of concerns about stability and reliability of BTRFS and a widespread reluctance to move servers to it. In any case, nothing in the near future. Could you point out some of these real concerns about stability and reliability of Btrfs? Btrfs isn't perfect, but I'm very frequently the person of first contact in Fedora for Btrfs issues, and we're really not seeing many problems even when including problems resulting from hardware defects like bad RAM and drive firmware dropping writes. And all of the reported problems get a followup. I'm not sure what qualifies as widespread reluctance, or what the metric is. However, I am absolutely confident that if you are asserting Fedora should avoid technology that no one else is using, the community should push back on such a misapplication of logic. > 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? -- 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
