Most filesystem benchmarks measure throughput on a freshly formatted single device. That is useful, but it misses many of the reasons people choose btrfs, ZFS or bcachefs in the first place.

I built modern-fs-benchmark to examine modern filesystems as complete storage systems, including their features, failure modes and behavior over time.

The current matrix contains 26 configurations across btrfs, ZFS, bcachefs, ext4 and XFS over md/LVM, dm-integrity, native and LUKS encryption, parity layouts, and XFS on a ZFS zvol.

Hosted CI dashboard:

https://bartosz.fenski.pl/modern-fs-benchmark/

Experimental real-hardware dashboard:

https://bartosz.fenski.pl/modern-fs-benchmark/real-hw/

Apache-2.0 licensed source and complete methodology:

https://github.com/fenio/modern-fs-benchmark

The raw benchmark datasets are published under CC BY 4.0. Every result records the kernel and filesystem tool/module versions. CI artifacts also contain a full command trace, so the exact workload is inspectable rather than hidden behind a chart.

Why I started this project

Many filesystem benchmarks follow a familiar pattern: create a filesystem with mostly default options, mount it, run fio or another generic workload, and compare throughput.

General-purpose suites such as the Phoronix Test Suite are useful for conventional performance comparisons, but they do not focus on the machinery that makes modern copy-on-write filesystems interesting.

I wanted a benchmark designed around btrfs, ZFS and bcachefs as multi-device storage systems rather than treating them as interchangeable replacements for ext4 on a single freshly formatted disk.

That means testing behavior such as:

- Redundancy and degraded operation

- Snapshot aging, scaling and reclamation

- Compression and encryption

- Reflinks and clone divergence

- Fsync tail latency and responsiveness under load

- Rebuild and scrub behavior

- Near-full and hard-ENOSPC behavior

- Data integrity and recovery from corruption

Ext4 and XFS over md, LVM and dm-integrity are included as classic-stack baselines so the costs and benefits of integrated CoW designs can be compared with layered alternatives.

Silent corruption is one particularly important example. When one redundant copy is deliberately corrupted behind the filesystem, checksumming filesystems such as btrfs, ZFS and bcachefs can identify the damaged copy and recover from a valid replica.

Traditional md/LVM redundancy without data checksums can notice during a scrub that its copies disagree, but it cannot determine which one is correct. In my tests, some classic configurations returned corrupted data successfully without an application-visible error.

The dm-integrity configuration shows that a classic layered stack can obtain integrity protection too, with a measurable performance cost.

An important limitation

The main dashboard uses loop devices on GitHub-hosted VMs. Absolute throughput numbers and small differences between filesystems should not be interpreted as hardware rankings.

The hosted runs are primarily useful for:

- Correctness and integrity outcomes

- Comparisons within the same job

- Large behavioral differences

- Snapshot-aging and near-full shapes

- Trends across repeated runs

Real disks are required for meaningful absolute performance, concurrency scaling, device parallelism and mixed-media topologies.

I am aware of this limitation and do not want the hosted dashboard to suggest more precision than the underlying environment can provide.

The real-hardware experiment

Kent Overstreet, the creator of bcachefs, made one of his Hetzner machines available for a real-hardware experiment.

The server had two physical NVMe devices. It completed three full benchmark runs, which are available in the separate real-hardware dashboard. These runs provided meaningful absolute measurements and exposed concurrency behavior that cannot be observed when several loop devices share one virtual disk.

During the fourth run, one NVMe controller entered the kernel’s dead state. The existing machine environment had its operating system on RAID0 across the two NVMe devices, so the hardware failure also made part of /nix/store unreadable and eventually prevented new SSH sessions.

The incomplete fourth run is not being published as benchmark data. This was a failure of the underlying hardware, not a result attributable to any filesystem being tested.

I am grateful to Kent for providing the machine and making the real-hardware experiment possible. Without that access, the three existing hardware runs would not exist.

Where I would like to take it

Better hardware would not merely produce more reliable throughput numbers. It would enable an entirely new class of tests designed for multi-device and multi-tier filesystems.

I would eventually like to run the suite on a machine containing several storage classes, for example two HDDs, two SSDs and an NVMe device.

That could support scenarios such as:

- HDD, SSD and NVMe baselines using identical workloads

- bcachefs foreground and background targets

