LFCS 78 🐧 Creating Filesystems — mkfs - KandZ

⏱️ Estimated read: 13 min | |

mkfs is the command that turns a raw block device into something the kernel can mount. It is a front-end, not an implementation: mkfs itself does almost nothing except locate and execute the filesystem-specific builder for the type you request . Understanding that distinction is the first step toward using it correctly, because the options that matter are almost all passed through to mkfs.ext4, mkfs.xfs, or mkfs.btrfs, and each of those builders has its own rules.

This chapter covers the creation step of the LFCS storage workflow: the mkfs front-end and its filesystem-specific variants, the options that appear in practice, the destructive nature of the operation, and the verification commands that confirm what was actually written. It assumes the partition already exists—created with parted, fdisk, or LVM—and that the device path is known. The chapter does not cover mounting or /etc/fstab; those belong to the persistence workflow that follows creation.

Key point: mkfs erases data without asking. The device path is the only thing standing between the command and the wrong disk, and the command will not warn you if that path is wrong.

Why mkfs is a front-end

The mkfs binary is documented as “a front-end for the various file system builders available under Linux” . When you run mkfs -t ext4 /dev/sdb1, the command searches for mkfs.ext4 in a compiled-in list of directories and executes it with the arguments you provided. The same binary handles mkfs.xfs, mkfs.btrfs, and every other supported type. The front-end exists so that scripts and documentation can use a uniform entry point, but the real work happens in the type-specific builder.

The practical consequence is that mkfs generic options are limited. The manual page lists -V, -t, -c, and -l, and it warns that “all generic options must precede and not be combined with file system-specific options” . If you need an option that controls inode size, block size, or metadata checksums, that option is a mkfs.ext4 option, not an mkfs option. The modern recommendation is to call the type-specific command directly: mkfs.ext4 rather than mkfs -t ext4 . The front-end is deprecated in favor of the explicit commands.

A second consequence is that the default type when -t is omitted is not what an administrator expects. The historical default was minix, and later ext2 . If mkfs is invoked without a type and without a matching /etc/fstab entry to deduce the type from, the result may be a filesystem that is not what was intended. Explicit is always better.

a. Creating ext4 with mkfs.ext4

mkfs.ext4 is the builder for the fourth extended filesystem. Its default options are appropriate for most use cases, and a plain invocation with just the device path produces a working filesystem . The ext family also includes mkfs.ext2 and mkfs.ext3, which create older variants of the same lineage.

# Create an ext4 filesystem with default options.
# This is the most common form for a data partition.
sudo mkfs.ext4 /dev/sdb1

# Set a volume label at creation time.
# The label is useful for identifying the filesystem in blkid output.
sudo mkfs.ext4 -L data /dev/sdb1

# Check for bad blocks before creating the filesystem.
# This is slow and rarely necessary on modern disks, but it is a valid option.
sudo mkfs.ext4 -c /dev/sdb1

The ext4 builder does not require a -f flag to overwrite an existing filesystem signature in most cases; it will detect the signature and prompt for confirmation in interactive mode, or refuse in some versions. The -F flag forces creation regardless of existing signatures, but it should be used with the same caution as mklabel in parted: it turns a safety check into a destructive operation.

After creation, dumpe2fs -h displays the superblock information, including the filesystem UUID, block count, inode count, and features enabled . This is the verification step for ext4: confirm that the filesystem type, size, and label match what was requested.

# Verify the filesystem that was created.
# The -h flag prints only the superblock summary, not the full block map.
sudo dumpe2fs -h /dev/sdb1

b. Creating XFS with mkfs.xfs

mkfs.xfs creates XFS filesystems. Like ext4, its default options are suitable for general use, and a plain invocation produces a functional filesystem . The difference is that XFS has no shrink capability, so the creation step is the only point at which certain layout decisions can be made.

# Create an XFS filesystem with default options.
sudo mkfs.xfs /dev/sdb1

# Force creation over an existing filesystem signature.
# XFS is more conservative than ext4 about overwriting, so -f is often needed.
sudo mkfs.xfs -f /dev/sdb1

# Set the filesystem label (maximum 12 characters).
sudo mkfs.xfs -L data /dev/sdb1

The -f flag deserves emphasis. On a partition that already contains a filesystem signature, mkfs.xfs refuses to proceed without it. This is a safety feature: it prevents accidental destruction of an existing filesystem. But in a scripting context where the intent is to reformat a reused disk, the flag is necessary. The decision to add it should be as deliberate as the decision to run the command at all.

Verification uses xfs_info, which reports the filesystem geometry: block size, inode size, allocation group count, and the underlying device . This command must be run on a mounted filesystem or with the device path; it reads the metadata to report what XFS actually created.

# Verify the XFS filesystem.
# Can be run on the device path or on the mount point.
sudo xfs_info /dev/sdb1

