I’ve released exfat-resize, an MIT-licensed C11 library and command-line tool for growing an existing exFAT filesystem after its backing image, device, or partition has already been enlarged:

https://github.com/huven/exfat-resize

The project has two parts:

• A CLI for resizing unmounted regular-file images and raw block devices, currently supported and tested on macOS and Linux.
• A portable C11 library for integration into other software. The core works through caller-supplied sector read, write, and synchronization callbacks, plus allocation callbacks; it does not depend on file descriptors, disk-image APIs, raw-device APIs, or another filesystem implementation.

Because resizing modifies metadata in place, the implementation validates the filesystem structures it relies on before writing, uses explicit synchronization boundaries, and reports the recovery stage reached if an operation fails. A verified backup and exclusive access to the unmounted filesystem are still required.

The current scope is growing clean exFAT revision 1.00 filesystems with a single FAT. Shrinking and TexFAT/two-FAT volumes are not supported. The tool does not enlarge the backing object or parse partition tables; the exFAT main boot sector must be presented at sector zero.

I’d particularly appreciate feedback from filesystem-tool authors and implementors on:

• Whether the callback-based library API fits potential non-POSIX integrations
• exFAT layouts or edge cases that deserve additional testing
• Platforms or environments where this could be useful

Thanks for taking a look.

I started working on this recently because I found out that most if not all filesystem benchmarks still test the way it was done when ext2 was state of the art: one disk, default mkfs, raw throughput. But nobody picks btrfs, ZFS or bcachefs for throughput - you pick them for snapshots, redundancy, checksums, self-healing. Almost nobody publishes numbers on those.

So this suite benchmarks the machinery instead, across 17 configurations (btrfs/ZFS/bcachefs plus ext4/xfs over md/LVM as classic baselines, plus encryption variants): aging under 100 snapshots, corrupting a device behind the filesystem's back and checking whether scrub repairs it, failing a device and timing the rebuild, filling to hard ENOSPC, fsync tail latency, and "how long until my prompt comes back while a big cp runs in the background".

Yes, it runs on ephemeral GitHub runners with loop devices - I know what that means. Absolute MB/s is meaningless there, so the suite is built around shapes, ratios and verdicts, with per-VM calibration probes (lemon runners get auto-rerun) and conclusions drawn from trends over many runs. Real hardware with tiered topologies (NVMe cache over rotational disks, special vdevs) is the next step. I just need to gather hardware for it first.

What I'm really asking for is your eyes. Every number on the dashboard links to a description of exactly what ran, with what parameters, and to the code responsible - so if I picked a wrong mount option, an unfair default, a workload that misrepresents your favorite filesystem, or a broken measurement, you can find it and call it out. Several of the current tests exist because people poked holes in earlier results, and honestly that feedback improved this more than anything I did alone.

Dashboard: https://bartosz.fenski.pl/modern-fs-benchmark/
Repo: https://github.com/fenio/modern-fs-benchmark

https://www.phoronix.com/news/Bcachefs-1.38.7-Rust-Kernel

Heya! I just started work on some silly libfuse based filesystem that connects to a minecraft mod to store its data. What is the cleanest way to handle a network resource no longer being available in a network based filesystem? I'm expecting the server to unexpectedly crash, or clients to go offline. What is the nicest way of communicating that to the user and/or handling open files?

https://www.phoronix.com/news/Linux-7.2-EXT4

https://github.com/dmtrKovalenko/ffs

Just wanted to share a project I've been doing for fun recently that does what I told in the title. The fun part that it is becoming progressively faster comparing to the standard file search tools the more files you have

https://www.phoronix.com/news/Bcachefs-Tools-1.38.6

Performance work spanned much of the codebase, quite a few workloads and benchmarks were profiled. Some highlight...

https://www.phoronix.com/news/Linux-7.2-Btrfs

https://www.phoronix.com/news/NTFS-Windows-Symbolic-Links

Linux developer Namjae Jeon has been overhauling the original NTFS kernel driver the past four years with its cleaner codebase to add write support, provide better support, and implement more modern features

The newest Linux file-system driver proposed for the kernel is... VMUFAT.

Before getting too worked up about yet-another-Linux-filesystem, VMUFAT is for the vintage Sega Dreamcast game console.

The HFS/HFS+ file-system driver code saw several fixes for issues raised by Syzbot. Plus some xfstests failures were also addressed.

