7.3 Creating Filesystems: mkfs, ext4, XFS, VFAT/exFAT & Btrfs (104.1)

7.3 Creating Filesystems: mkfs, ext4 & XFS

Quick Summary: Before an operating system can store files, directories, and permissions on a newly partitioned block device, the storage space must be formatted with a filesystem. Linux provides the unified mkfs frontend utility, which dispatches requests to backend binaries like mkfs.ext4 or mkfs.xfs. The fourth extended filesystem (ext4) uses extents, delayed block allocation, and tunable reserved space (-m), while Silicon Graphics' XFS filesystem offers high-performance journaling, dynamic inode allocation, and online capacity expansion via xfs_growfs (with the critical constraint that XFS cannot be shrunk).

---

1. The Generic Filesystem Frontend: mkfs Architecture

The mkfs command is a generic unified frontend wrapper for creating filesystems in Linux. When an administrator executes mkfs, it parses the -t <fstype> parameter and delegates execution to the corresponding filesystem builder executable in /sbin/ or /usr/sbin/:

mkfs Command Delegation Architecture:
                ┌───────────────────────────────────────┐
                │          mkfs -t <type> /dev/sdX      │
                └───────────────────────────────────────┘
                                    │
        ┌───────────────────────────┼───────────────────────────┐
        ▼                           ▼                           ▼
┌─────────────────┐         ┌─────────────────┐         ┌─────────────────┐
│ /sbin/mkfs.ext4 │         │ /sbin/mkfs.xfs  │         │ /sbin/mkfs.vfat │
│ (mke2fs -t ext4)│         │ (XFS filesystem)│         │ (FAT32 for ESP) │
└─────────────────┘         └─────────────────┘         └─────────────────┘

mkfs Invocation Syntax

# Using the generic frontend syntax:
# mkfs -t ext4 /dev/sdb1
# mkfs -t xfs /dev/sdb2
# mkfs -t vfat -F 32 /dev/sdb3

# Direct binary invocation (identical behavior, standard practice):
# mkfs.ext4 /dev/sdb1
# mkfs.xfs /dev/sdb2
# mkfs.vfat -F 32 /dev/sdb3

---

2. The Extended Filesystem Family: ext2, ext3 & ext4

The Extended (ext) filesystem architecture is the historical standard for Linux operating systems.

Evolutionary Progression of Ext Filesystems

Ext3/Ext4 Journaling Modes

Ext3 and ext4 support three distinct journaling modes configured via mount options (data=):

1. data=journal (Highest Integrity, Lowest Performance): Both metadata and actual file payload data are written to the journal before being committed to the main filesystem blocks.
2. data=ordered (Default Mode, Balanced): File payload data is flushed to the main filesystem blocks before the associated metadata transactions are committed to the journal. Guarantees that unwritten disk blocks are never referenced upon crash recovery.
3. data=writeback (Highest Performance, Lowest Integrity): Metadata is journaled, but file payload data is written asynchronously without ordering constraints. Recent file updates may expose stale disk block data after an unclean crash.

Ext4 Structural Advantages: Extents vs Block Mapping

In legacy ext2/ext3, large files required hierarchical indirect block pointers (direct, indirect, doubly indirect, and triply indirect block tables) to map logical file offsets to disk blocks. In ext4, a single extent descriptor can represent up to 128 MiB of contiguous physical disk blocks in a compact 12-byte structure ([starting block, length]), drastically reducing metadata overhead and fragmentation.

---

3. Formatting with mkfs.ext4 & mke2fs

The low-level utility responsible for building ext2, ext3, and ext4 filesystems is mke2fs. (mkfs.ext2, mkfs.ext3, and mkfs.ext4 are symlinks or wrappers to mke2fs).

Critical mke2fs / mkfs.ext4 Command Flags Reference

Practical mkfs.ext4 Formatting Examples

