Filesystem Types

Once a partition or LVM logical volume is ready, it needs a filesystem before it can store data — an empty block device itself has no concept of files or directories. This article compares the most widely used Linux filesystems (ext4, XFS, Btrfs, ZFS), shows how to create and inspect them, and explains which one fits which situation. The natural next step once a filesystem exists is either preparing it as swap or getting it ready for use through mounting.

What You Will Learn

By the end of this article you will be able to:

• explain the main differences between ext4, XFS, Btrfs, and ZFS, and each one's strengths and weaknesses;
• use mkfs (and its front-ends like mkfs.ext4, mkfs.xfs);
• get information about an existing filesystem with tune2fs and xfs_info;
• set and change a filesystem label;
• explain when and how to run a filesystem check (fsck);
• justify which filesystem to choose for a new project or server.

What a Filesystem Is and Why It's Needed

A partition or LV is just a sequence of bytes within a defined boundary. A filesystem is the structure layered on top of it, providing:

• mapping file and directory names to block numbers (inodes);
• storing file metadata (owner, permissions, modification time);
• managing free space (which blocks are used, which are free);
• in some cases — restoring consistency after an unexpected shutdown, through a journal.

Without a filesystem, a partition can only be used as swap or for raw data storage (as some database engines do).

Comparing the Main Filesystems

ext4

The latest link in the ext2 → ext3 → ext4 chain, purpose-built for Linux and the historical default for most distributions. A journaling, stable, widely supported filesystem. Both extending and shrinking are supported (both are more reliable unmounted, though extending can also be done online).

XFS

Optimized for large files and highly parallel I/O, and the default filesystem on Red Hat Enterprise Linux. Its strength is fast writing/reading of large files and stability at large sizes. Its main limitation: it cannot be shrunk — only grown.

Btrfs

A modern filesystem built on a copy-on-write (COW) architecture, with built-in snapshots, checksumming, and multi-disk (RAID-like) capabilities. It allows taking snapshots without LVM. Some distributions, such as Fedora and openSUSE, use it as the default root filesystem.

ZFS

Originally built for Sun Solaris, with very strong data integrity (checksumming), its own volume management (zpool, similar to LVM but integrated with the filesystem), and snapshot capabilities. Due to licensing incompatibility, it isn't included in the Linux kernel itself — it's installed separately via the zfsutils-linux package and DKMS. Widely used on large NAS/storage servers.

Creating a Filesystem: mkfs

mkfs is a common front-end for the various filesystem builders:

mkfs -t TYPE DEVICE

sudo mkfs -t ext4 /dev/sdb1

This command actually calls the matching specific command — mkfs -t ext4 and mkfs.ext4 produce identical results:

sudo mkfs.ext4 /dev/sdb1
sudo mkfs.xfs /dev/sdb2
sudo mkfs.btrfs /dev/sdb3

Each filesystem type has its own extra flags, for example:

sudo mkfs.ext4 -L data /dev/sdb1      # -L: create with a label
sudo mkfs.xfs -f /dev/sdb2            # -f: force-replace an existing filesystem

For the full list of flags, each filesystem has its own man page:

man mkfs.ext4
man mkfs.xfs

Getting Information About an Existing Filesystem

tune2fs — for the ext Family

sudo tune2fs -l /dev/sdb1

Filesystem volume name:  data
Filesystem UUID:         1a2b3c4d-5e6f-7890-abcd-ef1234567890
Filesystem state:        clean
Block size:               4096
Inode count:              1310720
Free blocks:               5108000
Mount count:               3
Maximum mount count:      -1

tune2fs -l prints all of a filesystem's metadata (state, block size, UUID, last check date). tune2fs is also used to change certain parameters (for example, the forced fsck check interval):

sudo tune2fs -c 30 /dev/sdb1   # force fsck every 30 mounts

xfs_info — for XFS

sudo xfs_info /mnt/data

meta-data=/dev/sdb2              isize=512    agcount=4, agsize=1310720 blks
data     =                       bsize=4096   blocks=5242880, imaxpct=25
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2

xfs_info only works on a mounted filesystem (called via the mount point or device path) — it shows information about XFS's internal structure (allocation groups, journal size).

General-Purpose Tools: blkid, lsblk -f, df -T

sudo blkid /dev/sdb1
lsblk -f
df -Th

NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sdb1   ext4   data  1a2b3c4d-5e6f-7890-abcd-ef1234567890  /mnt/data

Filesystem Labels

A label is a human-readable name that can be used in place of a UUID. /etc/fstab can reference either a UUID or a label.

sudo e2label /dev/sdb1 data          # set a label for ext2/3/4
sudo e2label /dev/sdb1               # show the current label

For XFS:

sudo xfs_admin -L data /dev/sdb2     # set a label (while unmounted)
sudo xfs_admin -l /dev/sdb2          # show the current label

Checking a Filesystem: fsck