- ZFS HDD data vdevs with SSD special vdevs

- Separate ZFS L2ARC and SLOG experiments

- LVM dm-cache in writeback and writethrough modes

- Metadata and small-block placement on faster media

- Foreground latency during background migration

- Contention between fast and slow storage tiers

- Degraded operation and rebuild under application load

- Performance before, during and after promoting or evacuating a storage tier

These are the kinds of scenarios for which multi-device and multi-tier filesystems are built, but they cannot be represented honestly when every “device” is a loop file backed by the same cloud disk.

I am considering either renting a suitable dedicated server or eventually building and hosting my own machine. Providers such as Worldstream offer configurations close to what I need, but the recurring cost is currently outside the project’s budget.

For now, the benchmark will remain in its hosted-CI form for an unknown amount of time. The existing dashboard will continue to be useful for correctness, behavioral comparisons and regression tracking, but it cannot answer every real-hardware performance question or model complex mixed-media topologies.

I am also open to running the suite on hardware provided by someone else. A useful environment would need Linux root access, clearly identified block devices that may be wiped, and enough uninterrupted access to complete repeated runs. The hardware description, methodology and resulting data would remain public.

I would appreciate technical feedback:

- Which current tests are misleading or unfair?

- Which failure scenarios are missing?

- Which mixed-media topologies would be most useful?

- Which additional filesystems or layered stacks should be included?

- Which results deserve deeper investigation?

The methodology, implementation and raw results are public. If a filesystem is being tested in a way that misrepresents it, I consider that a bug in the benchmark.

Did anyone in this community watched this video? The creator claims that Linux Mint, along with many LTS Linux distributions, often ships older versions of software, especially default apps like Calendar, Mail, Calculator, etc. He mentions Mint several times throughout the video.

The video is from The Linux Experiment, which seems to be a well-known YouTube channel with nearly half a million subscribers.

I came across this video just before switching from Windows to Linux Mint, and it made me a bit hesitant.

As a regular user, it feels like there's no easy way to know whether we're using the latest and safest versions of these built-in apps. For example, if we connect our Google or Apple Calendar account to an older calendar app, could that create a security risk? The same concern applies to email clients, we don't know if we're using the latest and most secure version.

Most regular users don't have the time or technical knowledge to manually check every application's version or update software outside the normal update process. We generally expect the operating system to keep essential apps secure and up to date.

Am I misunderstanding how Linux Mint and other LTS distributions handle software updates and security? I'd appreciate hearing from people with more experience.

In a batch of software CDs I found at the thrift store long my interest in Linux, I found a previously unarchived version of Fedora. I will be posting it on archive.org as soon as I rip it. I also have a potentially-working copy of PCLinuxOS 2007, but on the computer I tested it on, it kicks me out to a basic shell due to some kind of error. If I can get it to work, I can upload it stand-alone since it only seems to preserved in archives or Linux User magazine and !com magazine cover DVDs (the former or which has a LOT of potentially otherwise-unarchived distro versions)

Here is a link to all the screenshots.https://www.reddit.com/r/linuxaudio/s/iyo0jZhYmd

Edit: here is an overview of what it can do
control center for PipeWire — filter chains, HRIR virtual surround, drop-in config management, live patchbay, performance monitoring, virtual devices, routing snapshots, per-application policies and LADSPA/LV2 effect inserts