# Format /dev/sdb1 as ext4 with volume label 'DATA_STORE' and 1% reserved root space
# mkfs.ext4 -L "DATA_STORE" -m 1 /dev/sdb1
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: c1f23890-7812-4a0b-9912-abcdef123456
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done

# Format high-density news spool with small block size (1024B) and high inode count
# mke2fs -t ext4 -b 1024 -i 2048 -L "NEWS_SPOOL" /dev/sdc1

💡 LPIC-1 Exam Fill-in-the-Blank Alert: What mke2fs command-line option specifies the percentage of filesystem blocks reserved for the superuser root? Answer: -m

4. High-Performance XFS Filesystem Creation

XFS is a 64-bit, high-performance journaling filesystem originally designed by Silicon Graphics Inc. (SGI) for IRIX and ported to the Linux kernel. XFS is the default root filesystem on modern Enterprise Linux distributions (RHEL, CentOS Stream, Rocky Linux, AlmaLinux).

Key Architectural Characteristics of XFS

1. Allocation Groups (AGs): XFS divides a storage volume into equal-sized chunks called Allocation Groups. Each AG manages its own free space and inode index using independent B+ trees, allowing the kernel to perform completely concurrent, lock-free parallel I/O operations across multiple threads.
2. Dynamic Inode Allocation: Unlike ext4 (which preallocates a fixed number of static inodes across the disk during formatting), XFS creates inodes dynamically on demand as new files are written. An XFS filesystem never runs out of inodes as long as free disk space remains!
3. Guaranteed Metadata Logging: XFS journals all filesystem metadata operations (allocations, directory updates, extent shifts), ensuring rapid crash recovery by replaying the log during kernel mount.

Creating XFS with mkfs.xfs

Command Syntax:
  mkfs.xfs [options] <device>

# Format /dev/sdb2 as an XFS volume with label 'FAST_DATA'
# mkfs.xfs -f -L "FAST_DATA" /dev/sdb2
meta-data=/dev/sdb2              isize=512    agcount=4, agsize=6553600 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, spinodes=0, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1
data     =                       bsize=4096   blocks=26214400, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=12800, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

---

5. XFS Administration: xfs_info, xfs_admin & xfs_growfs

XFS provides dedicated maintenance utilities distinct from traditional ext tools:

1. xfs_info <mountpoint>

Displays geometry, block size, Allocation Group counts, and feature flags of a mounted XFS filesystem:

# Query geometry of mounted XFS filesystem
$ xfs_info /mnt/fast_data

2. xfs_admin <options> <device>

Modifies volume labels and UUIDs on an unmounted XFS filesystem:

# Change label on unmounted XFS volume
# xfs_admin -L "NEW_LABEL" /dev/sdb2

# Generate and assign a new random UUID
# xfs_admin -U generate /dev/sdb2

3. xfs_growfs <mountpoint> (Online Expansion)

When an underlying disk partition or LVM logical volume is enlarged, xfs_growfs expands the XFS filesystem to fill the newly available space.

⚠️ LPIC-1 Trap — Target Argument for xfs_growfs: Unlike ext resize tools (which accept the device node /dev/vg0/lv0), xfs_growfs requires the mounted mount point path (e.g., xfs_growfs /var), and the filesystem must be mounted read-write!

# Expand mounted XFS filesystem to fill underlying expanded partition
# xfs_growfs /mnt/fast_data

⚠️ LPIC-1 Trap — XFS Cannot Be Shrunk: An XFS filesystem can be grown online to any size, but XFS filesystems CANNOT be shrunk, reduced, or downsized under any circumstances. If you need to shrink an XFS volume, you must back up data, destroy the volume, recreate a smaller volume, and restore data.

---

6. Interchange Filesystems: VFAT and exFAT

Objective 104.1 names four filesystem families for mkfs: ext2/ext3/ext4, XFS, VFAT and exFAT. The last two are not Linux-native — they exist so that removable media can be read by Windows, macOS, cameras, and UEFI firmware.

