Stratis: Redhat's take on robust, ZFS-like filesystems

So I'm sure some of you are aware by now, but if not, RedHat is flat out dropping all support for BTRFS in the future.
phoronix.com/scan.php?page=news_item&px=Red-Hat-Deprecates-Btrfs-Again

A shame, as BTRFS has just recently made major progress towards eradicating its only real dealbreaker, broken RAID5/6 support.
It's also still got the backing of SUSE, Facebook, Oracle, and Fujitsu.

However, RedHat has decided to go for its own solution, Stratis. You can read about it in depth here
stratis-storage.github.io/StratisSoftwareDesign.pdf
but here are their plans from their requirements list
1.Make features easier to use in combination with each other: thin provisioning, snapshots, integrity, redundancy, multipath, encryption, hardware reconfiguration, monitoring, and a caching tier2. Simple and comprehensive command-line interface (a) Simple i. Single way to do things ii. Do not expose internal implementation details. Gives Stratis more implementation freedom, and of little value since internals are too complex to make manual user repairs practical iii. User typically will not use on a daily basis A. Consistent commands that a user can guess at, and probably be right B. Require explicitness from the user for potentially data-losing operations, such as giving a “–force” option. (b) Comprehensive i. User must master only one tool ii. Helps user learn: if task not possible through tool, it must not be worth doing (or a good idea)3. Programmatic language-neutral API for higher-level management tool integration (a) A clear next step for users after hitting the limitations of scripting the CLI (b) Encourages tight integration and use of all features by higher-level tools4. Event-driven monitoring and alerts (a) Monitoring and alert messages expressed in terms of Stratis user-visible simple concepts, not implementation details (b) Low CPU/memory overhead to monitoring (c) Only alert when action really is needed (d) Fail gracefully if alerts are unheeded5. Eliminate manual resizing of filesystems (a) Numerous problem reports throughout the years indicate that resizing filesystems is an area where users feel unease, due to potential data loss if a mistake is made. No real reason to require the user do this any more. (b) Simpler for DevOps (c) Makes storage “demand-allocated”, similar to virtual memory. Current technology allows us to manage a filesystem’s actual usage up (growfs) or down (thin provisioning).6. Initrd-capable (a) Allows root fs, all other filesystems except /boot to use Stratis. Needed for ease of use (b) Limited environment – no Python or DBus – but can use device-mapper7. Bootable (planned – see 11.6) (a) Feels like a “real” filesystem if no secondary filesystem is needed for boot (b) Enables Stratis features to be used by system image, e.g. booting from a snapshot, and allowing /boot to grow (c) Requires explicit support in bootloader (Grub2) (d) device-mapper not available8. Adaptable to emerging storage technologies (a) Persistent memory i. Block-appearing pmem can be used by Stratis ii. byte-addressible pmem see 11.69. Implementable in 1-2 years (a) We’re already behind, waiting another 10 years isn’t an option

Attached: stratis.png (200x200, 13.66K)

Other urls found in this thread:

perlfs.sourceforge.net/
wiki.archlinux.org/index.php/Libinput
twitter.com/NSFWRedditGif

Oh yeah and they're writing it in Rust and Python

Who cares? Red Hat is just a distro.

This is just pathetic. The future will be Wayland tied to systemd (which will be required to use any graphic drivers).

Sounds good to me. I enjoy pulse audio where when I plug in a USB headset it works on all my machines. No script hacking bullshit. When I want to I can easily route audio between different sources and sinks. I enjoy systemd where I can launch applications after complex dependencies are met. I love that I don't have constant tearing on wayland and that windows don't have to redraw themselves everytime I move them around or put one on top of another. These systems are sometimes buggy as fuck, but they have reasons for existing. Particularly wayland my god X is such a piece of shit.

I assume the CLI utilities are being written in python like most projects do. They are not going to have python doing the actual FS parts.

X is a dumpster fire, but Wayland isn't much better. This is an anecdote, but - I've never experienced any tearing with a proper xorg.conf (I don't use nVidia or a compositor, maybe that's your problem). GPU drivers will be bound to systemd, mark my words. I remember OSS just working too, and sndio + mixerctl on OpenBSD is way better than pulseaudio. Oh, and they're trashing pulseaudio (for pulsewire).

Its better in so many ways. First off its buffer based which means you don't have to redraw every time. Its very simple. Each program just gets a little buffer to write to. The programs are isolated. Having a connection to X does not give you access to everything on the screen. This ensures you need actual permission to screenshot.

The complaint people always have is that its not network transparent. Which sure its not.

Soyboy tier tbh fam. Here's something better.
> perlfs.sourceforge.net/

Attached: cat-in-the-hat.jpg (350x450, 17.33K)

It’s pipewire.
Also, i’ve heard a lot of good things about OpenBSD’s sound system. It’s fortunate that Genode OS is using it, assuming it’s as good as you claim.
If you want to know why Pulse was made, see again, specifically the opening part. Users would have consistent issues getting headphones to “just werk” without fucking around with some config. It also apparently is useful for people with more complex audio setups.
In my experience it only fucks things up, but I’ve heard some positive experiences about it lately.

This. Wayland is worth it for the security alone.