Fedora 37 Looks To Ship With Stratis Storage 3.1 Support

[phoronix]

Phoronix: Fedora 37 Looks To Ship With Stratis Storage 3.1 Support

While many Red Hat open-source projects end up being relatively instant successes that then end up being widely adopted in the open-source community, Red Hat's Stratis Storage effort seems to be trending as one of the exceptions. Red Hat continues investing in Stratis but it doesn't seem to have the sizable adoption or widespread interest that tends to come with most of their projects. In any event, Fedora 37 later this year should ship with the newest Stratis tech...

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-37-Stratis-3.1-Plan

[Tjako]

I was curious about this project when it appeard, it showed a promising roadmap and had some nice features.
Because all the features that I wanted where on the future roadmap I decided to wait a bit before using it.

Now the roadmap has dissapeared and you have to dig through all the release notes to find the features.
Anybody who knows where to find the feature list ?
And maybe a roadmap ?

Cheers

[Alliancemd]

I was curious about this project when it appeard, it showed a promising roadmap and had some nice features.
Because all the features that I wanted where on the future roadmap I decided to wait a bit before using it.

Now the roadmap has dissapeared and you have to dig through all the release notes to find the features.
Anybody who knows where to find the feature list ?
And maybe a roadmap ?

Cheers

Their board is public: https://github.com/orgs/stratis-storage/projects/48

[skeevy420]

I was curious about this project when it appeard, it showed a promising roadmap and had some nice features.
Because all the features that I wanted where on the future roadmap I decided to wait a bit before using it.

Now the roadmap has dissapeared and you have to dig through all the release notes to find the features.
Anybody who knows where to find the feature list ?
And maybe a roadmap ?

Cheers

I was the same way until I realized they were gung-ho with using XFS. XFS can't shrink so it's a horrible choice to use as a file system for individual pools. You can't just willy-nilly make pools and run with it because you can't shrink. Making pools all willy-nilly and running with them are the hallmark features of BTRFS and ZFS. They'll never make an OpenZFS-like system with XFS.

Yes, I'm well aware that you can't shrink ZFS partitions. With ZFS/BTRFS you give the disk to the FS and create pools as necessary. All created pools have access to the full available size of the disk (barring quota's, etc) so you can create them and not worry about how much space it needs to be or worry about long term growth. With Stratis you give the disk to the FS and you create pools as necessary. All created pools have access to a predefined size and can only grow as necessary. If you over-provision your pool, whoops, too bad. If a log blows up and over-provisions your pool for you, whoops, too bad. You don't get one vast pool of storage to manage like the other options that you tame with quotas, you have many pools you have to manage and provision properly.

No matter what technical progress they make with Stratis, it'll always have the problem I just described due to being reliant on XFS. They really, really need to replace XFS with something else that can shrink so the administrator doesn't have to deal with per-pool sizes like they're dealing with a custom Linux partition scheme from the 90s. The more things change, the more they stay the same.

EDIT: I feel the need to mention that I don't have a problem with XFS as a file system. It's a great choice when you have a single disk that you give to a file system and you don't want to play with partition schemes. I used it for many, many years on my root drive.

[pWe00Iri3e7Z9lHOX2Qx]

Their board is public: https://github.com/orgs/stratis-storage/projects/48

That link is way too granular and totally useless for what the OP (and I suspect many people) want, in the same way that my teams' Jira scrum boards are totally useless even to executives within our company let alone end customers.

What we want is a simple view of the big features. What is supported now? What is planned? When (roughly) are they planned or at least a sequence of stuff to tackle?

• Send / receive
• Compression
• Deduplication
• Encryption
• [...]

They announced this as something that was going to compete with ZFS / Btrfs, but it sure isn't obvious if it's even close on the biggest selling points of those other offerings.

[RahulSundaram]

They announced this as something that was going to compete with ZFS / Btrfs, but it sure isn't obvious if it's even close on the biggest selling points of those other offerings.

It's blatantly obvious that this project wasn't announced to be a direct competitor since it's not a new filesystem but a user space tool. It's a niche stop gap project that noone outside of a few Red Hat customers would ever hear or care about without Phoronix posting every minor release with small number of bug fixes.

[Tjako]

That link is way too granular and totally useless for what the OP (and I suspect many people) want, in the same way that my teams' Jira scrum boards are totally useless even to executives within our company let alone end customers.

What we want is a simple view of the big features. What is supported now? What is planned? When (roughly) are they planned or at least a sequence of stuff to tackle?

• Send / receive
• Compression
• Deduplication
• Encryption
• [...]

They announced this as something that was going to compete with ZFS / Btrfs, but it sure isn't obvious if it's even close on the biggest selling points of those other offerings.

spot on

[MadeUpName]

There are two reasons this project hasn't gained any popularity. The first is that by using it you will have less functionality than if you don't use it. The second is that for pretty well the entire life of this project they have had a notice telling people no to use it because it would corrupt their data.

[pWe00Iri3e7Z9lHOX2Qx]

It's blatantly obvious that this project wasn't announced to be a direct competitor since it's not a new filesystem but a user space tool. It's a niche stop gap project that noone outside of a few Red Hat customers would ever hear or care about without Phoronix posting every minor release with small number of bug fixes.

Oh please. None of us care if it's a new file system or slick glue between existing capabilities.

https://stratis-storage.github.io/StratisSoftwareDesign.pdf

"This is also a chance to learn from the benefits and shortcomings of existing solutions. We should not just copy ZFS. ZFS is now fifteen years old and the storage landscape has changed since its design. We seek to satisfy the same needs that ZFS does, but also integrate more tightly into today’s increasingly automated storage management solutions that span the data center as well as the local machine. This is made possible by a hybrid, userspace-based approach."

https://fedoraproject.org/wiki/Changes/StratisStorage

"Stratis is a local storage system akin to Btrfs, ZFS, and LVM. Its goal is to enable easier setup and management of disks and SSDs, as well as enabling the use of advanced storage features -- such as thin provisioning, snapshots, integrity, and a cache tier -- without requiring expert-level storage administration knowledge. Furthermore, Stratis includes monitoring and repair capabilities, and a programmatic API, for better integration with higher levels of system management software."

https://github.com/stratis-storage/stratisd

"Stratis (which includes stratisd as well as stratis-cli), provides ZFS/Btrfs-style features by integrating layers of existing technology: Linux's devicemapper subsystem, and the XFS filesystem. stratisd manages collections of block devices, and exports a D-Bus API. Stratis-cli's stratis provides a command-line tool which itself uses the D-Bus API to communicate with stratisd."


Yeah, we are all idiots for hoping that Stratis might offer a solution that solves the same important use cases that ZFS does very well, but with an offering without the licensing challenges. It's not like they explicitly say they want to do exactly that or anything . I know you work at RH and I like the insight you provide in many posts, but you don't have to try and defend every single thing they do.

[skeevy420]

It's blatantly obvious that this project wasn't announced to be a direct competitor since it's not a new filesystem but a user space tool.

That's not what their documents say:

1.2Proposal: Implement a hybrid Volume Managing Filesystem

In the past ten years,volume-managing filesystems(VMFs) such as ZFS and Btrfs have come
into vogue and gained users, after being previously available only on other UNIX-based operating
systems.These incorporate what would be handled by multiple tools under traditional Linux
into a single tool. Redundancy, thin provisioning, volume management, and filesystems become
features within a single comprehensive, consistent configuration system.Where a traditional
Linux storage stack exposes the layers of block devices to the user to manage, VMFs hide
everything in apool. The user puts raw storage in the pool, the VMF manages the storage in
the pool, providing the features the user wants, and allows the user to create filesystems from
the pool without being concerned with the details.

Unfortunately, existing VMFs aren’t easily used on enterprise Linux distributions like RHEL.
ZFS isn’t an option RHEL can embrace due to licensing, Ubuntu notwithstanding. Btrfs has no
licensing issues, but maintaining up-to-date support for it in enterprise kernels proved difficult.
We can see from the many developer-years of effort that have gone into these two projects
that writing a VMF is a tremendous, time-consuming undertaking. We also can hear our users
demanding their features and ease of use.

Rather than writing a new VMF from scratch, Stratis proposes to satisfy VMF-like require-
ments by managing existing technologies on behalf of the user, so that users can manage their
storage using high-level concepts like “pool” and “filesystem”, and remain unconcerned with the
more complex details under the covers.

This is also a chance to learn from the benefits and shortcomings of existing solutions. We
should not just copy ZFS. ZFS is now fifteen years old and the storage landscape has changed
since its design. We seek to satisfy the same needs that ZFS does, but also integrate more tightly
into today’s increasingly automated storage management solutions that span the data center as
well as the local machine. This is made possible by a hybrid, userspace-based approach

It basically says, "We like BTRFS but can't maintain it and we like OpenZFS but licenses and tigers and bears. Since our users want BTRFS and OpenZFS but we can't deliver those for reasons here's Stratis."

I find it very ironic that RHEL is calling something else old when they're 22 years old.

Our users like RHEL. However, RHEL is now 22 years old and the enterprise distribution landscape has changed. SkeevyHat Enterprise Linux seeks to satisfy the same needs that RHEL does, but also integrate more tightly with blackjack and hookers. You know what? Forget the distribution.

It's a niche stop gap project that noone outside of a few Red Hat customers would ever hear or care about without Phoronix posting every minor release with small number of bug fixes.

Calling it a stop gap assumes that it'll become abandonware since the definition of a stop gap is a temporary way to deal with a problem. Due to that definition it brings about the assumptions that there was a previous solution and that there will be a future solution.

What was the previous solution and what will be the future solution?