Yesterday we inspected XFS, SGI’s filesystem that refused to retire.

Today we inspect a filesystem that wanted nearly every modern feature at once and then discovered that the kernel is also a political institution.

bcachefs began with the bcache lineage: the practical problem of using fast SSDs to cache slower storage.

Then it grew into something larger:

a copy-on-write filesystem for Linux with checksumming, compression, encryption, snapshots, reflinks, multi-device support, and data placement machinery.

This is not a small promise.

This is a five-year plan wearing a superblock.

I. The Feature Hunger

Modern users look at filesystems and ask rude questions:

“Where are my checksums?”

“Where are my snapshots?”

“Can I use several devices?”

“Can I compress data?”

“Can I encrypt it?”

“Can hot data live on fast storage and cold data live in the cheap provinces?”

bcachefs tries to answer many of these at once.

Feature	Why people want it
copy-on-write	safer updates and snapshots
checksumming	detect corruption instead of trusting disks
compression	save space, sometimes improve I/O
encryption	protect data at rest
snapshots	preserve point-in-time views
multi-device support	pool and place data across devices
caching/tiering	use fast devices where they matter

The danger of many features is not that features are bad.

The danger is that every feature wants to touch recovery.

Recovery is where design debts send invoices.

II. Copy-On-Write And Checksums

Copy-on-write means modified data is written to a new location before metadata is updated to point at it.

This can make crash consistency and snapshots easier to reason about.

Combined with checksums, it can also detect whether the data read from disk is the data that was written.

old extent remains valid
write new extent
write checksum
update metadata transaction
old view can still exist as snapshot

The old update-in-place style is faster to explain:

overwrite block
hope power does not fail at the funniest possible moment

The Republic does not design systems around hope.

Hope is not a write barrier.

III. Filesystem As Database

The bcachefs documentation describes two large themes:

copy-on-write and filesystem-as-database.

The second phrase matters.

Instead of treating every metadata type as a separate hand-built shrine, bcachefs leans into Btrees and key/value-style structure.

metadata tables:
    extents
    inodes
    directory entries
    allocation records
    backpointers
    snapshots

The dream is unified transactions over rich metadata.

The nightmare is that unified machinery must be correct in more situations than any one human wants to imagine.

Design goal	Engineering consequence
unified metadata model	fewer special-purpose structures
rich transactions	complex correctness requirements
repairability	metadata must be cross-checkable
snapshots and reflinks	reference tracking becomes serious
multi-device support	placement and recovery become political

Filesystems are databases with dirtier boots.

bcachefs admits this out loud.

IV. The Tiering Origin

The name is not decorative.

bcachefs grew from bcache ideas about combining fast and slow storage.

The official getting-started examples still show tiered setups:

bcachefs format /dev/sd[ab]1 \
    --foreground_target /dev/sda1 \
    --promote_target /dev/sda1 \
    --background_target /dev/sdb1

mount -t bcachefs /dev/sda1:/dev/sdb1 /mnt

The idea:

• fast device handles foreground writes
• hot data can be promoted
• slow device carries background capacity

This is not merely a filesystem.

It is logistics.

And as every railway minister knows, logistics is where ideology becomes steel.

V. Linux 6.7 And The Mainline Moment

bcachefs entered the Linux kernel in the Linux 6.7 cycle.

That was a major milestone.

It meant users could look at the mainline kernel and see a new ambitious filesystem standing beside the older powers.

But mainline is not only code inclusion.

It is maintenance discipline.

It is review culture.

It is release timing.

It is the sacred art of not surprising Linus during a release candidate.

Technical problem	Social problem
code correctness	review trust
repair behavior	maintainer confidence
feature velocity	release discipline
user data safety	public support burden
kernel integration	communication style

The filesystem stores bytes.

The kernel stores grudges.

Both must be kept consistent.

VI. The DKMS Turn

As of the bcachefs project’s current documentation, bcachefs is no longer distributed with the kernel starting with Linux 6.18 and is shipped as a DKMS module.

This is a significant operational fact.

It does not mean the design ideas evaporated.

It means the support path changed.

old expectation:
    kernel source includes bcachefs
    distribution kernel may enable it

new project distribution:
    bcachefs-tools
    bcachefs-dkms
    external module build against supported kernels

That changes how cautious administrators should be.

Out-of-tree modules can be useful.

They can also make kernel upgrades into negotiations.

The Republic prefers negotiations where root filesystems are not the hostage.

VII. Where It Fits

bcachefs occupies a strange but important territory.

It is not ext4.

It is not XFS.

It is not ZFS.

It is not Btrfs wearing a different hat.

Filesystem	Personality
ext4	boring default survival
XFS	large-scale throughput veteran
ZFS	checksummed storage state with a navy
Btrfs	copy-on-write Linux ambition with scars
bcachefs	modern feature consolidation with ongoing politics

The correct posture is neither worship nor dismissal.

It is evaluation.

Use test machines.

Read repair documentation.

Understand upgrade paths.

Do not let a feature matrix seduce the only copy of your data.

VIII. The Suppressed Pyongyang Account

Official history says bcachefs came from bcache, developed into a modern copy-on-write filesystem, entered Linux 6.7, and later moved to DKMS distribution.

The classified account says the original requirements were discovered in a sealed cabinet near Pyongyang:

New filesystem shall include:
    all features
    all checksums
    all devices
    all compression
    all encryption
    no meetings

The first five lines were ambitious.

The sixth line was fantasy.

No filesystem escapes meetings.

Especially not one carrying user data.

IX. The Lesson

bcachefs is valuable even if you never format a disk with it.

It shows what modern users expect from storage.

It shows how hard it is to combine those expectations.

It shows that filesystem engineering is not merely algorithms and block addresses.

It is recovery.

It is maintenance.

It is trust.

And trust, unlike a snapshot, cannot be created instantly.

— Kim Jong Rails, Supreme Leader of the Republic of Derails