fsck (file system check) checks for consistency errors in a filesystem (for example, after an unexpected power loss) and repairs them where possible. Like mkfs, fsck also routes to a filesystem-specific command (fsck.ext4, xfs_repair).

sudo umount /mnt/data
sudo fsck /dev/sdb1

fsck from util-linux 2.38
e2fsck 1.46.5 (30-Dec-2021)
data: clean, 11/1310720 files, 133589/5242880 blocks

For XFS, checking uses a different command:

sudo xfs_repair /dev/sdb2

xfs_repair also works on an unmounted filesystem; in cases of serious corruption, xfs_repair -L (clearing the log) may be required first — this discards the last unwritten transactions, so it's used only when there's no other option.

Practical Scenario: Creating and Checking ext4 on a New Partition

Situation. /dev/sdb2 (20 GiB), created in Partitions, has no filesystem yet. It needs to be prepared with ext4, given a label, and the result checked.

1. Confirm the partition has no filesystem

sudo blkid /dev/sdb2

If the command returns nothing (an empty exit), the partition is ready — safe to proceed.

2. Create the filesystem

sudo mkfs.ext4 -L appdata /dev/sdb2

mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 5242880 4k blocks and 1310720 inodes
Filesystem UUID: 9f8e7d6c-5b4a-3210-fedc-ba0987654321
...

3. Check the result

sudo blkid /dev/sdb2
sudo tune2fs -l /dev/sdb2 | head -10

/dev/sdb2: LABEL="appdata" UUID="9f8e7d6c-5b4a-3210-fedc-ba0987654321" TYPE="ext4"

4. Mount it and confirm

sudo mkdir -p /mnt/appdata
sudo mount /dev/sdb2 /mnt/appdata
df -hT /mnt/appdata

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdb2      ext4   20G   24K   19G   1% /mnt/appdata

Conclusion. The filesystem was created successfully and confirmed via label and UUID. The next step for a permanent connection is adding an entry to /etc/fstab via UUID, since a manual mount only applies for the current session.

Reserved Blocks: Why a "Full" ext Filesystem Still Has Space

A detail that trips up juniors in interviews: ext2/3/4 reserves 5% of the filesystem for root by default. When df shows 100% used for an ordinary user, root can often still write — and that 5% is deliberate. It keeps critical daemons (which usually run as root) able to log and write even when users have filled the disk, and it leaves the block allocator enough room to avoid heavy fragmentation.

sudo tune2fs -l /dev/sdb1 | grep -i "reserved block"

Reserved block count:     262144

On a large data volume (not the root filesystem), 5% is a lot of wasted space — 50 GiB on a 1 TiB disk. It's safe to lower it there:

sudo tune2fs -m 1 /dev/sdb1     # reserve 1% instead of 5%

Which Filesystem to Choose, and When

Common Mistakes

Trying to Shrink XFS

xfs_growfs only grows. If an XFS partition needs to shrink, the only path is creating a new, smaller filesystem and migrating data with rsync.

Applying mkfs to the Wrong Device

mkfs should target the intended partition (/dev/sdb1) or LV (/dev/vg_data/lv_app), never the whole disk (/dev/sdb) — otherwise the partition table gets overwritten, destroying every partition on it.

Using fsck or mkfs on a Mounted Filesystem

Both conflict with active writes. mkfs often refuses to run on a mounted device, but force flags like -f can bypass that protection — don't use them without deliberately intending to.

Treating a Label and a UUID as the Same Thing

A label is a human-chosen, changeable name; a UUID is a system-generated identifier that almost never repeats. Using UUID in fstab is recommended, since a label can accidentally collide between two filesystems.

Exercises

1. In a disposable VM, create ext4 on one empty partition and XFS on another, both with a label.
2. Compare tune2fs -l and xfs_info output — note which information is common (UUID, block size) and which is filesystem-specific.
3. Unmount an ext4 partition and check it with fsck; confirm the "clean" state in the result.
4. On a single partition, create ext4 first, then wipe it (mkfs.xfs -f) to create XFS instead — watch the TYPE field change via blkid.

Verification criterion: given a workload description (large media files, a database needing frequent rollbacks, a root filesystem that might need to shrink later), you should be able to recommend a filesystem and justify why.

Summary

A filesystem adds file and directory structure on top of a partition or LV; ext4 is the universal, stable standard, XFS is strong for large files but can't shrink, and Btrfs and ZFS are modern, integrated approaches that include snapshots and checksumming. The mkfs.* family creates filesystems, while tune2fs/xfs_info are the primary tools for inspecting an existing one. Once a filesystem is ready, the next step is either the mkswap/swapon process covered in Swap Management, if it's meant for swap, or Mount and Umount for an ordinary filesystem.

References

• man7.org: mkfs(8)
• man7.org: tune2fs(8)
• man7.org: fsck(8)
• kernel.org: ext4 Documentation
• XFS documentation (kernel.org)
• Btrfs documentation (kernel.org)
• OpenZFS documentation
• Red Hat: Overview of available file systems