Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 25, 2021 at 5:05 PM Peter Boy <pboy@xxxxxxxxxxxxx> wrote:
>
>
> > Am 25.05.2021 um 21:56 schrieb Neal Gompa <ngompa13@xxxxxxxxx>:
> >
> > On Tue, May 25, 2021 at 3:52 PM Peter Boy <pboy@xxxxxxxxxxxxx> wrote:
> >>
> >>
> >> Am 25.05.2021 um 19:03 schrieb Ben Cotton <bcotton@xxxxxxxxxx>:
> >>
> >> 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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux