Filesystem medley: EROFS, NTFS, and XFS

By Jonathan Corbet
January 23, 2026

Filesystems seem to be one of those many areas where the problems are well understood, but there is always somebody working toward a better solution. As a result, filesystem development in the Linux kernel continues at a fast pace even after all these years. In recent news, the EROFS filesystem is on the path to gain a useful page-cache-sharing feature, there is a new NTFS implementation on the horizon, and XFS may be about to get an infrastructure for self healing.

EROFS page-cache sharing

The Enhanced Read-Only Filesystem (EROFS) is, as its name would suggest, a filesystem for read-only data. EROFS supports an assortment of advanced filesystem features and provides high-performance data compression. It can be found in a number of settings, perhaps most notably on Android devices. EROFS was merged for the 5.4 kernel release in 2019 and has been steadily developed since then.

One common use case for EROFS is as a base layer for container images. As such, an EROFS filesystem can often be mounted many times on a given machine, and there can be multiple variants of a given filesystem with minor differences. Several images may contain different application mixes, but all have the same C library, for example. While EROFS will deduplicate data within a given filesystem at creation time, it cannot do that for independently created filesystems. Duplication of files across filesystems can result in multiple open files containing the same data in the system as a whole, wasting a lot of memory as that data is placed in the page cache. It would be nice to find a way to deduplicate that page-cache data and eliminate that memory waste.

In early 2025, Hongzhen Luo posted a patch series implementing page-cache sharing for EROFS. Later on, Hongbo Li picked up and continued that work; the most recent posting is version 18. It works by assigning a "fingerprint" to each file within a filesystem at creation time; that fingerprint is later used to detect files containing the same data.

Specifically, each file within an EROFS filesystem is given an extended attribute; the name of that attribute can be set by the creator, but trusted.erofs.fingerprint appears to be standard usage. The actual contents of the fingerprint are not defined. A logical value to use would be a cryptographic hash of the file's contents but, as Gao Xiang said, it could simply be an integer value assigned by the image creator. It should, of course, be different for two files if they have different content.

The fingerprint is used if the filesystem is mounted with the inode_share option. Another option, domain_id, is used to separate users; only files mounted within the same domain ID will be deduplicated. In the absence of this restriction, an attacker who is able to mount an EROFS filesystem could attach arbitrary fingerprints to files with malicious content, possibly causing other users to obtain that content rather than the files they were hoping for.

When a fingerprinted file is opened, the EROFS code creates an internal inode that references the data within that file. The file opened by user space is redirected (within the kernel) to that deduplication inode, which is associated with the fingerprint internally. Subsequent opens of files with the same fingerprint will simply take a reference to the deduplication inode, and read operations will be redirected to that inode's backing store. As a result, all of the files will share the same folios in the page cache, eliminating the duplicate memory usage.

In the current implementation, at least, use of fingerprints is incompatible with direct I/O.

Depending on the workloads running within a system, page-cache sharing can reduce memory usage by as much as nearly half in the best cases. So the attractiveness of the idea is not entirely surprising. The patch series has evolved considerably over time and a lot of review concerns have been addressed, but some still remain. Christoph Hellwig, for example, is concerned about the security implications of this feature, and will likely need some convincing before coming around. So, while 18 revisions is quite a few, there will likely be more yet before this feature is merged.

A new NTFS

NTFS is the standard Windows filesystem format. One would think that Linux, which has long offered interoperability with as many systems as possible, would have a good NTFS implementation, but that has never really come to pass. For years, the kernel was limited to read-only support for NTFS. Linux users wanting full access to NTFS filesystems had to make do with ntfs-3g, running under FUSE in user space.

That situation appeared to change with the arrival of ntfs3 in 2021. This implementation offered full NTFS access and appeared to be what the community was waiting for, despite worries expressed at the time that the level of support behind this system was less than might be desired. It was merged for the 5.15 release, and the read-only NTFS filesystem was removed from the kernel for the 6.9 release in 2024.

The worries about the maintenance of ntfs3 have, to an extent, been realized since its merging. The ntfs3 code, having been freshly merged in 5.15, would normally be expected to see a fair rate of change in subsequent releases as bugs are fixed and more features added. In this case, though, there were exactly four ntfs3 patches in 5.16, only one in 5.17, five in 5.18, and so on. The pace picked up somewhat around 6.0, but has dropped off more recently. There have been 67 commits to fs/ntfs3 in the last year. Many of those changes are not by its maintainer (Konstantin Komarov), but by other developers fixing up ntfs3 for changes elsewhere in the tree.

In October 2025, Namjae Jeon surfaced with an alternative NTFS implementation called "ntfsplus"; the filesystem has since just been rebranded "ntfs", matching the old, read-only implementation. The work, Jeon said, was motivated by the fact that "ntfs3 still has many problems and is poorly maintained"; ntfs is meant to be a better-maintained and more functional NTFS implementation. The fifth revision of this patch set was posted on January 11.

The series begins by reverting the removal of the read-only NTFS filesystem. This code, Jeon says, "is much cleaner, with extensive comments, offers readability that makes understanding NTFS easier", so it makes a better base for ongoing development than the ntfs3 code base. From there, the series adds the code needed to turn the filesystem into a proper, read/write implementation of NTFS. Toward the end, the series removes the compatibility code that ntfs3 uses to emulate the old, read-only implementation.

There are, Jeon says, a number of advantages to this version. It uses the iomap layer to interface with the memory-management and block subsystems; ntfs3, instead, still uses the older buffer-head interface. (It should be said that there is a patch from Komorov adding iomap support to ntfs3 currently sitting in linux-next). There is an associated project adding a filesystem checker. Jeon claims that this filesystem passes many more fstests tests than ntfs3. A set of benchmarks shows better performance than ntfs3, as much as 110% better for some workloads.

The patch set has evolved quickly over the short time it has existed on the lists, and a lot of review comments have been addressed. The new filesystem appears to be mostly feature-complete, with one notable exception: it does not yet support journaling. The ntfs3 implementation is able to play back an existing journal (though Jeon says that this feature "in our testing did not function correctly"). The next step, according to the cover letter, will be full journaling support.

The kernel community is normally unenthusiastic about multiple implementations of the same functionality, and would rather see incremental improvements than wholesale replacements; that places a sizable obstacle in Jeon's path. Even so, the new code appears to be winning over the filesystem developers; there are a lot of review comments, still, but they are aimed at improving the code rather than questioning its existence. To replace the NTFS implementation again would be a big step, but it appears to not be an inconceivable one.

