Skip to content

Creating Filesystems


A partition from the last few files is just defined space — nothing has actually written a filesystem structure onto it yet. mkfs (“make filesystem”) is the command that does that, and it’s the direct, hands-on follow-through on everything the last chapter covered conceptually.

The Command Family

mkfs isn’t really one command — it’s a small family, one variant per filesystem type, following a consistent naming pattern:

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

Each one formats the given partition with that specific filesystem type, based directly on the comparison from the last chapter. You can also invoke mkfs with a -t flag specifying the type instead, which is functionally identical:

sudo mkfs -t ext4 /dev/sdb1

Both forms exist in common use — the dotted form (mkfs.ext4) is generally more common in everyday use and documentation.

Warning

mkfs destroys any existing data on the target partition immediately, with no confirmation prompt beyond what the specific tool happens to show. This is exactly the kind of command the lsblk-before-you-act habit from earlier in this section exists for — confirm the target device and partition number with lsblk immediately before running any mkfs command, every single time, especially since a partition that already has some filesystem on it will format over that previous one silently.

Giving A Filesystem A Label

Beyond just formatting, you can attach a human-readable label at creation time — genuinely useful later when you’re identifying disks by something more memorable than a raw device path:

sudo mkfs.ext4 -L backup-drive /dev/sdb1

-L backup-drive sets the filesystem’s label to backup-drive. The exact flag for setting a label varies slightly between filesystem types — mkfs.xfs uses -L too, but always check man mkfs.<type> for the specific tool you’re using rather than assuming every flag transfers identically across all three.

A Full Hands-On Example

Picking up from the partitioning tools chapter — say fdisk was used to create a fresh partition at /dev/sdb1. Confirm it exists and isn’t already something you need first:

lsblk -f

If /dev/sdb1 shows no filesystem type listed under FSTYPE, it’s genuinely empty and safe to format:

sudo mkfs.ext4 -L project-data /dev/sdb1

You’ll see mkfs.ext4 print a summary of what it created — inode count, block size, journal size, and similar details straight out of the last chapter’s explanation, now made concrete.

Verifying What You Just Created

Two tools confirm the result. lsblk -f, already introduced in the first chapter of this section, now shows the new filesystem:

lsblk -f
NAME   FSTYPE LABEL         UUID                                 MOUNTPOINT
sdb1   ext4   project-data  4a2b1c3d-5e6f-7890-abcd-ef1234567890

blkid gives a more detailed, filesystem-focused view of the same information, listing every block device with an identifiable filesystem:

sudo blkid
/dev/sdb1: LABEL="project-data" UUID="4a2b1c3d-5e6f-7890-abcd-ef1234567890" TYPE="ext4"

That UUID value is worth paying attention to now, even though you won’t use it hands-on until the next chapter — it’s a unique identifier generated for this specific filesystem, and it’s the recommended way to reference this partition later, rather than its device path, precisely because of the naming-instability caveat from the first chapter of this section (/dev/sdb isn’t guaranteed to always mean the same physical disk across reboots, but a filesystem’s UUID doesn’t change).

What’s Next

The partition now has real structure — you can verify it exists and even reference it by label or UUID. What you can’t do yet is actually use it, since nothing has told Linux where in the filesystem tree this new filesystem should appear. That’s mounting, covered next, along with /etc/fstab — the chapter that makes a mount survive a reboot instead of needing to be redone by hand every time.

Last updated on