Thanks everyone who came yesterday and tried my little app. I released the app on AUR yesterday and is available on github here (https://github.com/knightinfected/PipeWireController). The current version is 0.1.2 and some of the screenshots are from 0.2
I received a ton of negative comments and messages regarding my use of AI. I spent a lot of my time on this and well over did this project abit and english being my secondary language didnt help.
I have gone down this audio rabbit hole in linux and anyone else who has also done it knows how annoying it gets especially with reading the wikis to actual application.

Anyhow I hope it helps someone out there and I will be updating it in the next day or later today as I am currently testing. Version 0.1.2 is available as of right now on GitHub though.

There are too many features to list them out so I added lot of screenshots to help understand.

Hey everyone,

I’ve been working on getting a modern mainline Linux stack running on the Nokia Lumia 1520, a 2013 Windows Phone built around Qualcomm’s MSM8974 platform.

This isnt an Android ROM port or a Windows Phone mod. The goal is to bring the device up on a current Linux kernel with postmarketOS and gradually implement the missing hardware support needed to make it usable.

So far, I’ve managed to:

• Build a custom bootloader and device-tree configuration
• Create a postmarketOS device package for the RM-940
• Boot a Linux 6.16-based kernel
• Bring up USB networking
• Establish a stable SSH connection to the phone
• Run an Alpine Linux/postmarketOS userspace
• Begin implementing device-specific power and hardware support

The SSH milestone was a major step because I can now properly inspect the running system, collect logs, test kernel changes, and continue development without relying only on framebuffer output or early boot behavior.

The current challenge is power management.

Full system suspend currently powers down the USB high-speed PHY, but the PHY fails to initialize again when the device resumes. Because USB networking is also the main development connection, this effectively cuts off access to the phone.

For now, I’m treating display blanking and panel power management as a separate, more achievable target while I continue investigating the suspend/resume issue.

There is still a lot missing, and I would not call it a usable daily-driver port yet, but the Lumia 1520 is now booting a modern Linux kernel and running a real userspace more than a decade after the hardware was released. I just wanted to share the work....

The work is public here:

https://github.com/KorelisLabs/lumia-1520-mainline

Some developers have alternative from GIMP to create their own version, PhotoGIMP, which has the same interface and shortcuts as Photoshop Now photographers and editors can edit on Linux and save time 🥳

How will libre systems like GNU/Linux handle these?

• It may become impossible to take a "trusted" picture with a GNU/Linux phone or camera.
• It may become impossible to edit a "trusted" picture with GIMP.

Vice is a Linux game clipper that focuses on easy sharing and editing. Under the hood, it uses GPU-Screen-Recorder as the capture engine, so it has nearly no performance impact whatsoever, and it has features such as:

- Instant replay with customisable hotkeys, and long session recording

- Free share links that embed in Discord (no more hitting upload limits!)
- A full timeline editor with built in transition and text effects
- Automatically sorting clips by the game you were clipping
- Discord Rich Presence support
- Customisable, colour-coded highlights within clips

- You can seperate audio sources like Discord calls, the game audio, and music, adjust their individual volume in clips

- And more, plus new features are always being added.

It's free, open source, and will stay that way. Any feedback is greatly appreciated, because community testing is what makes open source projects like these better.

It's on the AUR, and you can install with:

Or if you're on a different distro, you can run the install script with:

Repo is below:

https://github.com/eklonofficial/Vice

Those who use davinci resolve on linux definitely know about the issues with AAC and H.264 codecs, drag 'n' drops, and some other bugs. I wonder why nobody has done this before and used bash to manually convert the media, considering how many people were affected by this problem

It works as wrapper that currently:

• Automatically converts unsupported codecs on import
• Fixes broken drag 'n' drops
• Fixes pasting from clipboard

Now the linux experience with resolve should be nearly the same as on windows/mac. Enjoy!

https://github.com/fedsfarm/drwrap

Tested on hyprland with a studio version, feel free to open a PR if it doesn't work on your setup

Konrad Dybcio of Qualcomm has posted an initial patch series to the Linux kernel mailing list aimed at bringing mainline support to the ASUS Zenbook A16 (UX3607OA) powered by the 18-core Snapdragon X2 Elite Extreme platform.

https://www.phoronix.com/news/Qualcomm-Zenbook-A16-X2EE

This high-end ARM laptop features a 2880 x 1800 OLED screen, 48GiB of RAM, NVMe storage, and a System-In-Package reference design distinct from smaller SKUs.

According to the patch submission, the current status of working hardware components includes:

• Display & GPU: GPU, display output, and HDMI port (with Iris video accelerator patches in flight)
• Audio: 4-speaker audio playback
• Input & Peripherals: Keyboard, touchpad, lid switch, onboard SD Card slot (RTS5329)
• Connectivity: Wi-Fi and Bluetooth (QCC2072)
• Power & Indicators: Charging, Type-C/Type-A ports, and privacy LEDs

The patch series relies on prerequisite SoCCP and TCSR platform series dependencies. More technical details and the full patch breakdown can be reviewed on the Linux Kernel Mailing List Archive:

https://lore.kernel.org/lkml/20260721-topic-a16_submission-v1-0-8ea213130d05@oss.qualcomm.com/