XFS self healing

The XFS filesystem tends to be associated with big systems; it is designed to scale to massive files in great number, on systems with a lot of CPUs. The organizations that run this type of system also tend to be concerned about reliability and data integrity. A lot of work has been done on XFS in those areas in recent times; one piece of that is the XFS autonomous self-healing infrastructure from Darrick Wong.

The kernel-based infrastructure will not, on its own, heal a problematic filesystem. It is primarily a reporting mechanism giving a user-space daemon the ability to learn about problems; the decision on how to respond to any particular problem can then be made in user space. That daemon might respond by killing and restarting a container, initiating some sort of scrub operation, or trying to correct an error in some other way. Regardless, this is a complex operation with policy decisions that are best made outside the kernel.

The series adds a new ioctl() operation, XFS_IOC_HEALTH_MONITOR, which will return a file descriptor to a suitably privileged process. Whenever an event of note takes place, a structure will be written to that file descriptor for user space to read and react to. For the curious, this patch starts with a justification of the decision to output events as binary C structures rather than using some sort of higher-level protocol encoding.

There is a wide variety of events that can be reported, starting with an "unmount" event; it indicates that the filesystem is no longer mounted, and no further events will be produced. There is a set of events for reporting metadata corruption, distinguishing between "sick" metadata (with corruption noted at run time) and "corrupt" metadata (detected by the filesystem checker). Other events report media and I/O errors. The series also adds an ioctl() operation to check whether a given file descriptor refers to a file on the filesystem that is being monitored; it can give the user-space daemon confidence that it is, indeed, operating on the right filesystem.

On the user-space side, Wong has a repository that includes an xfs_healer program designed to use the new interface. For the curious (and troff-capable), there is a minimal man page describing this utility; we have created a rendered version of that page that some may find a little easier on the eyes.

The kernel series is in its sixth revision, and it would appear to be stabilizing. It may find its way into the mainline in the near future. It might take a bit longer, though, to develop the user-space code to the point that administrators will trust it to operate on a live, production filesystem.

Index entries for this article
Kernel	Filesystems/EROFS
Kernel	Filesystems/NTFS
Kernel	Filesystems/XFS

to post comments

Compelling reasons to switch ?

Posted Jan 23, 2026 17:15 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (11 responses)

On my computer, the very first public release of ntfs-3g ran out of steam for files larger than several hundred MBs, but that was fixed quickly. Since then, which was nearly two decades ago, ntfs-3g has been reliable IME.

