Your expert guide to cybersecurity and digital privacy.
Security hardening for all platforms : Windows, macOS, Linux, and Android.
Solutions aligned standards : NIST and ANSSI for comprehensive digital protection.
The Linux file system landscape has undergone major upheavals with the release of kernel version 6.18. Bcachefs has been removed from the mainline kernel, ReiserFS has been officially removed, and security standards have evolved. In 2026, choosing a file system is no longer just about performance: intrinsic security, maintainability, and migration strategy have become determining criteria.
🔍What this guide covers— 4 essential pillars
32 FS
Security
Migration
Sources
Content
The SafeITExperts ObservationOBSERVATION
On forums and in production, a recurring pattern has been identified: administrators choose a file system based on popularity without evaluating its actual kernel status or its intrinsic security level.
What we observe too often
# Inefficient cycle observed:Step 1 → Choose a FS based on popularity
Step 2 → Discover post-deployment that it is obsolete
Step 3 → Attempt an urgent migration
Step 4 → Lose data or time
# Result: instability, hidden costs, loss of trust
💡 This cycle is not inevitable. It results from a lack of an evaluation framework before deployment.
Specific Stakes for 2026CONTEXT
Several factors make this guide particularly relevant this year:
Critical Evolutions of Kernel 6.18+
# Major changes:🔴 Bcachefs → Removed from mainline kernel (Sept. 2025)
🔴 ReiserFS → Permanently removed (Kernel 6.13)
🟠 ext3 → Driver removed, mounted via ext4 only
🟢 btrfs → Consolidated as a modern alternative
🟢 XFS V5 → Mandatory format, V4 deprecated
# Impact: yesterday's choices are no longer valid today
The 3-Step Audit MethodSTRUCTURE
Each file system is evaluated according to three complementary axes:
Evaluation Axes
# 1. Kernel StatusCurrent → Integrated and maintained in the mainline kernel
External → DKMS module / out-of-tree (e.g., ZFS, APFS)
Obsolete → Driver present but deprecated
Removed → Code removed from kernel
# 2. Intrinsic Security Level🔐 Very High : data+metadata checksums, self-healing
🛡️ High : metadata checksums, robust journaling
🔒 Medium : basic journaling, no data checksums
⚠️ Low : no journaling, known vulnerabilities
# 3. Migration Strategy
→ Exact commands, prerequisites, risks, rollback
How to Use This GuidePRACTICAL
The interactive widget below allows you to navigate between filesystem categories. Each panel displays:
Content of Each Panel
# For each filesystem:✓ Updated kernel status (6.18+)
✓ Updated technical description
✓ EXACT security table (Checksums/Self-healing/Isolation/Level)
✓ Copyable audit commands
✓ Expected result for validation
✓ Usage recommendation
# Navigation:
→ Click an item in the left menu
→ Commands are directly copyable
→ Use the floating table of contents (top right)
💡 Start with the Main File Systems categories to understand current options, then consult Legacy & Obsolete if you manage legacy systems.
Reference Table of 32 File Systems (Updated April 2026)
Synthetic overview of the 32 evaluated filesystems. Click a name in the widget below to access technical details and audit commands.
Filesystem
Kernel Status
Security
Recommended Usage
Migration
ext4
Current
🛡️ High
General Standard
—
XFS
Current
🛡️ High
Large volumes, databases
—
btrfs
Current
🔐 Very High
Snapshots, containers, migration
From ext/ReiserFS
ZFS
External (OpenZFS)
🔐 Very High
NAS, critical storage
DKMS Module
F2FS
Current
🛡️ High
Pure flash storage (SSD/NVMe)
—
EROFS/SquashFS
Current
🛡️ High
Immutable images, containers
—
ext3
Obsolete
🔒 Medium
Legacy maintenance only
→ ext4 then btrfs
ReiserFS
Removed (6.13)
⚠️ Low
No usage recommended
→ btrfs (urgent)
bcachefs
External (DKMS)
🔒 Variable
Experimentation only
→ btrfs/XFS advised
APFS
External (FUSE)
N/A Linux
Read macOS data
apfs-fuse
Note: This table is a synthesis. The interactive widget below provides exact commands, detailed security levels, and documented migration procedures for each of the 32 filesystems.
Interactive Audit of 32 File Systems
Navigate through categories using the left menu. Each panel displays the kernel status, the EXACT security table, audit commands, and recommendations for all 32 filesystems.
Apple filesystem (SSD optimized). Experimental read-only access via apfs-fuse.
Checksums
Self-healing
Isolation
Level
N/A Linux
N/A
N/A
ℹ️ N/A Linux
# Install apfs-fuse (Debian/Ubuntu)
sudo apt install apfs-fuse
# Mount APFS partition (read-only)
sudo apfs-fuse -o allow_other /dev/sdXY /mnt/apfs
# Verify mount
mount | grep apfs
FAT32/vfat — Universal LegacyLEGACY
4 GB/file limit. No journaling, no Unix permissions.
Checksums
Self-healing
Isolation
Level
✗
✗
✗ (no Unix permissions)
⚠️ Low
# Detect FAT32
df -T | grep vfat
# Mount with security options
sudo mount -t vfat /dev/sdXY /mnt/usb -o uid=1000,gid=1000,umask=077
# Verify
sudo fsck.vfat -n /dev/sdXY
NFS — UNIX Network ShareNETWORK
Network File System. UNIX standard for network sharing. NFSv4: security improvements (RPCSEC_GSS, Kerberos).
Checksums
Self-healing
Isolation
Level
✗
✗
Export restrictions
🔒 Medium
# NFS: active exports
exportfs -v
# NFS mounts client-side
mount | grep nfs
# Service status
systemctl status nfs-server
# Verify NFSv4 version
nfsstat -m
SMB/CIFS — Windows Network ShareNETWORK
Server Message Block / Common Internet File System. Windows interoperability. SMB3: transit encryption.
Checksums
Self-healing
Isolation
Level
✗
✗
Minimal (SMB ACL)
🔒 Medium
# SMB: mounted shares
mount | grep cifs
# Verify SMB encryption
grep -i encrypt /etc/samba/smb.conf
# Test connection
smbclient -L //server/share -U user
CephFS — Distributed POSIXCLOUD
High availability distributed file system. POSIX compatible. Metadata checksums, replication.
Checksums
Self-healing
Isolation
Level
Metadata
✓ (replication)
Multi-tenant
🛡️ High
# CephFS client status
ceph status
# CephFS mount
mount -t ceph mon1:6789,mon2:6789:/ /mnt/ceph -o name=admin,secretfile=/etc/ceph/admin.secret
# Verify integrity
ceph fs status
GlusterFS — Scale-out DistributedCLUSTER
Scale-out distributed file system. No single metadata server. Replication and striping.
Checksums
Self-healing
Isolation
Level
✗ (depends on underlying FS)
✓ (replication)
Volumes
🔒 Medium
# GlusterFS status
gluster volume status
# Volume information
gluster volume info
# Client mount
mount -t glusterfs server:/volname /mnt/gluster
Virtual interface to kernel information. /proc exposes processes, hardware, configuration.
Checksums
Self-healing
Isolation
Level
✗ (virtual)
✗
hidepid=2 recommended
🔒 Variable
# /proc mounted with hidepid?
grep proc /proc/mounts
# Harden in /etc/fstab:
# proc /proc proc defaults,hidepid=2 0 0
# Verify
mount | grep proc
sysfs — Kernel Hardware InterfaceSYSTEM
Exposes hardware and driver information from the kernel. Read-only for most entries.
Checksums
Self-healing
Isolation
Level
✗ (virtual)
✗
Standard mount
🔒 Variable
# Verify sysfs mount
mount | grep sysfs
# Explore hardware info
ls /sys/class/net/
# Verify permissions
ls -la /sys/
debugfs — Kernel DebuggingDEBUG
Kernel debugging interface. Should NEVER be mounted in production. Security risk if exposed.
Checksums
Self-healing
Isolation
Level
✗
✗
⚠ Danger if mounted
⚠️ Low (production)
# Verify if debugfs is mounted
mount | grep debugfs
# Disable in production
sudo umount /sys/kernel/debug
# Prevent auto-mount
# Remove any debugfs line from /etc/fstab
⚠ debugfs must never be active in production. Risk of exposing sensitive kernel information.
configfs — Kernel ConfigurationSYSTEM
User configuration interface for kernel objects. Alternative to sysfs for dynamic configuration.
Checksums
Self-healing
Isolation
Level
✗
✗
Standard mount
🔒 Variable
# Verify configfs mount
mount | grep configfs
# Explore
ls /sys/kernel/config/
✔ Overlayfs relies on the security of the underlying FS (ext4/btrfs). Ensure the lower FS has checksums enabled.
ramfs — Pure RAM (no limits)WARNING
RAM-based filesystem without size limits. Can consume all available RAM until the OOM killer triggers. tmpfs is preferred as it has limits and uses swap.
Checksums
Self-healing
Isolation
Level
✗
✗
✗ (no limits)
⚠️ Low
# Verify if ramfs is used
mount | grep ramfs
# Prefer tmpfs instead:
# /etc/fstab : tmpfs /mnt/ram tmpfs size=512M,mode=0700 0 0
# If ramfs detected → migrate to tmpfs
sudo umount /mnt/ramfssudo mount -t tmpfs -o size=512M tmpfs /mnt/ram
⚠ ramfs is dangerous in production because it has no limits. Use tmpfs which respects size= and can swap.
cramfs — Read-only compression (legacy)LEGACY
Compressed ROM Filesystem. Read-only, zlib compression. Ancestor of SquashFS. No checksums. Usage: old embedded systems, legacy firmware.
Checksums
Self-healing
Isolation
Level
✗ (basic read-only)
✗
Minimal
⚠️ Low
# Detect cramfs
findmnt -o TARGET,FSTYPE | grep cramfs
# Migrate to SquashFS (better compression, checksums)
# Recreate image with mksquashfssudo mksquashfs /source/dir new-image.squashfs -comp zstd
# Mount new image
sudo mount -t squashfs new-image.squashfs /mnt/sqfs -o loop
⚠ cramfs is obsolete. Migrate to SquashFS or EROFS for better performance, zstd compression, and security.
EROFS — Optimized Read-OnlyIMMUTABLE
Enhanced Read-Only File System. Optimized for fast reading on flash. Usage: Android, containers, immutable system images.
No in-place conversion. Requires full backup, formatting, and data restoration.
# 1. Full Backup
sudo rsync -aAXv /mnt/old/ /mnt/backup/
# 2. Format to ext4 (or rebuild as SquashFS)
sudo umount /dev/sdXYsudo mkfs.ext4 /dev/sdXY
# 3. Restore
sudo mount /dev/sdXY /mnt/newsudo rsync -aAXv /mnt/backup/ /mnt/new/
# Alternative cramfs → SquashFS:
sudo mksquashfs /mnt/cramfs-contents new.squashfs -comp zstd
Security Synthesis by Intrinsic Level
This summary table allows quick comparison of the built-in protection mechanisms for each of the 32 filesystems.
🔐 Very High (data+metadata checksums, self-healing)
90%
🛡️ High (metadata checksums, robust journaling)
75%
🔒 Medium (basic journaling, no data checksums)
50%
⚠️ Low (no journaling, known vulnerabilities)
25%
Filesystem
Checksums
Self-healing
Isolation
Level
btrfs
Data + metadata
✓ (scrub)
Subvolumes
🔐 Very High
ZFS
Data + metadata
✓ (self-healing)
Datasets, quotas
🔐 Very High
XFS (V5)
Metadata only
✗
Projects, quotas
🛡️ High
ext4
Metadata (optional)
✗
Basic quotas
🛡️ High
F2FS
Metadata
✗
Limited
🛡️ High
CephFS
Metadata
✓ (replication)
Multi-tenant
🛡️ High
EROFS
Read-only
✓ (immutable)
Reduced surface
🛡️ High
SquashFS
Read-only
✓ (immutable)
Reduced surface
🛡️ High
ISO9660
Read-only
✓ (immutable)
Reduced surface
🛡️ High
UDF
Read-only
✓ (immutable)
Reduced surface
🛡️ High
ext3
✗
✗
Minimal
🔒 Medium
JFS
✗
✗
Minimal
🔒 Medium
NTFS
✗ (not Linux)
✗
Windows permissions
🔒 Medium
exFAT
✗
✗
✗
🔒 Medium
NFS
✗
✗
Export restrictions
🔒 Medium
SMB/CIFS
✗
✗
Minimal (SMB ACL)
🔒 Medium
GlusterFS
✗ (depends on underlying)
✓ (replication)
Volumes
🔒 Medium
tmpfs
✗
✗
Depends on options
🔒 Variable
proc
✗ (virtual)
✗
hidepid recommended
🔒 Variable
sysfs
✗ (virtual)
✗
Standard
🔒 Variable
configfs
✗
✗
Standard
🔒 Variable
hugetlbfs
✗
✗
Depends on config
🔒 Variable
overlayfs
Depends on lower FS
✗
Depends on config
🔒 Variable
bcachefs (DKMS)
Variable / unmaintained
✗
Not guaranteed
🔒 Variable
ReiserFS
Variable / unmaintained
✗
Not guaranteed
⚠️ Low
ext2
✗
✗
None
⚠️ Low
minix
✗
✗
None
⚠️ Low
FAT32/vfat
✗
✗
✗ (no Unix)
⚠️ Low
debugfs
✗
✗
⚠ Danger if mounted
⚠️ Low (prod)
ramfs
✗
✗
✗ (no limits)
⚠️ Low
cramfs
✗ (basic read-only)
✗
Minimal
⚠️ Low
APFS
N/A Linux
N/A
N/A
ℹ️ N/A Linux
Methodological note: The "Very High" level requires both data checksums (not just metadata), a self-healing mechanism, and functional isolation (subvolumes/datasets). Only btrfs and ZFS meet these three criteria in 2026.
Documented Migration Strategies
For obsolete or removed filesystems, here are validated procedures to migrate to modern alternatives without data loss.
Golden rule: Always perform a full backup before any migration operation, even with in-place conversion tools.
Source
Recommended Target
Tool
Complexity
Risk
ReiserFS
btrfs
btrfs-convert
Medium
Moderate (rollback possible)
ext3
ext4 → btrfs
Direct mount + btrfs-convert
Low
Low
ext2
ext3 → ext4 → btrfs
tune2fs -j + conversion
Low
Low
JFS / minix
ext4 or btrfs
Backup + reinstallation
High
Moderate (depends on backup)
bcachefs (DKMS)
btrfs or XFS
Backup + manual migration
High
Moderate (external tool)
cramfs
SquashFS / EROFS
Image reconstruction
High
Moderate
ramfs
tmpfs
Direct replacement
Low
Low
# Pre-migration checklist (valid for all cases):✓ Full validated backup (restore test)
✓ Sufficient disk space for conversion
✓ Planned maintenance window
✓ Documented rollback procedure
✓ Defined post-migration tests (integrity, performance)
# Example: post-migration verification for btrfs
sudo btrfs scrub start -B /new_mountpointsudo btrfs filesystem usage /new_mountpoint
Verified Sources (English, 2025-2026)
Five up-to-date, credible English technical sources to deepen each aspect of Linux file systems:
Detailed analysis of bcachefs removal from kernel 6.18, DKMS implications, and recommended alternatives for production users.
# Full reference:Title : "Bcachefs Ousted from Mainline Kernel"
Source : Linux Journal
Date : October 2025
URL : lwn.net/Articles/1040120/# Key points:
→ Context of removal by Linus Torvalds
→ Impact on DKMS users
→ Alternatives: btrfs, XFS, ext4
Complete ext4 vs btrfs vs XFS comparison with performance benchmarks, production stability analysis, and recommendations by use case.
# Full reference:Title : "Linux File Systems Explained: Ext4 Vs Btrfs Vs XFS"
Source : Eagleeyet
Date : January 2026
URL : eagleeyet.net/blog/btrfs-xfs-zfs# Key points:
→ Sequential and random I/O benchmarks
→ SSD vs HDD performance
→ Production stability (user feedback)
→ Recommendations by scenario (desktop/server/NAS)
Focus on the impact of filesystems (checksums, integrity controls) on overall Linux system security in 2026.
# Full reference:Title : "Key Linux Features Boosting Security Measures for 2026"
Source : LinuxSecurity.com
Date : November 2025
URL : linuxsecurity.com/# Key points:
→ Impact of FS checksums on security
→ Integrity Measurement Architecture (IMA)
→ Filesystem-level encryption (fscrypt)
→ Integrity controls and corruption detection
→ Hardening recommendations by FS type
Cross-Verification AdviceMETHOD
For any critical technical information (kernel status, CVE, compatibility), always cross-check at least two independent sources.
# Recommended verification method:Step 1 → Consult primary source (LWN.net / mailing list)
Step 2 → Check official project website
Step 3 → Cross-check with independent technical media
Step 4 → Test in isolated environment before production
# Example: verifying bcachefs status
1. LWN.net → removal decision
2. kernel.org → status in mainline tree
3. Linux Journal → impact analysis
4. Isolated VM test → verify DKMS behavior
Recommended SafeITExperts Readings
Five articles from our blog to deepen related topics on security and file system management:
OS security comparison 2026: 14 Linux distributions, Windows 11 24H2, macOS 15 Sequoia, FreeBSD 14 and OpenBSD 7.8 evaluated on MAC, firewall, encryption and rights.
# Article reference:Title : "OS Security Panorama 2026: Linux, Windows, macOS, BSD"
URL : safeitexperts.com/2026/04/en/complete-os-security-guide-2026.html# Link with this guide:
→ ext4/XFS/btrfs → Linux filesystems (this guide)
→ NTFS/ReFS → Windows filesystems (comparison)
→ APFS → macOS filesystem (mentioned here)
→ ZFS → common to BSD/Solaris/Linux (OpenZFS)
→ 2026 production table → global context
💡 This article places Linux filesystems in the broader context of multi-OS security. Useful for heterogeneous environments.
Complete analysis of 2025 Linux kernels: new features from Linux 6.14 to 6.19, critical CVEs (nf_tables, ksmbd 0-day AI, Rust Binder LTS 6.18), Bcachefs removal, dm-pcache, Apple Silicon M2.
# Article reference:Title : "Linux Kernels 2025: Complete Analysis"
URL : safeitexperts.com/en/2026/04/linux-kernels-2025-complete-analysis.html# Direct link with this guide:
→ Critical CVEs → filesystem vulnerabilities
→ Bcachefs removal → kernel 6.18 removal (this guide)
→ dm-pcache → impact on cached FS
→ Apple Silicon M2 → APFS/FS compatibility
→ Kernel timeline → plan migrations
💡 This article explains why bcachefs was removed and how filesystem CVEs affect security. Essential reading before migration.
All our technical guides on hardening, auditing, and Linux monitoring — centralized access to all our security resources.
# Access to complete category:URL : safeitexperts.com/search/security/# Category content:
→ Security audit guides (filesystems, network, SSH)
→ Hardening tutorials (SELinux, firewall, LUKS)
→ CVE and vulnerability analysis
→ Secure migration methodologies
→ Security monitoring and supervision
# Navigation:
→ Articles sorted by date (newest first)
→ Tags to filter by theme
→ Internal links between related articles
💡 The Linux Security category gathers all our technical guides. Recommended bookmark to follow our new publications.
Conclusion
The 4 filesystems to prioritize in 2026: ext4 (stability), XFS (large volumes), btrfs (modern features), ZFS (external critical storage).
Urgent migration: ReiserFS → btrfs, ext2/ext3 → ext4. Use btrfs-convert and tune2fs -j for secure transitions.
bcachefs: now DKMS module only. Evaluate maintenance cost before adoption; prefer btrfs/XFS for production.
Intrinsic security: prioritize filesystems with data+metadata checksums and self-healing (btrfs, ZFS) for critical data.
"A file system is not just a data container: it is the first line of defense against corruption, loss, and exploitation. Choosing is already securing."
Which filesystem do you use in production? What integrity score after scrub? Share your feedback in the comments or on social media with #SafeITExperts.