uCore default File system

uCore
1

I recently installed uCore OS and noticed that the system defaults to an XFS file system for installation. So my questions:

  • Why XFS and not BTRFS like Bazzite and BlueFin?
  • Does this have any effect on the snapshot and rollback functionality compared to the other immutable systems?
  • If this does affect the system’s ability to handle snapshotting, is there a way to change the default file system?
2

XFS is the default for rhel/centOS/fedora IoT/fedora server.

It’s very suited for running workloads that are common on servers.

XFS does not support file system snapshots. However, this is separate from rollbacks offered by ostree/bootc.

You can change the default partitioning via your ignition file but I would recommend against it.

2 Likes
3

Thanks for the explanation. So, it’s like Git on top of a normal server-grade file system.

4

I’m also baffled as to why, in this day of age!, XFS is still used instead of BTRFS. Even on a single disk (SSD, etc.) systems, the features and advantages of BTRFS over all others is unquestionable. Like automatic end-to-end data checksum and re-allocation if errors, transparent data compression, no BITROT possible as in other file systems. Hopefully this will change in the near future.

5

btrfs does significantly more than XFS.

That said, XFS is still better in several workloads even when used under lvm. Ext4 still has a place as well.

6

I think this sums it up, with a better picture of overall benefits.
I hope devs take this into consideration, as stability and data integrity is more important than a little more speed.

image
image762×426 31 KB

1 Like
7

Notably missing from this table are actual workloads and features that Btrfs doesn’t support (fscrypt).

For actual workloads there are significant tradeoffs for using Btrfs on write heavy workloads such as VMs and Databases. This is severe enough that COW is often disabled for directories hosting these.

On your desktop, I agree that Btrfs is a good balance of most features and performance. But on a server, these decisions matter significantly more.

Additionally, with ostree for your rootfs, you get some of the key features (namely rollback) and when composefs backend is ready we will also have fs integrity.

And in that case for the actual variable data, we can choose whichever filesystem makes most sense for the workload at hand.

4 Likes
8

Thanks for the feedback. But I’ll never trade speed and other features for data integrity and data security, specifically end to end checksumed data, bitrot protection and filesystem self healing (auto sector reallocation, etc.) And that, XFS or EXT4 never have a chance against BTRFS. And specially for embedded systems, where the ideal combination is, as we now have, immutable filesystems and that coupled with the features I mention is the perfect system even for servers. No wonder OpenSUSE, Fedora, Bluefin, Bazzite, Aurora and many others have adopted BTRFS as the default file system. XFS and EXT4 might be much faster on some operations than BTRFS. And still, I’ve seen crash nightmares with XFS (total data loss) and less common with EXT4, but it happens. On a single disk BTRFS, havent’ seen that problem since about 10 years ago, when I did experience a total data loss on BTRFS. That has been long corrected and I haven’t seen any problems with BTRFS on either RAID 1, 2, RAID1C or RAID2C, the later which I use on my NAS for extremely data redundancy and protection. But that is an overkill for small embedded systems, unless it’s for a server and there is where BTRFS (RAID1C or RAID2C) really shine on a huge array of multiple disks.