# Format a USB stick as FAT32 with a volume label
# mkfs.vfat -F 32 -n "TRANSFER" /dev/sdb1

# The EFI System Partition must be FAT32
# mkfs.vfat -F 32 /dev/sda1

# Format a large SD card as exFAT for files over 4 GiB
# mkfs.exfat -n "MEDIA" /dev/sdc1

# The generic frontend reaches the same binaries
# mkfs -t vfat -F 32 /dev/sdb1
# mkfs -t exfat /dev/sdc1

mkfs.vfat is also reachable as mkfs.fat and mkdosfs from the dosfstools package; mkfs.exfat ships in exfatprogs. Neither filesystem stores UNIX ownership or mode bits — permissions are synthesised at mount time from the uid=, gid=, umask=, dmask= and fmask= mount options.

Exam Trap — The 4 GiB FAT32 Wall: FAT32 stores file size in a 32-bit field, so a single file cannot exceed 4 GiB − 1 byte. Copying a 5 GB video or a large ISO to a FAT32 stick fails with File too large even when gigabytes are free. exFAT was created specifically to lift that limit while keeping cross-platform compatibility, which is why modern high-capacity SD cards ship pre-formatted as exFAT.

---

7. Btrfs: Basic Feature Awareness

Objective 104.1 asks for basic feature knowledge of Btrfs — specifically multi-device filesystems, compression, and subvolumes. You will not be asked to administer a Btrfs array; you need to recognise the three capabilities and the vocabulary.

Btrfs ("B-tree filesystem") is a copy-on-write filesystem: it never overwrites a block in place, it writes a new copy and updates the pointer. That single design choice is what makes cheap snapshots and checksummed self-healing possible.

The Three Features the Objective Names

1. Multi-device filesystems. Unlike ext4 or XFS, a single Btrfs filesystem can span several block devices directly — no LVM and no mdadm layer required. It implements its own RAID-style profiles for data and metadata independently.

# Create one filesystem striped across two disks (RAID0 data, mirrored metadata)
# mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc

# Create a two-disk mirror
# mkfs.btrfs -d raid1 -m raid1 -L "POOL" /dev/sdb /dev/sdc

# Add a third disk to a live filesystem and rebalance onto it
# btrfs device add /dev/sdd /mnt/pool
# btrfs balance start /mnt/pool

# Show which devices back a mounted Btrfs filesystem
# btrfs filesystem show /mnt/pool

2. Transparent compression. Btrfs can compress data as it is written and decompress it on read, invisibly to applications. It is enabled as a mount option, not at format time.

# Mount with zstd compression
# mount -o compress=zstd /dev/sdb /mnt/pool

# Persist it in /etc/fstab
# /dev/sdb  /mnt/pool  btrfs  compress=zstd:3,noatime  0 0

3. Subvolumes. A subvolume is an independently mountable, independently snapshottable directory tree inside one filesystem. Subvolumes share the parent's free-space pool — they are not fixed-size partitions — which is what makes them cheaper than LVM logical volumes.

# Create subvolumes
# btrfs subvolume create /mnt/pool/@home
# btrfs subvolume create /mnt/pool/@var

# List them
# btrfs subvolume list /mnt/pool

# Mount one subvolume at a specific path
# mount -o subvol=@home /dev/sdb /home

# Snapshot a subvolume (near-instant, copy-on-write, read-only with -r)
# btrfs subvolume snapshot -r /mnt/pool/@home /mnt/pool/@home_2026-08-29

Exam Rule: Three Btrfs facts carry the objective. (1) Btrfs manages multiple devices natively, so it needs neither LVM nor mdadm. (2) Compression is a mount option (compress=zstd), not a mkfs option. (3) A subvolume is not a partition — it has no fixed size and shares the filesystem's free space with its siblings. Also note that Btrfs is checked with btrfs check, not with fsck.ext4 or xfs_repair.