c. Creating Btrfs with mkfs.btrfs

mkfs.btrfs creates Btrfs filesystems. Its invocation differs from the other two in one important way: it can take multiple devices, because Btrfs has integrated volume management and RAID support . A single-device Btrfs filesystem is the common case, but the multi-device form is part of the tool’s design.

# Create a single-device Btrfs filesystem.
sudo mkfs.btrfs /dev/sdb1

# Force creation over an existing signature.
sudo mkfs.btrfs -f /dev/sdb1

# Create a Btrfs filesystem spanning multiple devices with RAID10.
# RAID10 requires at least four devices for the data profile.
sudo mkfs.btrfs -d raid10 -m raid10 /dev/sdb /dev/sdc /dev/sdd /dev/sde

The multi-device form creates a filesystem that spans the listed devices. Btrfs defaults to mirroring metadata across devices when more than one is specified, unless a different profile is requested . For a single device, metadata is duplicated on that device by default, which provides some protection against metadata corruption at the cost of space.

After creating a multi-device Btrfs filesystem, btrfs device scan may be needed so the kernel discovers all the component devices . For a single-device filesystem, this is not necessary. Verification uses btrfs filesystem df or btrfs filesystem usage, which report the space allocation in Btrfs-specific terms: data, metadata, and system chunks .

# Verify the Btrfs filesystem space allocation.
# btrfs filesystem df is more accurate than generic df for Btrfs.
sudo btrfs filesystem df /mnt

Complete Example Session

# ============================================
# PART 1: INSPECTION BEFORE CREATION
# ============================================
# mkfs is destructive. Confirm the target device first.
# lsblk shows the device tree and current filesystem types.

lsblk -f /dev/sdb
# If the partition already has a filesystem, it will be listed.
# If it is empty, the FSTYPE column will be blank.

# ============================================
# PART 2: CREATING EXT4
# ============================================
# Default options, with a label for identification.

sudo mkfs.ext4 -L data /dev/sdb1

# ============================================
# PART 3: VERIFYING EXT4
# ============================================
# dumpe2fs reads the superblock and reports the result.

sudo dumpe2fs -h /dev/sdb1 | grep -E 'Filesystem volume name|Block count|Filesystem UUID'

# ============================================
# PART 4: CREATING XFS
# ============================================
# XFS often requires -f when a signature exists.
# The label is limited to 12 characters.

sudo mkfs.xfs -f -L data /dev/sdb2

# ============================================
# PART 5: VERIFYING XFS
# ============================================
# xfs_info reports geometry and features.

sudo xfs_info /dev/sdb2

# ============================================
# PART 6: CREATING BTRFS
# ============================================
# Single-device Btrfs, forced over any existing signature.

sudo mkfs.btrfs -f -L data /dev/sdb3

# ============================================
# PART 7: VERIFYING BTRFS
# ============================================
# btrfs filesystem usage reports the space allocation.
# This requires the filesystem to be mounted first.

sudo mkdir -p /mnt/btrfs
sudo mount /dev/sdb3 /mnt/btrfs
sudo btrfs filesystem usage /mnt/btrfs

# ============================================
# PART 8: THE FRONT-END FORM
# ============================================
# The generic mkfs command still works but is deprecated.
# The type-specific commands are preferred.

# sudo mkfs -t ext4 /dev/sdb1   # works, but mkfs.ext4 is preferred
# sudo mkfs -t xfs /dev/sdb2    # works, but mkfs.xfs is preferred

# ============================================
# PART 9: THE DESTRUCTIVE WARNING
# ============================================
# mkfs does not ask for confirmation in scripted mode.
# The only protection is the device path being correct.

# A wrong path here would destroy the wrong filesystem:
# sudo mkfs.ext4 /dev/sda1   # WRONG DISK, NO WARNING

# ============================================
# PART 10: THE VERIFICATION SUMMARY
# ============================================
# Each filesystem has its own verification tool.
# There is no universal "show me what I just created" command.

echo "ext4: dumpe2fs -h"
echo "xfs:  xfs_info"
echo "btrfs: btrfs filesystem usage"

The ten parts walk through creation and verification for all three filesystems, with the front-end form shown for contrast. The consistent pattern is: inspect with lsblk -f, create with the type-specific builder, verify with the type-specific inspector. The mkfs front-end is a historical convenience; the direct commands are the current practice.

Quick Reference

Creation Commands

Filesystem	Command	Force Flag	Label Flag
ext4	`mkfs.ext4 /dev/X`	`-F`	`-L name`
XFS	`mkfs.xfs /dev/X`	`-f`	`-L name`
Btrfs	`mkfs.btrfs /dev/X`	`-f`	`-L name`
Front-end	`mkfs -t type /dev/X`	Deprecated	Passed through

Verification Commands

