Learn Linux Filesystem - Modern Features & Roadmap

#Introduction

No technology is static — including filesystems. Episode 20 looks forward: features that just matured, and development directions already readable from project roadmaps. Understanding this direction helps you make architectural decisions that don't become obsolete quickly.

We cover modern features from the two most dynamic filesystems — block-group-tree and ref feature flags from btrfs, BRT dedup and AnyRaid from ZFS — then the role of NFS/CIFS as the network filesystem layer, and finish with the btrfs-progs 8.x and OpenZFS 2.5/2.6 roadmaps, plus integration with new hardware.

For those planning long-term storage, this episode is your radar.

#Modern btrfs Features

#Block-Group-Tree as Default

Block-group-tree, which we covered in episode 13, has been the default since kernel 6.19. It's not just a small optimization — it changes the block allocation architecture so large, nearly full filesystems don't slow down.

Check whether your kernel supports it:

uname -r
btrfs-progs --version

Kernel 6.19+ and btrfs-progs 6.12+ support block-group-tree as the default.

#ref Feature Flags

btrfs uses feature flags for compatibility. Flags prefixed with ref- relate to block reference accounting:

• ref_verify: reference verification — lets debug tools check block reference consistency.
• ref-verify and its companion flags give visibility for detecting block leaks (space leaks).

View the active flags on a filesystem:

sudo btrfs inspect-internal dump-super /dev/loop0 | grep -E "compat|flags"

The output shows incompat_flags including the installed features. These features let the on-disk format evolve without breaking old filesystems.

#Modern ZFS Features

#BRT Dedup and AnyRaid

Two big OpenZFS 2.4 features already covered in episode 14 return to the radar because both define the long-term direction:

• BRT (Block Reference Table): deduplication with small overhead — opening up dedup for workloads previously avoided because of memory.
• AnyRaid: flexible parity layouts — making RAIDZ configurations no longer rigid.

Check pool capabilities:

zpool get version,feature@block_cloning labpool
zfs version

#Feature@block_cloning

Another feature worth watching is block cloning — copying blocks between datasets without reading and rewriting physical data. This speeds up clone and copy operations inside the pool:

zpool get feature@block_cloning labpool

Block cloning is ZFS's step toward more efficient data management — almost no data is physically copied unless necessary.

#Exabyte Scale and 256-bit Pointers

#Why ZFS Differs at Scale

ZFS was designed with 256-bit pointers from the start — something ext4 and XFS don't have. As a consequence, ZFS's theoretical capacity limits sit far above anything today's infrastructure can imagine:

ext4  : 1 exabyte (max filesystem 16TB di praktik 64-bit)
XFS   : 8 exabytes (16EB di praktik)
ZFS   : 256 quadrillion zettabyte (pointer 256-bit)

Why does this matter? Because your data outlives hardware — and the filesystem chosen today must still be readable even if storage capacity jumps by several orders of magnitude in the future.

#Practical Implications

For today's practical needs, all modern filesystems are sufficient. But for projects planned 10-20 years ahead (national archives, scientific data), ZFS's 256-bit range is an advantage neither ext4 nor XFS can match.

#NFS and CIFS: The Network Filesystem Layer

#Network Filesystems

NFS and CIFS/SMB aren't on-disk filesystems — they're protocols that make a host filesystem available over the network. Their role differs from ext4/ZFS:

• NFS: the Unix standard for networked file access — used by EFS and Filestore (episode 19).
• CIFS/SMB: the Windows standard, used by Samba on Linux for cross-platform file sharing.

Mount NFS and CIFS:

sudo mount -t nfs4 server:/share /mnt/nfs
sudo mount -t cifs //server/share /mnt/cifs -o username=user,vers=3.1.1

mount -t nfs4 connects a client to an NFS server; the network hides whatever filesystem exists on the server side — ext4, XFS, ZFS, they all look the same to the client.

#The Position of Network Filesystems

Network filesystems occupy a different layer than local filesystems:

• They provide shared access — multiple hosts accessing the same data.
• They don't replace local filesystems — they're built on top of them.
• They add a layer of latency and network failure.

Understand the order: local filesystems store physical data → NFS/CIFS expose it to the network → applications see it as a regular directory.

#Roadmap and New Hardware

#btrfs-progs 7.x → 8.x

The development direction of btrfs-progs:

• 7.x (v7.1 at the time this series was written): check improvements, more mature btrfs property.
• 8.x: a more stable remap tree for partial block COW, plus full block-group-tree integration.

The remap tree is the key to COW efficiency's future: it allows partially splitting shared blocks — reducing space waste on partially modified snapshots.

#OpenZFS 2.5 and 2.6

After 2.4, OpenZFS's direction includes:

• 2.5: refinements to AnyRaid and BRT, further uncached IO tuning.
• 2.6: optimizations for new hardware and performance refinements.

To keep track, check the official release page at openzfs.org and zfs version:

zfs version

#NVMe, CXL, and Emerging Storage

Filesystems must follow hardware:

• NVMe: deep parallel queues — none scheduler and high queue depth.
• CXL (Compute Express Link): shared memory and storage mapping — an area where dax and PMEM (episode 12) will find a bigger role.
• Persistent memory: byte-addressable access that blurs the line between RAM and disk.

This is why features like dax, block cloning, and remap tree are appearing now: they prepare filesystems for the next generation of storage.

#Conclusion

Modern Linux filesystem features aren't just a list of additions — they tell a direction: allocation efficiency (block-group-tree), cheap dedup and clones (BRT, block cloning), unlimited scale (256-bit pointers), and integration with networks and new hardware. Understanding this direction makes your choices last longer.

Key takeaways:

• btrfs block-group-tree is the default since kernel 6.19; ref-* feature flags maintain compatibility.
• BRT dedup and AnyRaid define ZFS's direction; block cloning speeds up in-pool copies.
• ZFS's 256-bit pointers give capacity limits far beyond ext4/XFS.
• NFS/CIFS are the network layer — hiding the filesystem on the server side.
• Roadmap: btrfs-progs 8.x with remap tree, OpenZFS 2.5/2.6.
• New hardware (NVMe, CXL, persistent memory) shapes the features under development.

In the next episode, episode 21, we cover production hardening — making sure journal and checksums are active, strict mount options for /tmp, quotas and limits, RAID plus snapshot plus offsite backup, UPS for COW filesystems, and fsck ordering at boot. You'll build layered defense for production.