mkfs, mount, umount, findmnt

mkfs - a hands-on Linux lab on a real virtual machine.

Take a raw partition all the way to a working mounted directory and cleanly back down. Format with mkfs.xfs (the RHEL 10 default, which can grow but never shrink) or mkfs.ext4, attach it with mount device mountpoint, control it with -o options like ro, verify it with findmnt (target, source, fstype, options) and measure it with df -h, then detach with umount. Serves EX200 file-systems: create, mount, unmount, and use vfat, ext4, and xfs file systems.

You just carved a fresh partition out of a spare disk. It has a size, a device name, a place in the world: /dev/vdb1. So you try to save a file onto it, and nothing works. There is no place to put the file. The partition is real, but it is raw: a blank slab of storage with no shelving inside it.

A block device is just capacity. Before it can hold a single file, you have to lay down a structure that tracks names, directories, and where each file's bytes live. That structure is a filesystem, and putting one on a device is called formatting. This lesson takes a raw partition all the way to a working, mounted directory you can write into, then cleanly back off again. It is the most-repeated task on the whole exam.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2) with a spare disk formatted XFS and mounted at /mnt/data. A few values, like the exact block counts and the mount options string, depend on the disk and kernel, so treat those as illustrative. What is stable everywhere is the SHAPE: mkfs.xfs prints a meta-data header, mount attaches a device to a directory, and findmnt reports the target, source, type, and options.

A filesystem is the organizing structure written onto a block device so the system can store and retrieve files by name. Picture the raw partition as an empty warehouse. The filesystem is the shelving, the aisle labels, and the index card that says which box sits where. Without it, the warehouse is just walls.

The tool that installs that structure is mkfs, short for make filesystem. You do not run bare mkfs; you run a type-specific version. mkfs.xfs writes an XFS filesystem, mkfs.ext4 writes an ext4 one, mkfs.vfat writes a FAT filesystem for USB sticks and EFI partitions. The exam tells you which type to use; you pick the matching mkfs.<type>.

On RHEL 10, XFS is the default filesystem. Fresh installs use it, the exam leans on it, and unless a task names another type, XFS is the safe choice. It is fast and scales to very large volumes. It has one sharp edge you must remember: an XFS filesystem can grow but it can never shrink. You can add space to it later; you can never take space away. ext4, by contrast, can both grow and shrink, which is the main reason a task might ask for ext4 instead.

That grow-only rule is not a bug, it is a design tradeoff XFS made for speed and scale. Remember it as a planning rule: when you size an XFS volume, err small, because you can always grow it but you can never claw space back. The exam has been known to punish an oversized XFS volume you cannot undo.

Start by laying a filesystem onto the raw partition /dev/vdb1. The command is mkfs.xfs followed by the device. When it runs, it prints a block of meta-data describing what it built: the inode size, how many allocation groups, the block size, and the total block count.

Before you run it, know what success looks like: a meta-data header naming your device, not an error. Format the partition:

mkfs.xfs /dev/vdb1

prompt: [root@servera ~]# answer: mkfs.xfs /dev/vdb1 output: meta-data=/dev/vdb1 isize=512 agcount=4, agsize=65536 blks data = bsize=4096 blocks=262144, imaxpct=25 hint: The XFS formatter is mkfs.xfs, then the device path: mkfs.xfs /dev/vdb1

The meta-data=/dev/vdb1 line confirms XFS wrote its structure onto that exact device. isize=512 is the inode size, agcount=4 is the number of allocation groups XFS uses to spread work across the disk, bsize=4096 is the 4-kilobyte block size, and blocks=262144 is the total block count. You do not memorize these numbers. You confirm two things: the device name is the one you meant, and the command printed a header instead of an error. The partition now has shelving inside it.

mkfs is destructive and there is no undo. It wipes everything on the target device and lays down an empty filesystem. The classic exam disaster is a typo in the device path: mkfs.xfs /dev/vdb formats the WHOLE disk instead of the partition /dev/vdb1, or worse, names a disk that holds data. Read the device path twice before you press Enter. Confirm with lsblk first if you are unsure which device is which.

A formatted filesystem is still invisible until you attach it to a directory. That directory is called the mount point, and attaching is called mounting. The command is mount <device> <mountpoint>. After it succeeds, every file you write into that directory actually lands on the device.

The mount point must already exist as an empty directory, so you make it first with mkdir. Then mount the freshly formatted partition onto /mnt/data:

mount /dev/vdb1 /mnt/data

prompt: [root@servera ~]# answer: mount /dev/vdb1 /mnt/data output: hint: The order is mount, then the device, then the mount point: mount /dev/vdb1 /mnt/data

No output, which is success: mount is silent when it works. The partition /dev/vdb1 is now attached at /mnt/data, and anything written under /mnt/data is stored on that disk. Two things to remember: the mount point directory must exist before you mount, and this mount lasts only until the next reboot. Making it survive a reboot means writing a line into /etc/fstab, which is its own lesson. For now, prove the mount is live.

The clearest way to inspect a mount is findmnt. Hand it a path and it prints one tidy row with four columns that matter: TARGET (the mount point), SOURCE (the device), FSTYPE (the filesystem type), and OPTIONS (how it is mounted). If the path is not a mount point, findmnt prints nothing, which is itself an answer.

Before you run it, predict the row: TARGET should read /mnt/data, SOURCE /dev/vdb1, and FSTYPE xfs. Inspect the mount:

findmnt /mnt/data

prompt: [root@servera ~]# answer: findmnt /mnt/data output: TARGET SOURCE FSTYPE OPTIONS /mnt/data /dev/vdb1 xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota hint: The mount inspector is findmnt, then the path you want to check: findmnt /mnt/data

One row tells the whole story. TARGET /mnt/data is where it lives, SOURCE /dev/vdb1 is the device behind it, FSTYPE xfs confirms the format took, and OPTIONS lists how it is mounted. The first option, rw, means read-write: the default. This is the command that answers whether a mount really exists and what it looks like, in one line, without you parsing a wall of text. Whenever a task says mount this and verify it, findmnt <path> is the verify.

The exact OPTIONS string depends on the kernel and filesystem defaults, so yours may list slightly different flags. What is stable is the front of the list: a normal mount starts with rw (read-write), and the FSTYPE reads xfs for an XFS volume. Read those two first; the rest are XFS internals like inode64 and noquota that the kernel fills in.

findmnt proves the mount exists; df -h proves how big it is and how full. df means disk free, and the -h flag prints human-readable units (M for megabytes, G for gigabytes) instead of raw blocks. Point it at the mount point to see the size, used, available, and percent-full for just that filesystem.

Check the size of the new mount:

df -h /mnt/data

prompt: [root@servera ~]# answer: df -h /mnt/data output: Filesystem Size Used Avail Use% Mounted on /dev/vdb1 960M 51M 910M 6% /mnt/data hint: The disk-free tool with human units is df -h, then the path: df -h /mnt/data

The row reads /dev/vdb1 at 960M total, 51M used, 910M available, 6% full, mounted on /mnt/data. A brand-new XFS filesystem is never truly empty: that 51M used is XFS's own metadata, the shelving overhead written by mkfs. So a fresh format showing a little space already used is normal, not a fault. Your exact numbers depend on the disk size, but the six-column shape is identical everywhere.

Two more moves finish the toolkit. First, mount options. The -o flag changes how a filesystem is mounted; the one the exam cares about most is ro, read-only, which blocks all writes. You can apply it to a live mount without unmounting by remounting: mount -o remount,ro /mnt/data. After that, findmnt shows the OPTIONS string now leading with ro instead of rw.

Second, taking it down. umount detaches a filesystem from its mount point. Note the spelling: it is umount, with no first n, one of the oldest quirks in Unix. You hand it either the device or the mount point. Detach the filesystem:

umount /mnt/data

prompt: [root@servera ~]# answer: umount /mnt/data output: hint: The detach command is spelled umount, no n after the u, then the mount point: umount /mnt/data

Silence again means success: umount detached /mnt/data, and the directory is back to being an ordinary empty folder. Run findmnt /mnt/data now and it prints nothing, because the mount is gone. One trap to know: if umount reports target is busy, some process still has a file open under that mount, or your own shell is sitting inside it. Step out with cd / and try again, or find the culprit with lsof /mnt/data.

Scaffolding off. No command is printed this time. You have every piece you need.

You have just mounted a filesystem at /mnt/data. A task tells you to confirm it is really mounted and to read back its device, its filesystem type, and its options in one clean line. You do not want df, which measures size; you want the mount itself, spelled out. Which single command, given the path, prints that one-row TARGET, SOURCE, FSTYPE, OPTIONS summary?

prompt: [root@servera ~]# answer: findmnt /mnt/data output: TARGET SOURCE FSTYPE OPTIONS /mnt/data /dev/vdb1 xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota hint: It is the mount inspector, not df. The tool is findmnt, then the path /mnt/data.

findmnt /mnt/data prints exactly one row: TARGET /mnt/data, SOURCE /dev/vdb1, FSTYPE xfs, and the OPTIONS string. That is the verify step for every mount task on the exam. df -h would have told you how full it is, but only findmnt names the source device, the type, and the options together. When a task says mount and verify, this is the command that earns the verify.

You earned this cheat sheet. Every row is a form you just ran or built:

The one thing to burn in for the exam: XFS is the RHEL 10 default and can only GROW, never shrink. When a task does not name a type, reach for mkfs.xfs. When it says verify a mount, reach for findmnt.

This lesson used a live mount, which vanishes at the next reboot. To make a mount survive a reboot you write it into /etc/fstab, which is its own lesson. The full exam pattern is always the same four steps: format with mkfs, make the mount point, mount it, then persist it in /etc/fstab and test with mount -a before you trust it.

The practice terminal has walked you through the whole loop. mkfs.xfs to lay a filesystem onto a raw partition, mount to attach it to /mnt/data, findmnt and df -h to prove and measure it, -o to control how it mounts, and umount to take it cleanly back down. Every one of those you typed yourself.

The file-systems module mission is where you run these against a real RHEL 10 machine with a spare disk. A full VM boots for you, with its own real block devices waiting to be formatted and mounted. The mission hands you objectives that use exactly what you practiced here. Format a partition with the right filesystem type, mount it at a named directory, verify it with findmnt, and take it down cleanly. One difference from this lesson: the mission shows no commands. You read the objective, recall the mkfs.xfs and mount and findmnt forms, and type them. That recall is what makes it stick on exam day.

Finish the other file-systems lessons, then go format and mount a real disk.

Practice mkfs, mount, umount, findmnt in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.