How to Format a Drive or Partition on Fedora
You plugged in a new external drive or added a second disk to your Fedora machine. The drive has old data you don't need, or it's fresh out of the factory with a filesystem Fedora doesn't recognize. You need to wipe the partition and set up a clean filesystem so you can store files, back up your home directory, or mount it for a specific service. One wrong command here deletes data permanently. There is no undo button.
What's actually happening
Formatting a drive doesn't just erase files. It writes a filesystem structure onto the raw blocks of the disk. Think of the drive as a warehouse. Formatting builds the aisles, labels the shelves, and creates the inventory ledger. Without that structure, the kernel doesn't know where to put files or how to find them later. The mkfs family of commands builds that structure. mkfs stands for "make filesystem." You choose the type of warehouse layout based on what you plan to store.
The kernel relies on the filesystem metadata to manage inodes, block allocation, and journaling. When you run mkfs, you are telling the kernel how to interpret the bits on that specific device. Different filesystems optimize for different workloads. Some prioritize speed for large files. Others focus on data integrity or advanced features like snapshots. Fedora supports several options out of the box.
Verify the device before you touch it
Before you run any formatting command, verify the device path. Running mkfs on the wrong device destroys your root filesystem or your data partition instantly. The terminal will not stop you if you type the wrong path. Use lsblk to list all block devices. Look for the size and the current mount point. The size is the most reliable indicator. A 4TB drive will show 3.6T or 4.0T in the SIZE column. Never format a device that is currently mounted. Unmount it first.
Here's how to list block devices and check their status.
lsblk -f
# -f shows filesystem type, label, and UUID
# Verify the target device matches the size and is not mounted
# Look for the FSTYPE column to see if a filesystem already exists
Convention aside: lsblk is the standard tool for inspecting block devices on Fedora. It shows the device tree, sizes, and mount points in a readable format. Avoid fdisk -l for quick checks. fdisk outputs raw partition tables that are harder to parse when you just need to confirm a size or mount point.
Check if the device is part of an LVM volume group. If the partition is a physical volume, formatting it breaks the volume group and destroys all logical volumes inside it.
Here's how to check for LVM metadata.
sudo pvs /dev/sdXn
# Check if the device is part of an LVM physical volume
# If output shows a VG name, do not format
# Formatting an LVM PV destroys the volume group metadata
If pvs returns output, stop. You are looking at an LVM component. Use vgreduce or pvremove if you intend to dismantle the LVM setup. Otherwise, find the correct partition.
Unmount the partition
You cannot format a mounted filesystem. The kernel locks the device to protect active data. Attempting to format a mounted device results in an error or silent corruption. Unmount the partition before proceeding. If the system reports the device is busy, identify the process holding it open.
Here's how to unmount the target partition.
sudo umount /dev/sdXn
# Unmount the partition before formatting
# Formatting a mounted device corrupts the filesystem and risks kernel panic
# If this fails, the device is busy and you need to stop the process
If umount fails with target is busy, use fuser to find the culprit.
Here's how to identify processes using the device.
sudo fuser -vm /dev/sdXn
# Identify processes holding the device open
# Kill or stop those processes before unmounting
# This resolves "target is busy" errors
Convention aside: journalctl -xe is your friend when mount operations fail. If you get a cryptic error, run journalctl -xe immediately after. The x flag adds explanatory text and the e flag jumps to the end. Most mount errors show up as kernel messages or systemd unit failures in the journal. Read the actual error before guessing.
Choose and create the filesystem
Fedora defaults to ext4 for Workstation and XFS for Server. Btrfs is available for advanced features. Choose the filesystem based on your workload. Run the specific mkfs command for your choice.
ext4
ext4 is the default for Fedora Workstation. It's stable, widely supported, and handles most desktop workloads without fuss. It supports journals, extents, and delayed allocation. Use ext4 for general purpose storage, home directories, or drives that need to be readable by other Linux distributions.
Here's how to create an ext4 filesystem.
sudo mkfs.ext4 /dev/sdXn
# Create an ext4 filesystem on the target partition
# mkfs.ext4 runs e2fsck first to ensure the device is clean
# This step prevents accidental formatting of a valid filesystem
The command runs a quick check first. If it detects an existing filesystem, it prompts you to confirm. Type y only if you are certain the data is gone or irrelevant. mkfs.ext4 also sets default mount options and creates the journal.
XFS
XFS is the default for Fedora Server. It scales well for large files and high throughput. It uses delayed allocation and extent-based allocation to minimize fragmentation. XFS is excellent for data hoarding, media servers, or high-performance storage. XFS cannot be shrunk. It can only be grown. If you format XFS, you cannot resize the partition down later without reformatting.
Here's how to create an XFS filesystem.
sudo mkfs.xfs -f /dev/sdXn
# Create an XFS filesystem
# -f forces creation if a signature is already detected
# Use -f only when you are certain the data is gone or irrelevant
The -f flag forces creation over an existing signature. XFS is paranoid about overwriting valid filesystems. Use -f when you have verified the device and are ready to wipe it. Without -f, mkfs.xfs may refuse to run if it detects a valid superblock.
Btrfs
Btrfs offers snapshots, transparent compression, and subvolume management. It's a copy-on-write filesystem. Use Btrfs when you need built-in backups via snapshots, or if you want to experiment with subvolumes for containers or isolated environments. Btrfs is more complex to manage than ext4 or XFS. It requires tools like btrfs and snapper for full functionality.
Here's how to create a Btrfs filesystem.
sudo mkfs.btrfs -L mybackup /dev/sdXn
# Create a Btrfs filesystem with a label
# -L sets the volume label for easy identification
# Labels help when mounting by label in /etc/fstab
The -L flag sets a label. Labels make it easier to identify the drive in lsblk and allow you to mount by label in /etc/fstab. Btrfs creates a default subvolume at the root. You can create additional subvolumes later for organization.
Convention aside: Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. When you configure mounts in /etc/fstab, you are editing a user configuration file. The system reads /etc/fstab at boot to assemble the filesystem tree. Changes here persist across reboots.
Verify the result
Check the filesystem type and UUID after formatting. The UUID changes every time you format. If you have an entry in /etc/fstab pointing to the old UUID, the mount will fail. Verify the new UUID matches what you expect.
Here's how to confirm the filesystem details.
lsblk -f /dev/sdXn
# Confirm the filesystem type appears in the FSTYPE column
# Verify the UUID has changed to a new value
# Check the LABEL column if you set one
Use blkid to see the raw attributes.
Here's how to inspect the filesystem attributes.
sudo blkid /dev/sdXn
# Display filesystem type, UUID, and label
# Use this output to update /etc/fstab if needed
# The UUID is the safest identifier for mounting
Convention aside: blkid queries the device directly and returns the UUID, type, and label. This is the source of truth for mount configurations. When editing /etc/fstab, copy the UUID from blkid. UUIDs are unique and stable across device name changes. Labels are human-readable but can duplicate across drives. Prefer UUIDs in production configurations.
Mount the new filesystem
Formatting prepares the drive. Mounting makes it accessible. Create a mount point directory and mount the device. Verify access by listing the directory.
Here's how to mount the formatted partition.
sudo mkdir -p /mnt/data
# Create a mount point directory
# The directory must exist before you can mount the filesystem
sudo mount /dev/sdXn /mnt/data
# Mount the newly formatted partition
# Verify access by listing the directory contents
Check permissions. The root user owns the mount point by default. Adjust ownership if you need user access.
Here's how to set ownership for a user.
sudo chown $USER:$USER /mnt/data
# Change ownership to the current user
# This allows the user to read and write without sudo
# Replace $USER with a specific username if needed
Verify the mount is active.
Here's how to confirm the mount status.
findmnt /mnt/data
# Show mount information for the target directory
# Verify the source device and filesystem type
# Check the OPTIONS column for mount flags
Convention aside: findmnt is the modern tool for querying mount points. It shows the device, mount point, type, and options in a clean table. Use findmnt instead of parsing /proc/mounts or mount output. findmnt integrates with systemd and shows transient mounts correctly.
Common pitfalls and errors
Formatting errors usually print to stderr immediately. Read the error message. Most failures are preventable.
Device or resource busy
You forgot to unmount. The kernel locks the device. Run umount first. If umount fails, use fuser to kill the process.
Device appears to contain a partition table
You targeted the whole disk instead of a partition. mkfs detected a partition table on /dev/sda instead of /dev/sda1. Format the partition, not the disk. Targeting the disk wipes the partition table and destroys all partitions.
XFS signature detected
XFS refuses to overwrite a valid filesystem without -f. Add -f to force creation. Use wipefs if mkfs still fails.
Here's how to wipe filesystem signatures.
sudo wipefs -a /dev/sdXn
# Remove all filesystem signatures from the device
# Use this only when mkfs refuses to run due to existing signatures
# This action is irreversible and destroys the partition metadata
Permission denied
You ran the command without sudo. mkfs requires root privileges to write to block devices. Add sudo to the command.
XFS cannot shrink
You formatted XFS and now need to resize the partition down. XFS does not support shrinking. You must back up the data, resize the partition, reformat, and restore. Plan your partition sizes carefully before formatting XFS.
Check the UUID. Mounting by old UUID causes silent failures.
When to use each filesystem
Use ext4 when you want the standard Fedora desktop experience with broad compatibility and reliable performance for mixed workloads.
Use XFS when you are managing large files, high-throughput transfers, or a server environment where scalability matters more than shrinking partitions.
Use Btrfs when you need built-in snapshots, transparent compression, or subvolume management for backups and container storage.
Stick with the existing filesystem if the drive already works and you only need to clear files. Formatting is destructive. rm -rf is often safer for clearing data.
Verify the device path twice. One typo wipes the wrong disk.