On Tue, May 25, 2021 at 5:05 PM Peter Boy <p...@uni-bremen.de> wrote: > > > > Am 25.05.2021 um 21:56 schrieb Neal Gompa <ngomp...@gmail.com>: > > > > On Tue, May 25, 2021 at 3:52 PM Peter Boy <p...@uni-bremen.de> wrote: > >> > >> > >> Am 25.05.2021 um 19:03 schrieb Ben Cotton <bcot...@redhat.com>: > >> > >> https://fedoraproject.org/wiki/Changes/FedoraCloudBtrfsByDefault > >> > >> This includes the same subvolume layout that is used on the desktop > >> variants [[Changes/BtrfsByDefault|as introduced in Fedora Linux 33]], > >> as well as transparent Zstd compression > >> [[Changes/BtrfsTransparentCompression|as introduced in Fedora Linux > >> 34]]. > >> > >> > >> > >> Wonder why a cloud image would just have a special affinity for a desktop > >> system. Who runs their desktop in the cloud? > >> > >> And there is a reason why the partition layout of server and desktop > >> differs. > >> > >> > > > > The partition layout differed specifically to maximize available > > space. > > As to my knowledge it’s not about space (there is no difference in this > respect), it's about strikt separation of system and user data, containment > in the event of a file system failure, and opportunities and simplification > of recovery. >
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. > ... > > So the same model works totally fine for both desktop and > > server. > > I myself lack the exact technical knowledge, but (all?) server and file > system experts I hear consider just that a gross misconception. > > In the cloud use-case, it is relatively rare for important data to be on the OS partition. Either a secondary volume is attached and formatted, or people are using some kind of distributed storage (such as Ceph, Gluster, S3, etc.). 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. > >> == Release Notes == > >> > >> The default file system on the cloud is now Btrfs, following the > >> desktop change in Fedora Linux 33. Fedora Server, IoT, and CoreOS are > >> still specifically excluded. > >> > >> > >> It wasn't long ago that the plan was to better align cloud and server. > > > > That's still a goal, but Server Edition has more complex needs to > > address before we could do it there by default. Since the storage > > needs for Cloud Edition are tremendously simpler, we can do it here > > first and iterate on getting things to the point that we could propose > > it for Server Edition. > > 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. We literally talked about how this would go in the last Fedora Server meeting[1] with us agreeing that Fedora Cloud would be a starting point for Btrfs for server use-cases. Starting with the simpler cases (from a storage perspective) is a good way to see how things go. [1]: https://meetbot.fedoraproject.org/teams/fedora-server/fedora-server.2021-05-05-17.00.log.html > For this time, we should come up with something else to easily set up a > Fedora Server VM in Fedora Server as a transitional measure. Maybe the ARM > disk image for SBC's would be a good starting point. This disk image already > offers an almost perfect implementation of the structure and concept of > Fedora Server Edition, at least much closer than the current Cloud Base disk > image. Their composition script might be a good starting point if you leave > off the hardware specific parts. > Fedora Cloud was never set up as a "Fedora Server" lookalike in the first place. That's why it's a distinct Edition. Some examples of differences that are already present: * We used single ext4 instead of xfs+lvm with logical volumes for root and home * Set up with cloud-init instead of standard boot * No cockpit software If you want to do an "easy" Fedora Server as a VM on classical KVM hosts, you're probably better off with using virt-install[2]. Setting up Fedora Cloud images on regular KVM hosts is a pain and not the intended use-case. Working with cloud-init or ignition in classical VM models is painful and probably not what people want to do for that type of setup. [2]: https://www.mankier.com/1/virt-install -- 真実はいつも一つ！/ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