Filesystem	Command	What It Shows
ext4	`dumpe2fs -h /dev/X`	Superblock, UUID, features
XFS	`xfs_info /dev/X`	Geometry, block size, AG count
Btrfs	`btrfs filesystem usage /mnt`	Data/metadata/system allocation

Generic mkfs Options

Option	Meaning	Status
`-t fstype`	Select filesystem type	Supported, deprecated
`-V`	Verbose output	Supported
`-c`	Check for bad blocks	Supported
`-l file`	Read bad blocks list	Rarely used

Destructive Behavior

Command	Confirmation Prompt?	Reversible?
`mkfs.ext4`	Interactive: yes; scripted: no	No
`mkfs.xfs`	Refuses without `-f` if signature exists	No
`mkfs.btrfs`	Interactive: yes; scripted: no	No
`mkfs -t type`	Depends on builder	No

Best Practices

✅ Do This:

# Inspect the device before formatting.
lsblk -f /dev/sdb                                                       # ✅

# Use the type-specific command directly.
sudo mkfs.ext4 /dev/sdb1                                                # ✅

# Set a label for identification.
sudo mkfs.xfs -L data /dev/sdb2                                         # ✅

# Verify what was created.
sudo dumpe2fs -h /dev/sdb1                                              # ✅

# Use -f deliberately when reformatting a reused disk.
sudo mkfs.xfs -f /dev/sdb1                                              # ✅

# Confirm the partition exists in the kernel first.
lsblk /dev/sdb                                                          # ✅

❌ Don’t Do This:

# Don't format without checking the device path.
sudo mkfs.ext4 /dev/sda1  # wrong disk, no warning                    # ❌

# Don't use the front-end form in new scripts.
sudo mkfs -t ext4 /dev/sdb1  # deprecated, use mkfs.ext4              # ❌

# Don't expect mkfs to partition the disk.
sudo mkfs.ext4 /dev/sdb  # formats the whole disk, not a partition     # ❌

# Don't assume the filesystem is mountable immediately.
# Run partprobe if the partition was just created.                    # ❌

# Don't skip verification.
# A silent success may still be the wrong filesystem type.            # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Wrong filesystem type created	`mkfs` without `-t` defaults to an unexpected type	Always call `mkfs.ext4`, `mkfs.xfs`, or `mkfs.btrfs` explicitly
`mkfs.xfs` refuses to run	Existing filesystem signature detected	Add `-f` only after confirming the correct device
Partition not found	Kernel table not re-read after `parted`	Run `partprobe /dev/sdb` first
Label not set	Label flag omitted or wrong length	Use `-L`; XFS caps at 12 characters
Cannot verify Btrfs	`btrfs filesystem usage` needs a mount point	Mount first, then run the command
Data lost on reused disk	`mkfs` is destructive and does not warn	Inspect with `lsblk -f` before every format

Real-World Examples

1. Format ext4 with Label

sudo mkfs.ext4 -L data /dev/sdb1

2. Format XFS with Force

sudo mkfs.xfs -f /dev/sdb1

3. Format Btrfs Single Device

sudo mkfs.btrfs -f /dev/sdb1

4. Verify ext4 Superblock

sudo dumpe2fs -h /dev/sdb1 | head -20

5. Verify XFS Geometry

sudo xfs_info /dev/sdb1

6. Verify Btrfs Usage

sudo btrfs filesystem usage /mnt

7. Inspect Before Formatting

lsblk -f /dev/sdb

8. Check for Bad Blocks

sudo mkfs.ext4 -c /dev/sdb1

9. Multi-Device Btrfs

sudo mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc

10. Front-End Form (Deprecated)

sudo mkfs -t ext4 /dev/sdb1

Visual

The mkfs Front-End

┌─────────────────────────────────────────────────────────┐
│  mkfs -t ext4 /dev/sdb1                                 │
│         │                                               │
│         ▼                                               │
│  ┌───────────────────────────────────────────────────┐  │
│  │  mkfs front-end                                   │  │
│  │  Searches for the type-specific builder           │  │
│  └───────────────────────────────────────────────────┘  │
│         │                                               │
│         ▼                                               │
│  ┌───────────────────────────────────────────────────┐  │
│  │  mkfs.ext4 /dev/sdb1                              │  │
│  │  The actual filesystem builder                    │  │
│  └───────────────────────────────────────────────────┘  │
│         │                                               │
│         ▼                                               │
│  ┌───────────────────────────────────────────────────┐  │
│  │  ext4 filesystem written to /dev/sdb1             │  │
│  └───────────────────────────────────────────────────┘  │
│                                                         │
│  The front-end adds nothing except indirection.         │
│  Calling mkfs.ext4 directly skips the search.           │
└─────────────────────────────────────────────────────────┘

Creation and Verification Pairs

