Red Hat Enterprise Linux 8 Beta Released With Stratis, Yum 4, Application Streams

[Anvil]

Why are they using yum instead of dnf?

DNF is the NEXT GEN YUM alla yum-4 , it'll be the same in Fedora30 you'll say do a
sudo yum install blah blah
but you'll be using DNF as a backend . YUM will be symlinked to DNF

in other words, YUM will be Powered by DNF

[lindgrenj6]

Kernel 4.18, sytemd239 - this looks like they "just" copied Fedora 29 repo.

That's exactly how it works. Fedora is the upstream for RHEL.

[mskarbek]

That's exactly how it works. Fedora is the upstream for RHEL.

I know that perfectly well but this time they did something different.
RHEL 6 - November 2010 was based on Fedora 12 - November 2009
RHEL 7 - June 2014 was based on Fedora 19 - July 2013

In RHEL 8, from what I can tell based on available repo they used a mix of mostly Fedora 28 (half a year old) with packages (like systemd) from 29 which is like few weeks old. With older releases, they tended even to chose packages from older then the base Fedora releases, not the latest available.

[dwagner]

It seems like Stratis is a nothingburger, anyone can just throw an XFS filesystem on top of an LVM.

Yes. I'm using both XFS-on-top-of-LVM and btrfs at work, both have their place, but "Stratis" promises just nothing in addition. Ceph is certainly a different beast, trying to tackle the challenges of a distributed filesystem. It may already be the best of such, but if you don't strictly need a distributed FS, then Ceph is just slower, more complex and much less convenient.

[okapi]

Stratis is a big step back from the next generation filesystem we could have with forward looking designs, either btrfs or moving toward Cephfs has a general purpose filesystem even. Stratis is a 1980s filesystem on top of a 1980s block layer.

Have you even tried stratis? It isn't a filesystem itself but a layer on top. Something like firewalld is to iptables. It isn't even tied to XFS/LVM. The command-line interface feels cleaner and more well designed than the mess that btrfs exposes and if you need a programmatic interface, it fills a gap that even ZFS doesn't do well.

XFS is a rock solid filesystem and in the medium term is a good choice. With data-only CoW, it is gaining some of the newer advanced features. Redhat invested in btrfs for some time and I don't imagine they took the decision to drop it lightly. Given how long it has taken without btrfs becoming properly stable, I suspect there might be some fairly broken early design decisions. I'd have preferred to see them take the Ubuntu route with ZFS. But given the legal rather than technical problems with that I'll put my hopes for the future in something else like bcachefs.

As it is, I've been happily using ZFS on RHEL 7 and at work we've decided to start using it for more of the important systems.

[garegin]

The volume manager in modern filesystems is filesystem aware. You can’t do that with layering like LVM.

[re:fi.64]

Red Hat isn't uses BTRFS because a) they currently have very few BTRFS experts employed, and b) BTRFS's codebase is a disastrous mess. LVM is great but can be rather finnicky at times. Stratis is promising something built for XFS that will serve until we get a stable modern FS for Linux, which is probably going to take quite a while.

[gilboa]

The volume manager in modern filesystems is filesystem aware. You can’t do that with layering like LVM.

In my experience RedHat spends a lot of time gathering input from their (many) customers.
I would imagine that the decision to build modern management layer on top of stable LVM and XFS wasn't taken lightly (as opposed to using btrfs).

- Gilboa

[oiaohm]

The volume manager in modern filesystems is filesystem aware. You can’t do that with layering like LVM.

This is a mistake. XFs/XLV combination use to do it. This combination is a historic and is really the first with volume manager and file system working with each other.

When XFS was brought to Linux XLV was not brought along with it. Yes XLV was a file system integrated volume manager. XLV unlike the btrfs and zfs integrated volume managers XLV can operate as a stand alone volume manager and as a generic shared between multi different file systems.

Layering like LVM runs into problems due to a limited API. This is the block device API in the Linux kernel not providing file systems with information to query the block devices under them completely or provide highly useful directives to raid by the block device API. Highly useful directive would be if a file system could say this group blocks should go on a single device to the block device.

Basically if LVM and DMRAID is made not a black box to the file systems other ways of implementing file system volume manager comes possible without the file system implementing its own individual volume manager.

One thing you really don't want to-do is Volume management on Volume management if you can avoid it.

https://lwn.net/Articles/747633/

This mentions some of the alterations. Basically if the block device API grows a decent space-management API then LVM and DMRAID implement it there will really not be a need for file system to implement their own volume management.

Yes this article raises the question should file system mandate direct block device usage. ZFS and Btrfs having own internal volume management is not that effective when you want to access a image of file system.

There is the possibility that ZFS and Btrfs are going completely down the wrong path with volume management.