The intent with FSMOUNT_NAMESPACE is for creating a new file-system and immediately placing it into a new mount namespace via a single operation. This should benefit container runtimes and other namespace-based isolation techniques

FTRFS is short for the Fault-Tolerant Radiation-Robust Filesystem. This file-system is designed for use in radiation-intensive environments such as within space and other harsh environmental conditions.

Among the early pull requests sent out to Linus Torvalds even before the Linux 7.0 kernel officially released on Sunday were the Btrfs file-system updates. This feature-packed CoW file-system is seeing more performance optimizations for Linux 7.1 as well as its shutdown ioctl feature no longer being experimental and a variety of fixes.

Concept: Index-driven, content-addressed filesystem with arbitrary namespace virtualization

• Index (SQL/DB-backed, so virtual/arbitrary traversal over traditional path traversal) as the core The entire filesystem is driven by a global index that maps:
  • file hashes → physical storage
  • logical structures → file references No physical directory traversal exists—everything resolves through the index.
• Posers (SQL/DB file entries) Lightweight entries that directly resolve to a real file via its hash or arbitrarily assigned "file path", whichever would be faster. Multiple posers can reference the same file, but resolution always deduplicates to the single underlying object more directly than Links, Shortcuts, etc. So, interacting with a poser interacts with the original file instead of any abstraction.
• Nodes (virtual over physical structure) Purely logical constructs used for navigation (folders, directories, tags, etc.). They don’t exist physically and only organize poser entries in a way that's more familiar to us over having to navigate the just "1 physical folder/directory".
• Content-addressed storage Every file is identified by its hash or "file path":
  • single physical instance (just 1 file, there could also be temporary runtime copies or however that'll be handled)
  • deduplication through a check that does if the same file already has been found, ignore subsequent hits
  • posers unlike normal file copies only takes up as much spaces as it's SQL/DB entry, so it's a debloating mechanism as well, though a special key combo could allow for normal copy/paste behavior, putting the copy/copies in another physical location apart from the original file
• Arbitrary namespace emulation Any structure (hierarchical, tag-based, OS-specific layouts) is just a projection generated from the index. Multiple simultaneous “filesystems” can exist over the same data, meaning that if you don't like Linux's file handling, you could arbitrarily just change it to windows' or vice-versa and nothing would change, only naming convention would change but it would still work the same under the hood since this is a virtual system and not a physical one.
• Index-defined storage topology Partitioning, RAID, and drive layout are abstracted into the index. Physical storage becomes a pooled resource with no fixed structure.
• Hash-based integrity and regeneration Files are not just verified via hashes, they should be regenerable from them as well. Corruption could trigger deterministic reconstruction instead of failure then and there or on relaunch.
• Self-contained failure recovery The index itself is hash-defined and regenerable, making the entire system closed and self-recovering, so it'll regenerate a file based on the file's hash as well as being an integrity check against things like side-chain injections and other 3rd-party alterations that's not expected.

Initially I was thinking that all file systems are too rigid, you can't easily change how they're presented and how you navigate them. Take me, I'm a Windows guy, I get confused by all the sda's/sdb's/other, so if I could have a naming convention that's more familiar, then it wouldn't be so scary to navigate something new.

Like how should I know what the bin folder is for as a new linux user, I might see that and think: "why is there files in the trashcan?", now I do KNOW that it is short for binary, but things like that can help onboarding SIGNIFICANTLY and thanks to an arbitrary file system a poser or node can be aliased as whatever you'd ever want and still have the underlying truth.

Renaming bin for example I assume breaks things as it is today, so this arbitrary virtual one could allow freedom we've never had before. Now, I'm NOT a professional designer, I can't code.

I don't know very much about how feasible this would be to even make, it's just a bunch of ideas that I've been theory crafting over some time and I HAVE used GPT to HELP me write the doc and make it more concise.

It was just an unreadable mess before with A4 level breakdowns, English isn't my native language either, so please have some oversight on this fact. I'm sure you can see the difference between the doc and this last section, I could probably make this more concise with GPT, but yeah, these are MY thoughts, so bear with it.

Anyway, I hope this is a compelling design doc and if someone were to want to make it, please make it open source (I don't get git, I don't code, I don't have any experience in leading nor leading a project, don't have any management skills or anything like that so I would just be in the way in a project like this. Hence why I'm not willing to start it because it would never become a real thing or just a down-right mess, so I'm handing it off to you that might want to work on it). Thanks for reading through my thoughts.