┌─────────────────────────────────────────────────────────┐
│  CREATE                 VERIFY                          │
│                                                         │
│  mkfs.ext4 /dev/sdb1    dumpe2fs -h /dev/sdb1           │
│         │                      │                        │
│         ▼                      ▼                        │
│  superblock, UUID       superblock summary              │
│  inode tables           block count                     │
│  journal                feature flags                   │
│                                                         │
│  ─────────────────────────────────────────────────────  │
│                                                         │
│  mkfs.xfs /dev/sdb1     xfs_info /dev/sdb1              │
│         │                      │                        │
│         ▼                      ▼                        │
│  allocation groups      block size                      │
│  journal                inode size                      │
│  metadata               AG count                        │
│                                                         │
│  ─────────────────────────────────────────────────────  │
│                                                         │
│  mkfs.btrfs /dev/sdb1   btrfs filesystem usage /mnt     │
│         │                      │                        │
│         ▼                      ▼                        │
│  copy-on-write tree     data/metadata/system            │
│  checksums              allocation profiles             │
│  subvolumes             device size                     │
└─────────────────────────────────────────────────────────┘

The Destructive Boundary

┌─────────────────────────────────────────────────────────┐
│  lsblk -f /dev/sdb                                      │
│         │                                               │
│         ▼                                               │
│  ┌───────────────────────────────────────────────────┐  │
│  │  sdb1: ext4, LABEL="old_data"                     │  │
│  │  sdb2: (blank)                                    │  │
│  └───────────────────────────────────────────────────┘  │
│         │                                               │
│         ▼  mkfs.ext4 /dev/sdb1                          │
│  ┌───────────────────────────────────────────────────┐  │
│  │  The old_data filesystem is GONE.                 │  │
│  │  No prompt. No undo.                              │  │
│  └───────────────────────────────────────────────────┘  │
│                                                         │
│  The blank sdb2 is safe. The labeled sdb1 is not.       │
│  Inspection before formatting is the only protection.   │
└─────────────────────────────────────────────────────────┘

Btrfs Multi-Device Form

┌─────────────────────────────────────────────────────────┐
│  mkfs.btrfs -d raid1 -m raid1 /dev/sdb /dev/sdc         │
│                                                         │
│  ┌─────────────┐         ┌─────────────┐               │
│  │   /dev/sdb  │         │   /dev/sdc  │               │
│  │             │         │             │               │
│  │  data copy  │◄───────►│  data copy  │               │
│  │  meta copy  │◄───────►│  meta copy  │               │
│  └─────────────┘         └─────────────┘               │
│                                                         │
│  One Btrfs filesystem, two devices, mirrored.           │
│  Either device can be specified at mount time.          │
│                                                         │
│  For single-device Btrfs, omit the second device.       │
│  mkfs.btrfs /dev/sdb1                                   │
└─────────────────────────────────────────────────────────┘

Summary

Item	Value
mkfs	Front-end for filesystem-specific builders
ext4 builder	`mkfs.ext4`
XFS builder	`mkfs.xfs`
Btrfs builder	`mkfs.btrfs`
ext4 force	`-F`
XFS force	`-f` (often required over existing signatures)
Btrfs force	`-f`
Label flag	`-L name` (XFS max 12 chars)
ext4 verify	`dumpe2fs -h`
XFS verify	`xfs_info`
Btrfs verify	`btrfs filesystem usage`

Key takeaways:

mkfs is a front-end, not the real builder. The type-specific commands are the current practice, and the front-end form is deprecated .
mkfs.xfs often requires -f. XFS refuses to overwrite an existing signature without explicit permission. That refusal is a safety feature, not an obstacle.
Each filesystem has its own verification tool. There is no universal mkfs --verify. dumpe2fs, xfs_info, and btrfs filesystem usage report different information because the filesystems are different.
The device path is the only safety check. mkfs does not know which disk you meant to format. lsblk -f before the command is the step that prevents disaster.
Btrfs accepts multiple devices. The multi-device form is part of the tool’s design, and RAID profiles are selected at creation time.
The filesystem must exist in the kernel before formatting. If parted just created the partition, run partprobe first, or mkfs will fail with “no such device.”
Labels are filesystem-specific. ext4 and Btrfs accept longer labels; XFS caps at 12 characters. Labels are useful for blkid and /etc/fstab.
Creation is not the end of the workflow. Formatting, mounting, and persistence are separate steps, and each has its own verification.

Remember: mkfs is the step that writes a filesystem’s metadata to a block device. It is destructive, it does not ask for confirmation in scripted use, and it is type-specific in everything that matters: the command name, the options, and the verification tool. The LFCS candidate should be able to format a partition with all three major local filesystems, set a label, force the operation when necessary, and verify the result with the correct inspector. The front-end mkfs is worth recognizing in documentation and legacy scripts, but the direct commands are what to reach for in practice.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!