Honest questions:
* for most users, with the ever increasing focus on security, what are the highly compelling reasons to use kernel-mode drivers like ntfs3, or that new version of ntfs, instead of trusty old FUSE ntfs-3g ? Performance, really ?
* for security-minded users aiming at reducing the attack surface without resorting to building and signing their own kernels, why should their hardened deployments of standard Linux distros not add into some /etc/modprobe.d/* file:
install ntfs /bin/true
right next to
install ksmbd /bin/true
and a number of similar lines for disabling rarely used filesystems and/or repeat security offenders ?

Compelling reasons to switch ?

Posted Jan 23, 2026 17:59 UTC (Fri) by pizza (subscriber, #46) [Link] (2 responses)

> Performance, really ?

"Security" is not the focus of most users... as opposed to things like "don't eat my data".. and yes, "performance".

Filesystems are routinely benchmarked on "performance". But you can't sell "security" the same way.

Compelling reasons to switch ?

Posted Jan 24, 2026 8:08 UTC (Sat) by Lionel_Debroux (subscriber, #30014) [Link]

Nearly 20 years ago, after the first few releases of ntfs-3g fixed the initial performance issues with large files, ntfs-3g was much faster than HDDs anyway. When dealing with a PCIe Gen5 NVME SSD sporting millions of IOPS and a transfer rate in the GB/s range, there could be a speed and/or CPU consumption difference between a kernel space filesystem and a user space filesystem, right. However, it remains to be seen whether the latter isn't good enough for _most users_ on those metrics.

I guess I'll wait for benchmarks to be posted on e.g. Phoronix.

Compelling reasons to switch ?

Posted Jan 29, 2026 15:25 UTC (Thu) by LionsPhil (subscriber, #121073) [Link]

I don't think that really applies when it comes to file system implementations. For the vast majority of users you're not presented with a choice; you're going to get whatever your GUI filer autoselects when you click the icon for the drive, or mount autoselects when you just do "mount /dev/sdb1 /tmp/whatever".

Which is putting the decision in the hands of distro, kernel, util-linux, KIO, whatever-GNOME's-is-called, etc. maintainers. I assume that's going to be more influenced by "which one gets me the fewest severe bug reports?"

Add to that that a lot of filesystem performance pressure comes from the server role, but...hopefully the number of people choosing to use NTFS on Linux servers is small. :D As a reverse-engineered-for-interoperability filesystem, this is more the remit of client systems supporting being able to read that Windows-world external drive you plugged in. And, consequently, at *more* risk of vulnerabilities in the filesystem driver.

(I just wish ntfs-3g supported sparse files. NTFS itself does.)

Compelling reasons to switch ?

Posted Jan 23, 2026 18:23 UTC (Fri) by marcel.oliver (subscriber, #5441) [Link] (7 responses)

I experienced a very "interesting" bug that might well give a compelling reason for a more robust NTFS implementation: A graduate student of mine was doing, fairly recently, a parameter study of some numerical modeling problem. He was controlling the actual simulation (some Fortran code) from a Python script that would first generate a working directory with a deep path, each of the many parameters encoding one level of subdirectories with the actual parameter value going into the directory name. He was running all of this on a mildly beefy departmental compute server, dumping the output onto a big USB hard drive which, no surprise, came formatted with NTFS. For the analysis, he plugged in the hard drive into his laptop and used different Python scripts to read a single data point from each of the simulations for his study. Both server and laptop had some recent Ubuntu, so presumably used ntfs-3g.

Now it turned out that his graphs had strange outliers. On closer inspection, the "outliers" were actually at different locations for different runs of the script, while the data on disk was completely unchanged. Excluding all other rational explanations and given that the nesting of directories was pretty deep and I was not sure that all characters used where actually legal and unambiguous on NTFS, I concluded that this might be a filesystem issue, with the filesystem randomly and quietly mixing up paths. So I advised to simply reformat the drive in ext4 and recompute everything. Immediately, the "outliers" were gone.

I still think we were extremely lucky that ntfs-3g's path resolution was wrong in a non-deterministic fashion, otherwise the problem space would have been much larger and we would likely not have suspected the filesystem as the culprit. But from this experience, I am very reluctant to touch NTFS from Linux in any way.

Compelling reasons to switch ?

Posted Jan 23, 2026 20:26 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (6 responses)

I experienced a very "interesting" bug that might well give a compelling reason for a more robust NTFS implementation ... But from this experience, I am very reluctant to touch NTFS from Linux in any way.

I think the second point is the right one. Having an NTFS driver is cool because it helps with interoperability with Windows systems, but that should be its exclusive use. If every system that's going to use your disk runs Linux, they should use a Linux-native filesystem. This isn't intended as a dig against NTFS, just a comment on the degree of testing the different filesystem code is likely to have.

Compelling reasons to switch ?

Posted Jan 25, 2026 18:21 UTC (Sun) by eru (subscriber, #2753) [Link] (5 responses)

Sadly, interoperability with Windows is a common use-case, and it is bidirectional. I like to archive stuff offline on removable USB HD:s, and wish them to be both readable and writable from both Linux and Windows systems. NTFS is really the only option, because Windows has no up-to-date and well-maintained implementations for any Linux file systems, and FAT just does not cut it any more with today's large files. So all work on better NTFS support in Linux is welcome.

Compelling reasons to switch ?

Posted Jan 25, 2026 19:12 UTC (Sun) by jem (subscriber, #24231) [Link] (4 responses)

ExFAT and UDF are two filesystems that are suitable for removable drives, and can be used to transfer large files between Linux and Windows (and macOS too.)

Compelling reasons to switch ?

Posted Jan 25, 2026 20:10 UTC (Sun) by marcH (subscriber, #57642) [Link] (2 responses)

UDF looks nice in but I'm afraid it's poorly maintained - including on Windows!

exFAT is probably a better choice now.

Compelling reasons to switch ?

Posted Jan 26, 2026 2:08 UTC (Mon) by willy (subscriber, #9762) [Link] (1 responses)

Jan Kara maintains UDF, and I'm not aware of any outstanding problems or patches that are unduly delayed. Sure, there's not a huge flux of patches, but that's to be expected, I think.

It'd be nice if it were converted to use iomap instead of buffer_heads. If anyone's looking for a filesystem project ...

Compelling reasons to switch ?

Posted Jan 26, 2026 9:10 UTC (Mon) by chris_se (subscriber, #99706) [Link]

> Jan Kara maintains UDF, and I'm not aware of any outstanding problems or patches that are unduly delayed.

The main reason for not using UDF as a data exchange format is not the Linux support in my eyes, but the rather non-optimal support on other platforms. Reading from UDF works on other platforms from my experience, but in the past I've had trouble writing to UDF filesystems on Windows - sometimes it just didn't work, with no apparent reason for the failure.

UDF is nice in theory, but in practice exFAT is probably what's here to stay for simple data exchange.

Compelling reasons to switch ?

Posted Jan 25, 2026 20:41 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

ExFAT is not journaled, making it less suitable for something like an internal HDD/SSD that is used to store data on a dual-boot system.

xfs_healer

Posted Jan 23, 2026 18:36 UTC (Fri) by djwong (subscriber, #23506) [Link] (5 responses)

/me notes that xfs_healer is a daemon that will autostart at mount time (if you have systemd) and fix XFS problems in the background if the filesystem is so configured.

For maximum repair abilities, you need to format the filesystem with reverse mapping and parent pointers enabled. This is the default in xfsprogs 6.18; for older versions you can pass “-m rmapbt=1 -n parent=1”. Don't do this if your kernel is older than 6.12; your distributor may not enable online fsck in their kernel configuration.

For self-repair, you also have to enable the xfs_healer_start service (“systemctl enable xfs_healer_start; systemctl start xfs_healer_start”), and set the autofsck property on each filesystem to the value “repair”, either by formatting with “-m autofsck=1” or via “xfs_property <mountpoint or device> set autofsck=repair”. Note that self-repair is still extremely experimental, so don't do this except on a test filesystem that you created by restoring a backup.

Complaints about xfs_healer should be sent to linux-xfs@vger.kernel.org so everyone can see how things are going.

xfs_healer

Posted Jan 23, 2026 19:27 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

> systemctl enable xfs_healer_start; systemctl start xfs_healer_start

FYI, `systemctl enable --now xfs_healer_start` combines these.

xfs_healer

Posted Jan 23, 2026 20:16 UTC (Fri) by djwong (subscriber, #23506) [Link]

That's a neat trick that I didn't know about. Thanks for the info!

xfs_healer

Posted Jan 25, 2026 11:08 UTC (Sun) by jengelh (subscriber, #33263) [Link] (2 responses)

How do xfs.ko and xfs_healer work together ensuring that they do not write data simultaneously? For example when a user just so happens to call /bin/rm mere nanoseconds after the kernel has detected corruption in the same file. Or when xfs_healer relocates a piece of data, that a concurrent "open(blah, O_CREAT)" do not write to the same empty block.

xfs_healer

Posted Jan 26, 2026 16:47 UTC (Mon) by zhaan (subscriber, #177139) [Link] (1 responses)

Not an expert, but my guess is that the operations would happen sequentially and transactionally. Corruption would be fixed (at block level), then the /bin/rm would execute assuming there weren't other block corruption fixes queued. So you would be injecting a /bin/rm into a process queue.

xfs_healer

Posted Jan 26, 2026 16:57 UTC (Mon) by koverstreet (✭ supporter ✭, #4296) [Link]

The actual repair code is in kernel, the userspace code is just a driver - it's not reaching around the kernel code and doing its own thing.

So yes, all the normal filesystem locking applies.

Is NTFS on the way out?

Posted Jan 23, 2026 18:52 UTC (Fri) by epa (subscriber, #39769) [Link] (14 responses)

Better NTFS support is great news. But Microsoft appears to be replacing NTFS with their new filesystem ReFS (Resilient File System), at least for big disks. It might not be true to call NTFS "the standard Windows filesystem format" any longer.

Is NTFS on the way out?

Posted Jan 23, 2026 22:44 UTC (Fri) by garyguo (subscriber, #173367) [Link] (5 responses)

The same can be said in 2016. 10 years later, NTFS is still the default and booting from ReFS is still consider experimental...

Is NTFS on the way out?

Posted Jan 24, 2026 0:09 UTC (Sat) by wsy (subscriber, #121706) [Link]

The same can be said in 2003 when they announced WinFs.

Is NTFS on the way out?

Posted Jan 24, 2026 4:05 UTC (Sat) by djwong (subscriber, #23506) [Link] (3 responses)

Filesystems are hard, XFS is just about finished, and it's been what, 33 years? 😜

Is NTFS on the way out?

Posted Jan 24, 2026 14:30 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (2 responses)

> Filesystems are hard, XFS is just about finished, and it's been what, 33 years? 😜

Has it become better with small files ? I was using it a lot in the past, but I had to abandon it on my laptop for ext4 15 years ago when every git operation on my linux directory would make my disk seek for 30 seconds before completing the operation. However for large files, streaming writes etc it was awesome. I initially started to use it on network probes running tcpdump that would continuously capture traffic on multiple interfaces and store it to disk. Writing and rotating 10GB files was as instant as doing it on a readme with XFS, and I'm speaking about pentium4 with sata1 disks. Also it never failed even once on me, despite not having invoked "halt" nor "shutdown" on a linux machine for the last 20 years, since boot-time journal replay is always faster than a "clean" system shutdown.

On the other hand, ext4 is also good for my use cases nowadays, I'm just not sure if XFS would bring me anything more, or could still annoy me on numerous small files like a kernel source tree.

Is NTFS on the way out?

Posted Jan 24, 2026 21:28 UTC (Sat) by dgc (subscriber, #6611) [Link] (1 responses)

> Has it become better with small files ? I was using it a lot in the past,
> but I had to abandon it on my laptop for ext4 15 years ago when every
> git operation on my linux directory would make my disk seek for 30
> seconds before completing the operation.

Yes, most of major small file/metadata performance issues (in comparison to ext4) were fixed with the introduction of delayed logging in 2.6.36 (i.e. about 15 years ago). That improved transaction rates from being disk bound at a few hundred a second to being CPU bound at tens of thousands of transactions/second.

These days XFS can run a couple of million asynchronous transactions per second through the journal, so highly concurrent workloads are able to scan, create, rename, unlink, etc at rates of over half a million files/second, even on a typical cheap consumer SSDs....

Is NTFS on the way out?

Posted Jan 26, 2026 5:19 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

Good to know, thank you! I'll have to try it again then!

Is NTFS on the way out?

Posted Jan 24, 2026 13:21 UTC (Sat) by willy (subscriber, #9762) [Link] (7 responses)

It looks like Microsoft changed their mind on that in 2017. Support for creating new ReFS volumes was removed from Windows 10, except for Server and Enterprise editions. While all versions of Windows 10/11 can read-write ReFS volumes, it seems that ReFS is not currently slated to replace NTFS.

Is NTFS on the way out?

Posted Jan 24, 2026 17:00 UTC (Sat) by khim (subscriber, #9252) [Link] (6 responses)

It already change it back and Windows 11 can create it and even boot from it.

But after two flip-flops we don't know where would it go next…

It's not like Apple who just said “we are going APFS” and just did that. Granted, HFS+ was a crazy unstable pile of hacks on top of hacks, at this point, thus abandoned it was much easier that for Microsoft to abandon NTFS which is simply bad, not awful.

Is NTFS on the way out?

Posted Jan 25, 2026 20:52 UTC (Sun) by marcH (subscriber, #57642) [Link] (5 responses)

So with ReFS, maybe Windows will be able to delete or even just rename a file in use in 10-20 years time? Who knows, software updates might not take 30 minutes anymore.

Unless Windows first becomes what "DOS" or COBOL is today. Even _gaming_ is under serious threat now, who would have thought?

Is NTFS on the way out?

Posted Jan 25, 2026 22:55 UTC (Sun) by garyguo (subscriber, #173367) [Link] (1 responses)

That was possible for a while now in Windows, when `FILE_DISPOSITION_POSIX_SEMANTICS` is specified to delete a file. I think it is even the default in newer version of Windows.

Is NTFS on the way out?

Posted Jan 26, 2026 5:10 UTC (Mon) by marcH (subscriber, #57642) [Link]

Indeed, it looks like this was changed with very little fanfare:
https://stackoverflow.com/questions/60424732/did-the-beha...

Is NTFS on the way out?

Posted Jan 25, 2026 23:16 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

> Who knows, software updates might not take 30 minutes anymore.

How is that even related? Android and macOS do that, too — and they are not using NTFS.

They all are just using process that is less error-prone (and is actually even recommended by many Linux distributions, just not enforced) instead of giving the user rope and hoping that s/he not hung himself or herself.

Is NTFS on the way out?

Posted Jan 26, 2026 5:15 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

It's related because when you cannot delete files in use then you need to stop, delete and restart processes using the files. And when you are not 100% sure, then you need to restart pretty much everything.

It may not be the only upgrade limitation but it's an important one.

> Android and macOS do that, too

"How is that even related?"

Is NTFS on the way out?

Posted Jan 26, 2026 18:11 UTC (Mon) by Wol (subscriber, #4433) [Link]

> It's related because when you cannot delete files in use then you need to stop,

Or you nick an idea or two from the 80s ... and rename the old file in place so you can replace it.

You still need to reboot to ensure everything is running the upgrade, and then clean up all the old files, but that's not too hard ...

Cheers,
Wol

ZFS status

Posted Jan 25, 2026 17:03 UTC (Sun) by cyperpunks (subscriber, #39406) [Link] (2 responses)

Talking about file systems: what is status of ZFS (on Linux) there days?

ZFS status

Posted Jan 25, 2026 23:30 UTC (Sun) by mbunkus (subscriber, #87248) [Link]

A lot of folks use it commercially with huge success. For example, TrueNAS-the-company makes TrueNAS Scale, their current OS, and it's all based on Linux + ZFS. They also sell hardware with pre-installed TrueNAS (Dell machines if I'm not mistaken). Those NAS devices are quite popular and rock solid. The Linux+ZFS solution is so stable that they decided to sunset their earlier product, TrueNAS Core, which was based on FreeBSD+ZFS in favor of doing the multi-year process of switching the whole thing to Linux+ZFS.

Another example is Proxmox Virtualization Environment, which emerged as the primary winner in VMware's (Broadcom's) ongoing slide to irrelevancy in small & medium deployment sizes. It's Debian + custom Open Source software, and while they support a plethora of file systems the one they support the best & recommend the most for single-server deployments is ZFS.

Neither of those are marked as experimental features, and in the case of TrueNAS it's the raison d'être of the whole company nowadays.

My personal experience with both products and ZFS outside of those as well mrirors what you read elsewhere, too: it works great, has amazing features, and well worth a look for any kind of storage environment.

It's here to stay.

ZFS status

Posted Feb 7, 2026 17:17 UTC (Sat) by zwol (guest, #126152) [Link]

ZFS doesn't have a fsck. (Its "scrub" operation only validates the block checksums, not the consistency of the on-disk data structure.) In this cranky old sysadmin's opinion, that indicates an unacceptable level of hubris among the ZFS developers, and renders the filesystem unfit for production use.

COW and volume management?

Posted Jan 25, 2026 20:45 UTC (Sun) by marcH (subscriber, #57642) [Link] (28 responses)

> As a result, filesystem development in the Linux kernel continues at a fast pace even after all these years.

Except... for "modern" COW filesystems with snapshots and volume management built-in?

Like this one: https://illumos.org/books/zfs-admin/gbcik.html
Or this one: https://en.wikipedia.org/wiki/Apple_File_System

Is btrfs progressing and its advanced features getting better reliability and reputation? Genuine question.

COW and volume management?

Posted Jan 26, 2026 8:50 UTC (Mon) by jmalcolm (subscriber, #8876) [Link] (27 responses)

Btrfs is getting better but not everybody trusts it yet.

A file system which is already excellent but massively controversial for non-technical reasons is bcachefs.

It is great but the dev got it kicked out of the kernel. So you have to build it in yourself or using DKMS.

COW and volume management?

Posted Jan 26, 2026 11:22 UTC (Mon) by koverstreet (✭ supporter ✭, #4296) [Link] (18 responses)

The split with the kernel needed to happen, unfortunately. Since then things have been massively smoother and my life has been much less stressful. Project's been growing, people are migrating and the focus is back on the technical.

The reasons for that split being a topic for another conversation, because I'm just drinking my coffee and enjoying a nice drama free day, and hoping to keep it that way, thank you very much :)

I should have erasure coding ready for testers inside of a week, I deferred the announcement lifting the experimental label to get that done due to popular demand (and post reconcile, there really wasn't much left). Gonna have some very cool stuff coming out this year - our ability to manage large numbers of drives is turning into something next level.

And we've got all the self healing stuff, complete and thorough fsck - and image creation tools that produce images on par with what EROFS can do.

But the thing that excites me the most is how debuggable the system is.

COW and volume management?

Posted Jan 27, 2026 8:15 UTC (Tue) by drago01 (subscriber, #50715) [Link] (17 responses)

Being out of tree means it has to compete with ZFS. If someone goes through that pain, why not just use ZFS?

COW and volume management?

Posted Jan 27, 2026 9:00 UTC (Tue) by taladar (subscriber, #68407) [Link] (14 responses)

I can't speak for others but ZFS very much feels like a project that has peaked and has wasted a lot of its potential on that whole licensing fight. Any desire to even try it has been gone for many years at this point and the ZFS hype was another very off-putting thing about it.

Plus, on a purely technical level, I am sure ZFS, being the first of this type of file system has many design flaws that could be improved starting from scratch a generation later, much like any technology that tries something new and then gets stuck supporting existing behavior and design decisions as it gains users. Filesystems are probably affected by that more than most given that they deal with data at rest and not just some ephemeral data like e.g. network protocols.

COW and volume management?

Posted Jan 27, 2026 9:55 UTC (Tue) by marcH (subscriber, #57642) [Link] (4 responses)

I tried it only briefly but the concepts and user interface looked better than everything else I knew at the time. Very impressive.

It has real, "big iron" users too and they seem generally pretty happy too.

I have not researched it extensively but I don't remember hearing about any serious issue with it.

> and the ZFS hype was another very off-putting thing about it.

How do you know it was hype? I don't think any company tried to promote it, or at least not recently...

> I am sure ZFS, ...

"sure" without ever trying it? What is this based on?

> ... being the first of this type of file system has many design flaws

Maybe you could find and list at least one flaw?

> ... that could be improved starting from scratch a generation later, much like any technology that tries something new and then gets stuck supporting existing behavior and design decisions as it gains users.

Again, not an expert but I try to stay informed and so far it seems like other filesystems are still playing catch up...

> wasted a lot of its potential on that whole licensing fight.

Agreed, a real pity. That could almost make you wish it's also bad technically :-)

COW and volume management?

Posted Jan 28, 2026 8:33 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

I did actually try it once for a little while in the early days when the hype was at its peak. From what i remember the ZFS design had some issues around requiring huge amounts of kernel memory which presented a big problem for alternate implementations even on license compatible systems like the BSDs and it quickly ran out of memory on systems with the 2GB of RAM that were still common at the time. Overall I was not very impressed, especially since 90% of its supposed advantages are meaningless on the small scale of just 2-4 disks or so that you might have in a typical home system.

COW and volume management?

Posted Feb 5, 2026 17:27 UTC (Thu) by georgh-cat (guest, #158897) [Link]

Is that memory issue something you experimented yourself?

I had a 750GB mirror running on OpenSolaris at home on 2008 (still using ZFS today and that pool was migrated once to 4TB disks), and I was afraid of the memory thing.

It was never an issue. Even when approaching full disk capacity, never had the memory usage be anywhere near high or even a potential problem. Then had the same server migrated to FreeBSD (OpenSolaris not being maintained anymore) and same experience.

If there ever were memory issues, I was somehow not affected or it was a myth or misunderstanding of how it worked.

COW and volume management?

Posted Feb 5, 2026 12:38 UTC (Thu) by anton (subscriber, #25547) [Link]

How do you know it was hype?

The kind of fearmongering used for selling ZFS was really off-putting. One supposedly-relevant scenario that ZFS defends against is when a HDD writes a block to the wrong disk sectors. This scenario has never happened in my experience, and the way HDDs work, it cannot happen in the way that the scenario suggests (by the read-write-head arm moving to the wrong track without any additional hardware failure).

That being said, we have used ZFS on many machines since about 2019 (mainly because it was not clear at the time whether RAID1 works well on btrfs), it works nicely. The only downside I see in it is that it is its own universe that ignores things like /etc/fstab and you need to learn the ZFS terminology even for terms that have a correspondence outside the ZFS universe. Another downside I read about is that ZFS supposedly does not utilize RAM as well as native Linux file systems which make better use of the buffer cache or somesuch. We certainly see little free RAM on our machines with ZFS. That's why I have decided to go for btrfs again for one machine recently.

COW and volume management?

Posted Feb 7, 2026 7:53 UTC (Sat) by cypherpunks2 (guest, #152408) [Link]

> Maybe you could find and list at least one flaw?

ARC is not well-integrated with the rest of the memory management system, so the system can OOM before ARC detects memory pressure and shrinks itself (so it's more than just an "ARC presents itself as used memory which confuses people" UI issue).

The cache for mapped files is unnecessarily duplicated in both ARC and the page cache.

There's still no support for defragmentation, which is an issue on high-speed IOPS-limited NVMe drives as CoW filesystems tend to experience heavy fragmentation.

COW and volume management?

Posted Jan 27, 2026 11:12 UTC (Tue) by koverstreet (✭ supporter ✭, #4296) [Link] (8 responses)

> Plus, on a purely technical level, I am sure ZFS, being the first of this type of file system has many design flaws that could be improved starting from scratch a generation later, much like any technology that tries something new and then gets stuck supporting existing behavior and design decisions as it gains users. Filesystems are probably affected by that more than most given that they deal with data at rest and not just some ephemeral data like e.g. network protocols.

"Flaws" isn't a fair characterization; the approach the ZFS devs took was a pragmatic one, and the only one that had any chance of success given the scope of what they were trying to do.

When you're trying to do something ambitious, you don't shoot for the moon - you can't reimagine everything at once, you can't take on too many big risks, that's how you get stuck in second system syndrome; you'll never complete your task. You have to work incrementally, and pick and choose what you're going to reimagine and what risks you're going to take.

But - that does mean that ZFS is essentially the original Unix filesystem underneath. Blocks, not extents, and data structures that are clearly in that lineage.

bcachefs is that "shoot for the moon and reimagine everything" project. It only happened because I got profoundly lucky with some of the original key design decisions (the b-tree implementation in particular), and for the first five years I wasn't attempting a full filesystem - I had much smaller targets (a block cache, and then something more intermediate) where I was able to successfully complete and ship building blocks for the full filesystem; it wasn't until those were successful that I realized attempting a filesystem was even possible.

So in a way you're right, but don't sell the ZFS folks short - they deserve massive amounts of credit and respect for showing everyone what a modern filesystem should be capable of.

And there's a whole list of things that took years to crack before I had something better:

- Snapshots: snapshots + extents are a difficult combination, Dave Chinner and others were poking me about this for years before I had a working design (I've got notebooks filled with scribbles of different ways of solving the "extents can overlap in arbitrary ways" problem).

- fsck/self healing: bcachefs benefited massively from the hindsight of seeing what other filesystems were doing, and just having a lot more time to get it done. Going straight for full self healing and skipping a conventional fsck does not get you what you want, nor does just starting with a conventional offline fsck. I had experience with proto-runtime-fsck from the early days immediately after bcache, and time to explore a lot of different options; bcachefs takes a mixed approach that's turned out to be very comprehensive, but that took a lot of time to get right.

- The erasure coding design is entirely original; it delivers much better performance than RAIDZ but had many difficult problems to solve over years of development (it all looks simple in hindsight, but it wasn't simple to figure out when it hadn't been done before!).

- The whole "filesystem that really is a database underneath" approach has always been the dream - having that makes my life so much easier now. (Was working on the last bits of hooking up erasure coding to reconcile last night for automatic resilvering when a drive goes away, when I realized the on disk data structures were wrong; when using the reconcile_*_phys btrees for doing pending work in on-disk LBA order on rotating disks, we can't mix that in with the pending work for user data extents; we need to repair stripes first; _then_ user data extents to get anything that wasn't erasure coded, or we'll do a ton of unnecessary work; oh damn, that was a whole 10 lines of code to fix). But no existing b-tree implementation was remotely fast enough, even today - that was the big one that I cracked 15 years ago, with design decisions that look prescient in hindsight, and then benchmarking bcache on early Google SSDs when we realized "oh damn, binary search is actually really slow" and pulling math out of the ether to do magic with eytzinger search trees...

COW and volume management?

Posted Jan 27, 2026 12:45 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

> - The whole "filesystem that really is a database underneath" approach has always been the dream - having that makes my life so much easier now.

Wowser! And that's moving into the mainstream now? Again, massive kudos to you if you've managed to pull it off, but that's been around for ages.

I hesitate to say it was true of Pick - it was sort of - but that was more "the storage system is permanent virtual memory". The AS400 had a database as a filesystem, no? And there were loads of rumours that NTFS was originally going to be a derivative of the Pick database - that was back in the days of NT3.1 whenever that was.

"If I can see so far, it's because I'm standing on the shoulders of giants" - but you're a giant yourself for pulling it off!

Cheers,
Wol

COW and volume management?

Posted Jan 27, 2026 13:15 UTC (Tue) by koverstreet (✭ supporter ✭, #4296) [Link] (3 responses)

Yup.

We're not using it to do anything particularly novel yet, just doing normal filesystem stuff but done better and more cleanly, so far. And it's still not quite as general as I want; the main remaining limitation is that keys are fixed size at 160 bits (64 bit inum, 64 bit offset, 32 bit snapshot); key types really need to be per-btree definable, bpos has been increasingly overloaded in different places and it's annoying.

It's also definitely nowhere near SQL, where you define tables and indexes and do joins; it's more of a NoSQL database. But it's got a solid transaction model, locking model (with a full cycle detector, as real databases do), triggers, nice iterators, lots of support for extending the database schema - it's generally quite pleasant to work with.

The challenge with making this stuff mainstream has been performance. Historically, Unix filesystems were completely unlike databases because they needed to be simple and fast - inodes as flat arrays on disk, blocks indexed by radix trees hanging off the inodes. Lots of simple specialized data structures.

Bu conventional filesystems have started to look more and more like databases over the years as they've gotten more complex. Extents mean radix trees don't work anymore, you need btrees, journaling means you need a transaction model, and every additional feature filesystems want to do pushes you more in the direction of "I really just want a real general purpose database for this stuff".

The game changer was when, in the early days of bcache, we pushed the performance of the "btree with big log structured nodes" design to the point where it could support a filesystem with no per-inode sharding - that was when I knew bcachefs was possible.

COW and volume management?

Posted Jan 27, 2026 13:45 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

> We're not using it to do anything particularly novel yet, just doing normal filesystem stuff but done better and more cleanly, so far. And it's still not quite as general as I want; the main remaining limitation is that keys are fixed size at 160 bits (64 bit inum, 64 bit offset, 32 bit snapshot); key types really need to be per-btree definable, bpos has been increasingly overloaded in different places and it's annoying.

> It's also definitely nowhere near SQL, where you define tables and indexes and do joins; it's more of a NoSQL database. But it's got a solid transaction model, locking model (with a full cycle detector, as real databases do), triggers, nice iterators, lots of support for extending the database schema - it's generally quite pleasant to work with.

Don't confuse SQL and Relational, they're two completely separate things in a marriage :-)

And you say "NoSQL" - do you mean No SQL, or Not Only SQL? :-) (I'm sure you don't mean the database actually called "NoSQL" :-)

But it might be worth taking a look at Pick's Not Only SQL model. I don't understand what you're going about key types and btree especially, but Pick is hash-based not btree based. Investigate Linear/Dynamic hashing. That swaps btree's "all accesses take the same time" for hashing's "most accesses are extremely fast" and the linear/dynamic algorithm makes resizing order 1, not order N. I've been thinking about making ScarletDMEs hash buckets into btrees so in the worst case access degrades to btrees ?order root N? rather than a naive hash's order N. (And speeds up splitting an overflowed bucket, too.)

But if you're looking at "the file system is a database", don't restrict yourself to SQL/Relational. Just because it's taken the universities by storm so that nobody knows anything else, doesn't mean it's the best, or even has any ideas worth nicking :-)

Cheers,
Wol

COW and volume management?

Posted Jan 27, 2026 15:07 UTC (Tue) by koverstreet (✭ supporter ✭, #4296) [Link] (1 responses)

SQL may not be the prettiest language, and the relational model may not be what you want in every context - it's too abstracted when you really need to optimize for performance - but there's a reason it's taught, it's a good model, and it's something every programmer should probably know.

Hash tables are no-go in on disk data structures, they destroy locality and you can't do range lookups. Extents require range lookups, along with a lot of other things filesystems need to do, and we very frequently need to do efficient scans - btrees are much better suited to that.

Locality is a prime consideration when designing on disk data structures, and frequently you'll be doing short linear scans - linear searches are not slow as long as you keep them short.

E.g., the way bcachefs does full writeable snapshots, with versioning (so snapshots are at key granularity, not btree node granularity like btrfs) uses the low bits of the key as the snapshot ID - so a lookup finds either a key in the current snapshot, or an ancestor snapshot - that requires range lookups. But then for writeable snapshots, the snapshot ID is not a linear history, it's a tree; so we also have to skip over keys in unrelated branches of the snapshots tree. This search will be short for a variety of reasons (the main one being that creates always get a new inode number that won't be shared by any other snapshots), so snapshot lookups are fast; you can't do these kinds of tricks with hash tables.

COW and volume management?

Posted Jan 27, 2026 21:02 UTC (Tue) by Wol (subscriber, #4433) [Link]

> SQL may not be the prettiest language, and the relational model may not be what you want in every context - it's too abstracted when you really need to optimize for performance - but there's a reason it's taught, it's a good model, and it's something every programmer should probably know.

The relational *model* is great, yes. The engineering is flawed by design :-(

Pick allows you to stick a 4NF view directly into the database as a table row ... that's why an optimiser is a waste of time ... (now that most RDBMSs have arrays and structures, they've finally caught up, 40 years late, but SQL can't query them cleanly)

Cheers,
Wol

COW and volume management?

Posted Jan 27, 2026 13:59 UTC (Tue) by malmedal (subscriber, #56172) [Link] (2 responses)

> But - that does mean that ZFS is essentially the original Unix filesystem underneath.

what? ZFS is a log-structured filesystem, like e.g. Sprite LFS and NetApp WAFL. Very different tradition from the old modify-in-place unix filesystem.

COW and volume management?

Posted Feb 5, 2026 13:26 UTC (Thu) by intelfx (subscriber, #130118) [Link] (1 responses)

> what? ZFS is a log-structured filesystem, like e.g. Sprite LFS and NetApp WAFL.

It's not a log-structured filesystem, it is a write-anywhere-*ish* (but not really) kind of filesystem with a log (journal) hanging off its side for performance.

Very different things.

The core concept underpinning DMU is still just a (potentially recursive) map of blocks. That is the "original Unix filesystem". It's just ext2 with (admittedly, a lot of) extra steps.

COW and volume management?

Posted Feb 5, 2026 16:05 UTC (Thu) by malmedal (subscriber, #56172) [Link]

> it is a write-anywhere-*ish* (but not really)

ish? Fully I believe. The only exception to write anywhere I am aware of is the uberblock. IIRC you basically have two logs, one for the uberblock only and one for everything else.

I believe NetApp does the same thing, the root inode, just like ZFS's uberblock, is constrained to a few known locations to avoid having to read every byte on every disk on a cold start.

> (but not really) kind of filesystem with a log (journal) hanging off its side for performance.

No, both metadata and data are always written to a new location when updated. There is no update in place neither in ZFS nor in NetApp WAFL.

COW and volume management?

Posted Jan 27, 2026 10:46 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

bcachefs doesn't have the licensing issue and, if and when it's mature and trusted, it'll (hopefully) be a no-brainer to have it merged back in to upstream.

COW and volume management?

Posted Jan 27, 2026 12:12 UTC (Tue) by koverstreet (✭ supporter ✭, #4296) [Link]

No, it won't be a no brainer -

I've always believed in "just write the best code you can - the rest will sort itself out later". Not being upstream hasn't hurt the project at all - on the contrary, if anything adoption has accelerated over the past six months. We're no longer tied to a project with engineering practices that haven't changed much over the past 20 years, and right now I'm wondering how the kernel is going to manage the Rust transition over the next 10-20 years.

At some point, the broader engineering community is going to realize that all the code we depend on - essentially, all of it - is going to have to be rewritten in Rust. The level of complexity we can manage in C has been hitting limits; we cannot keep doing the same old forever. Systems engineering is going to get so much easier if we can manage the Rust transition, and there are so many techniques in debugability, introspection, static analysis and formal verification that that opens up. There is a mountain of work that needs to happen to get there - but it needs to happen, or we'll be stuck with a mountain of legacy code in a language new people aren't learning with the people that actually understand it dying off.

To understand how this impacts myself personally and the bcachefs project: my rule of thumb is that when a bug in upstream, non-bcachefs kernel code comes across my desk (and they do), it's going to take at least 10 times as long to debug as any bcachefs bug. And I'm going to be stuck with it personally; there are people who have been tearing through the bcachefs code and can debug anything (literally; I'm half-following the IRC channel right now) and will tell me exactly what's broken and what needs to be fixed - and I'd be more than comfortable just giving commit access to the repo but they seem to like using me as the coding bot - but when it's an mm-involved bug or anything else I'll hear back a week later - "uhh, maybe you better take this one on".

There's ways to write complex code and make it testable and debugable, but it has to be an object of serious study, you have to prioritize it. Fortunately, Rust is going to make this a hell of a lot easier, with things like the Display trait, and a type system that's comprehensive enough that you don't have to stare at code for a couple hours in order to safely change one little thing - but "how to write complex systems that we can maintain and debug in the wild" is something that needs more thought and study in the kernel community.

So I'll be taking a wait-and-see approach. I have seen some positive developments over the past six months - people who weren't finally seem to be talking somewhat more seriously about automated testing, and that's been a huge gap that was really painful for bcachefs (my test dashboard would blow up every rc1 rebase with bugs in other subsystems, and I can't do work or merge code without good test data, so all work would stop - often for weeks - while dealing with that). But I think things have a ways to go before I could seriously consider it - and that's if they even wanted bcachefs in the kernel, and I think everyone knows the rough outline of that part of the story :)

COW and volume management?

Posted Jan 28, 2026 10:40 UTC (Wed) by Lennie (subscriber, #49641) [Link] (7 responses)

"Btrfs is getting better but not everybody trusts it yet."

Every time I test it, it fails, when I report it on the mailinglist I got no response, I stopped testing it a few years ago.

My test was:

create a VM with 2 disks, set up RAID1 for meta and data, etc.

Scrub and sync them, shutdown the VM, remove disk one and start it again, it usually runs.

Shutdown the VM, connect second disk again.

Start VM and scrub and sync to make sure they are the same again.

Shutdown VM, remove first disk and start VM

Failed. The first time I do this it might work and it would fail on the second time I did the whole cycle again.

A scrub/sync should make sure all the data is on the second disk, why does it fail such a simple test ?

Or is this now fixed ?

COW and volume management?

Posted Jan 28, 2026 11:17 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link] (5 responses)

You might give bcachefs a try. And if you do run into issues, there's a lot of activity on the IRC channel, and we really try to stay on top of bugs and make sure things are working for people.

COW and volume management?

Posted Jan 28, 2026 12:57 UTC (Wed) by koverstreet (✭ supporter ✭, #4296) [Link] (4 responses)

Also, I should say a bit about methodology when there's issues, for new people jumping into bcachefs.

The expectation isn't that things will be 100% perfect; it's a > 100k loc codebase. You do want your filesystem to be as close to perfect as humanly possible - but developing perfect code in isolation and then releasing it to the world, that isn't possible at the scale we're talking about. There will always be issues, people will always be trying out new and unexpected things, even when it's 100% stable for the situations it was originally developed. We're always pushing boundaries and trying new things, especially as the userbase ramps up.

It's much more important to me that code be debugable than that it be perfect; when something breaks, error messages should be clear enough that even end users can get a decent idea of what went wrong, and the introspection and other debugging facilities need to be complete, thorough and easy to use so that mere mortals can debug in the field.

That's how we make this sustainable, when there aren't enough developers to go around, and that's how we share the load and build up the community and make complex systems understandable and usable.

And we've got a solid community of people who are knowledgable about the system and interested in making sure it works for people - so if you run into issues, you should be able to get answers, especially if you're willing to pay that forward and help the next person out.

COW and volume management?

Posted Jan 28, 2026 23:31 UTC (Wed) by neggles (subscriber, #153254) [Link] (3 responses)

It's really nice to see you sticking to saying positive things about bcachefs, rather than being negative about other filesystems; seems like you're much happier these days :)

COW and volume management?

Posted Jan 29, 2026 1:20 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

Engineering isn't a "good vibes only" club. We have to be able to talk about and understand past mistakes if we want to improve and do better, and sometimes the "what not to do" are really important lessons.

So I can and do talk about that stuff when it's relevant, and no doubt will again.

If you want to avoid the tensions and the drama, the way for that to happen is for everyone to be taking responsibility for their work and responding to the challenges that are arising, because we all depend on each other.

COW and volume management?

Posted Jan 29, 2026 15:30 UTC (Thu) by neggles (subscriber, #153254) [Link] (1 responses)

I completely agree; maybe I should've said "being unnecessarily negative", my bad.

COW and volume management?

Posted Jan 29, 2026 16:08 UTC (Thu) by koverstreet (✭ supporter ✭, #4296) [Link]

That can be hard one to categorize :) Some people may think everything is fine, and maybe they're right, maybe they're not - and it may not be clear until it's too late.

But I do not think you can look at the kernel community's track record on filesystems and call it a smashing success. There are lessons I think the community has yet to learn. When you see me talking harshly about those things, it's not because I'm trying to be negative or tear the place down - but sometimes people do need tough love.

That thing that makes me happy is just when I see that people are learning, or at least willing to learn. All problems are solvable - in engineering, and programming especially - as long as we're facing up to them.

But yeah, I am happier since the split, and watching the bcachefs community grow and turn into something really special has been a big part of that.

COW and volume management?

Posted Feb 5, 2026 12:55 UTC (Thu) by anton (subscriber, #25547) [Link]

I have done a similar test around 2018, and what we tried, worked (although recovery after a drive failure requires (required?) extra effort). We have been using btrfs in RAID1 configuration since then without problems. I had been using btrfs earlier (starting around 2013 or so) on laptops without RAID1 without problems.