Every disk you format gets a file system, and that choice sets your limits for snapshots, corruption detection, permissions, file size and cross-OS access. Pick the wrong one and you face a reformat, a failed mount or silent bit rot. This guide compares the six file systems you will meet most often, with the commands to inspect, create and repair each.
Quick Takeaways
- Windows system drive: NTFS is required. Windows cannot boot from anything else in mainstream installs.
- Linux root and general servers: ext4 is the safest default. Btrfs is the pick when you want snapshots and rollback.
- macOS internal storage: APFS is the only supported choice on modern macOS. It is built for flash.
- Storage servers and NAS: ZFS gives the strongest data integrity. exFAT is for removable drives shared across Windows, macOS and Linux.
| File System | Primary OS | Journal / CoW | Data Checksums | Snapshots | Best For |
|---|---|---|---|---|---|
| NTFS | Windows | Metadata journal | No | Via VSS | Windows system and data disks |
| ext4 | Linux | Metadata journal | No | No (LVM only) | Linux root, databases, VMs |
| APFS | macOS, iOS | Copy-on-write | Metadata only | Yes | Apple SSDs, Time Machine |
| Btrfs | Linux | Copy-on-write | Yes | Yes | Desktops, rollback, mixed workloads |
| ZFS | Linux, FreeBSD, illumos | Copy-on-write | Yes | Yes | NAS, hypervisors, backup targets |
| exFAT | Cross-platform | None | No | No | USB drives, SD cards |
Prerequisites
Identify what you are working with before you change anything.
- Root or Administrator access.
- A verified backup of any disk you plan to format. Formatting destroys the existing file system.
- The device node:
/dev/sdb1on Linux,E:on Windows,disk3s1on macOS.
Check the current file system on each platform:
# Linux: list block devices with file system type, label and UUID
lsblk -f
# Linux: show mounted file systems and options
findmnt -t ext4,btrfs,xfs,ntfs3,exfat
# Windows: file system, health and free space per volume
Get-Volume | Format-Table DriveLetter, FileSystem, HealthStatus, SizeRemaining, Size
# Windows: NTFS version, cluster size and feature flags
fsutil fsinfo ntfsinfo C:
# macOS: list containers, volumes and their file system type
diskutil list
diskutil info / | grep -E "File System|Container"
Conceptual Overview: Journaling vs. Copy-on-Write
Two designs explain most of the differences in the table above.
Journaling file systems (NTFS, ext4) write intended metadata changes to a log first. After a crash, chkdsk or e2fsck replays the log and restores consistency. File data is overwritten in place. A crash mid-write can leave a file half old and half new, and the file system will not notice.
Copy-on-write (CoW) file systems (APFS, Btrfs, ZFS) never overwrite live blocks. They write new blocks, then atomically update the pointer. This makes snapshots nearly free and prevents torn writes. Btrfs and ZFS also store checksums for data, so they detect corruption on every read. APFS checksums metadata only.
exFAT has no journal and no CoW. A device pulled mid-write can leave the allocation table inconsistent. That is the main reason not to use it for anything you cannot afford to lose.
Deep Dive: Each File System
NTFS
NTFS is the native Windows file system. It supports ACLs, EFS encryption, per-file compression, hard links, junctions, sparse files, alternate data streams and VSS (Volume Shadow Copy) snapshots. It journals metadata but does not checksum file data.
- Limits: Practical maximum volume size is 256 TB with 64 KB clusters. Newer Windows Server releases allow larger clusters and larger volumes.
- Linux access: The in-kernel ntfs3 driver (Linux 5.15 and later) gives read-write support. The older FUSE-based ntfs-3g still works and is the fallback.
- macOS access: Read-only by default.
# Format a volume as NTFS (destroys data; -Confirm prompts first)
Format-Volume -DriveLetter E -FileSystem NTFS -NewFileSystemLabel "Data" -Confirm
# Check and repair: /f fixes errors, /r also scans for bad sectors
chkdsk E: /f /r
ext4
ext4 is the default on Debian, Ubuntu and many RHEL-family installs. It uses extents, delayed allocation and a journal. It has metadata checksums but no data checksums, no native snapshots and no compression. Its strength is boring predictability: low overhead, mature tooling and consistent latency.
- Limits: 1 EiB volume, 16 TiB maximum file size with 4 KiB blocks.
- Strengths: Fast
fsck, wide recovery tool support, excellent for databases and VM images where CoW fragmentation hurts.
# Create ext4 with a label; -m 1 reserves 1% for root instead of the default 5%
sudo mkfs.ext4 -L data -m 1 /dev/sdb1
# Show journal mode, features and mount counts
sudo tune2fs -l /dev/sdb1
# Grow the file system online after extending the LV or partition
sudo resize2fs /dev/sdb1
APFS
APFS is Apple’s CoW file system. It supports snapshots, clones (instant file copies that share blocks), space sharing across volumes in one container, and native per-file or per-volume encryption. It checksums metadata only. APFS is tuned for flash storage and performs poorly on spinning disks compared to older HFS+.
Time Machine uses APFS snapshots for local backups. Linux has no stable mainline APFS driver, so treat APFS as macOS-only.
# Show containers, volumes, roles and encryption state
diskutil apfs list
# Verify a volume (read-only check)
diskutil verifyVolume /
# Create a new volume inside an existing container
diskutil apfs addVolume disk3 APFS "Projects"
# List local snapshots
tmutil listlocalsnapshots /
Btrfs
Btrfs is the Linux in-tree CoW file system. It offers data and metadata checksums, subvolumes, writable and read-only snapshots, send/receive replication, transparent compression (zstd, lzo) and built-in multi-device profiles. RAID 0, 1 and 10 are considered stable. RAID 5/6 remains risky because of write-hole issues, so avoid it for data you care about.
openSUSE and Fedora Workstation use Btrfs by default. It suits desktops where rollback before an upgrade matters.
# Create with a label
sudo mkfs.btrfs -L pool /dev/sdb1
# Mount with zstd compression and no access-time writes
sudo mount -o compress=zstd:3,noatime /dev/sdb1 /mnt/pool
# Create a subvolume and a read-only snapshot
sudo btrfs subvolume create /mnt/pool/data
sudo btrfs subvolume snapshot -r /mnt/pool/data /mnt/pool/snap-2026-11-08
# Verify every checksum on the volume (-B runs in the foreground)
sudo btrfs scrub start -B /mnt/pool
ZFS
ZFS combines the volume manager and the file system. You build pools from vdevs (mirror, RAIDZ1/2/3), then create datasets with their own properties. It checksums all data and metadata, self-heals from redundancy during reads and scrubs, and supports snapshots, clones, send/recv replication, native encryption and compression. OpenZFS 2.3 added RAIDZ expansion, which lets you widen an existing RAIDZ vdev.
ZFS ships under the CDDL license, so it lives out of tree on Linux and installs as a module. ZFS also uses RAM aggressively for its ARC cache. ECC memory is recommended but not mandatory.
# Create a mirrored pool; ashift=12 aligns to 4K sectors
sudo zpool create -o ashift=12 tank mirror \
/dev/disk/by-id/ata-DISK_A /dev/disk/by-id/ata-DISK_B
# Dataset with compression and no atime updates
sudo zfs create -o compression=zstd -o atime=off tank/media
# Snapshot and replicate to another pool
sudo zfs snapshot tank/media@2026-11-08
sudo zfs send tank/media@2026-11-08 | sudo zfs recv backup/media
# Scrub and check health
sudo zpool scrub tank
zpool status -v tank
exFAT
exFAT exists for flash media. It removes FAT32’s 4 GiB file limit, has no practical size ceiling for consumer use and mounts natively on Windows, macOS and modern Linux (in-kernel driver since 5.7). It has no permissions, no journal, no checksums and no snapshots.
# Linux: format (requires exfatprogs)
sudo mkfs.exfat -L share /dev/sdb1
# Check and repair
sudo fsck.exfat /dev/sdb1
# Windows: quick format as exFAT
format E: /FS:exFAT /Q /V:Share
Direct Comparison: Features and Trade-Offs
| Criteria | NTFS | ext4 | APFS | Btrfs | ZFS | exFAT |
|---|---|---|---|---|---|---|
| Resource Consumption | Low | Very low | Low | Moderate | High (RAM for ARC) | Very low |
| Data Integrity | Journal only | Journal only | Metadata checksums | Full checksums | Full checksums, self-heal | None |
| Snapshots | VSS | None | Native | Native | Native | None |
| Compression | Per-file | None | None | zstd / lzo | lz4 / zstd | None |
| Native Encryption | EFS, BitLocker | fscrypt, LUKS | Built in | LUKS (native in progress) | Built in | None |
| Permissions | ACLs | POSIX + ACLs | POSIX + ACLs | POSIX + ACLs | POSIX + NFSv4 ACLs | None |
| Stability | Very high | Very high | High | High (not RAID 5/6) | Very high | Moderate |
| Cross-OS Support | Win r/w, Linux r/w, macOS r/o | Linux only (add-ons elsewhere) | macOS only | Linux only | Linux/BSD/macOS/Windows via OpenZFS ports | All three |
| Management Effort | Low | Low | Low | Medium | High | Minimal |
Decision Matrix: Which One for Which Job
| Scenario | Recommended | Reason |
|---|---|---|
| Windows 11 system disk | NTFS | Required for boot, BitLocker, VSS |
| Ubuntu or Debian server root | ext4 | Predictable, well-tested, fast fsck |
| Linux desktop with rollback | Btrfs | Snapshot before upgrades, cheap compression |
| Home NAS with bit-rot protection | ZFS | Scrubs and self-healing on redundant vdevs |
| PostgreSQL or MySQL on Linux | ext4 (or XFS) | CoW fragmentation hurts random writes |
| MacBook internal SSD | APFS | Only supported option, clones and snapshots |
| USB stick shared across all OSes | exFAT | Native read-write everywhere |
| Backup target with replication | ZFS or Btrfs | send/recv incremental transfers |
Practical Troubleshooting and Real-World Scenarios
Scenario 1: ext4 Superblock Damage
Symptom: mount: wrong fs type, bad option, bad superblock.
Unmount the device and list backup superblock locations. The -n flag simulates formatting and writes nothing.
sudo umount /dev/sdb1
sudo mke2fs -n /dev/sdb1
# Note the "Superblock backups stored on blocks" list, e.g. 32768, 98304
# Repair using a backup superblock; -y answers yes to all fixes
sudo e2fsck -b 32768 -y /dev/sdb1
Scenario 2: NTFS Volume Marked Dirty
Symptom: Linux refuses read-write mounts, or Windows prompts to scan on every boot. Windows may also report 0x80070570 (“The file or directory is corrupted and unreadable”).
chkdsk E: /f
If the drive only mounts on Linux, ntfsfix clears the dirty flag and schedules a Windows check. It is not a full repair.
sudo ntfsfix /dev/sdb1
Scenario 3: Btrfs Checksum Errors
Symptom: BTRFS error ... csum failed in dmesg.
# Locate corrupt files
sudo btrfs scrub start -B /mnt/pool
sudo btrfs scrub status /mnt/pool
# Review per-device error counters
sudo btrfs device stats /mnt/pool
On a mirrored profile, the scrub repairs bad blocks from the good copy. On single-device Btrfs it only reports, so restore the named files from backup. Run btrfs check --readonly only on an unmounted device. Avoid --repair unless you have a backup and no alternative.
Scenario 4: ZFS Pool Degraded
Symptom: zpool status shows DEGRADED and a device marked FAULTED or UNAVAIL.
zpool status -v tank
# Replace the failed disk; ZFS resilvers automatically
sudo zpool replace tank /dev/disk/by-id/ata-OLD /dev/disk/by-id/ata-NEW
# Clear transient error counters after fixing cabling
sudo zpool clear tank
Scenario 5: APFS Volume Won’t Mount
Symptom: Disk Utility First Aid fails.
diskutil verifyVolume disk3s1
diskutil repairVolume disk3s1
If that fails, boot into Recovery, open Terminal and run fsck_apfs -y /dev/disk3s1. Restore from Time Machine if the check reports unrecoverable errors.
Scenario 6: Corrupted exFAT After Unsafe Removal
sudo fsck.exfat -p /dev/sdb1
On Windows, right-click the drive, choose Properties > Tools > Check, or run chkdsk E: /f. Always use Safely Remove Hardware on exFAT media. It has no journal to cover an interrupted write.
Converting and Migrating Between File Systems
In-place conversion exists for only a few pairs. Treat it as risky and back up first.
| Conversion | In-Place Option | Safer Path |
|---|---|---|
| ext4 → Btrfs | btrfs-convert /dev/sdb1 |
Copy data to a new Btrfs volume with rsync -aHAX |
| FAT32 → NTFS | convert E: /fs:ntfs |
Backup, reformat, restore |
| NTFS → ext4 | None | rsync to new volume (loses ACLs and ADS) |
| Any → ZFS | None | rsync into a new dataset |
# Preserve permissions, ACLs, xattrs and hard links during migration
sudo rsync -aHAX --info=progress2 /mnt/old/ /mnt/new/
FAQ
Is NTFS or exFAT better for an external drive?
Use NTFS if the drive stays with Windows, because it gives journaling, permissions and files above 4 GiB. Use exFAT if you move the drive between Windows, macOS and Linux with read-write access everywhere. exFAT has no journal, so eject it properly and keep a backup.
Is Btrfs or ZFS better for a home server?
ZFS is more mature for multi-disk storage. It has stable RAIDZ, proven self-healing and better replication tooling. Btrfs is in the mainline Linux kernel, needs less RAM and works well on a single disk or mirror. Avoid Btrfs RAID 5/6 for important data.
Can Windows read ext4 or APFS?
Not natively. Windows needs a third-party driver or WSL2 disk mounting to read ext4 (wsl --mount \\.\PHYSICALDRIVE1 --partition 1 --type ext4). Windows has no maintained APFS driver. Linux can read APFS only through a read-only FUSE tool, and macOS cannot write ext4 natively.
Which Linux file system is fastest?
None wins every workload. ext4 and XFS typically lead on raw latency for databases and large sequential I/O. Btrfs and ZFS trade some speed for checksums, compression and snapshots. Benchmark with fio on your own hardware and access pattern before deciding.
