A disk you just added to a Linux box does nothing until you tell the kernel where its bytes belong. Plugging it in gets you a block device and not one usable file. The distance between /dev/sdb showing up in lsblk and /data holding real files is three moves: partition, format, mount. Skip the last move and your writes land on the wrong disk. Get the permanent version wrong and the machine drops to an emergency shell on the next boot, which is a rough place to learn this.

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   40G  0 disk
├─sda1   8:1    0    1G  0 part /boot
└─sda2   8:2    0   39G  0 part /
sdb      8:16   0  100G  0 disk

Read the bottom line. sdb is a 100G disk with no children and an empty mountpoint column. The kernel sees it, but nothing on the system can write to it yet. That is the starting state for every new disk.

New to this? Follow along on a spare VM or on a loopback file, both shown below, and nothing on your real machine is at risk. Already running servers? The one habit worth keeping is nofail on data mounts and a mount -a check before every reboot, because the alternative is a 03:00 call about a box stuck at the emergency prompt.

From block device to mount point

Each stage wraps the one before it. The partition is a slice of the raw disk. The filesystem is the bookkeeping that turns that slice into somewhere files can live. The mount point is the directory where that filesystem appears in your normal tree. You cannot mount a disk with no filesystem, and a filesystem with no mount point is invisible to everything except tools that address the device directly.

What lsblk is telling you

The TYPE column separates a whole disk from a part that lives on it. MOUNTPOINTS is the fastest way to see what is actually in use: blank means the device is not mounted anywhere. RM flags removable media, which matters because USB disks are the ones that vanish and hang your boot. If lsblk shows your new disk with no partition rows under it, you are at step zero and everything below applies.

Partitioning a new disk

Two tools do this job: fdisk for an interactive session and parted for scripted, repeatable commands. On a fresh disk you first write a partition table, then carve out a partition. Here is the scripted path with parted, which is the one worth memorising because you can paste it into a runbook.

$ sudo parted /dev/sdb --script mklabel gpt
$ sudo parted /dev/sdb --script mkpart primary ext4 0% 100%
$ sudo parted /dev/sdb --script print
Model: Virtio Block Device (virtblk)
Disk /dev/sdb: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  107GB   107GB                primary

Notice the File system column is empty. The ext4 word in mkpart is only a type hint written into the table, not a real filesystem. Nothing formats the partition yet. That happens in the next section. The partition you just made is /dev/sdb1.

GPT or MBR?

Use GPT. The old MBR scheme caps a single partition at 2 TiB and allows only four primary partitions, both of which are limits you can hit on modern hardware without trying. MBR is worth choosing in exactly one case: an old BIOS-only machine that refuses to boot from GPT. For a data disk on anything built in the last decade, mklabel gpt is the default and you can stop thinking about it.

Putting a filesystem on the partition

The mkfs family writes a filesystem onto a partition. Pick the filesystem, point it at /dev/sdb1, and it stamps the bookkeeping in place. Formatting is destructive to whatever was on that partition, so read the device name twice.

$ sudo mkfs.ext4 /dev/sdb1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 26214144 4k blocks and 6553600 inodes
Filesystem UUID: 7c9d2e5a-1f3b-4a2c-9d6e-2b8a1c4f5e60
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done

For xfs it is a single line, sudo mkfs.xfs /dev/sdb1, and it returns almost instantly even on a huge disk. The choice between the two comes down to a few real differences.

Here is where I part company with the usual hedging answer of it depends. For a plain data disk on a server, use xfs and move on. The one thing xfs cannot do is shrink, and shrinking a filesystem is something most people never do in the life of a machine. If you genuinely expect to make a volume smaller later, use ext4 and keep resize2fs in reach. Everyone else is choosing between fine and fine.

Mounting it, and making it stick

Mounting attaches the filesystem to a directory. Create the directory, mount the partition on it, and confirm with df.

$ sudo mkdir -p /data
$ sudo mount /dev/sdb1 /data
$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        98G   24K   93G   1% /data

This works right now and disappears on the next reboot. A manual mount is not remembered by anything. To make it permanent you add a line to /etc/fstab, and the safe way to name the disk there is not /dev/sdb1.

Why you mount by UUID and not /dev/sdb1

$ sudo blkid /dev/sdb1
/dev/sdb1: UUID="7c9d2e5a-1f3b-4a2c-9d6e-2b8a1c4f5e60" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a1b2c3d4-01"

Device names like /dev/sdb are assigned in the order the kernel probes hardware. Add a second disk, move a cable, or boot with a USB drive plugged in, and today's sdb can become tomorrow's sdc. An fstab entry pinned to /dev/sdb1 then points at the wrong disk, or nothing. The UUID is written into the filesystem itself and never changes, so that is what belongs in fstab.

# /etc/fstab
UUID=7c9d2e5a-1f3b-4a2c-9d6e-2b8a1c4f5e60  /data  ext4  defaults,nofail,x-systemd.device-timeout=10  0  2

$ sudo mount -a
$ findmnt /data
TARGET SOURCE    FSTYPE OPTIONS
/data  /dev/sdb1 ext4   rw,relatime,nofail

That single line has six fields, and each one earns its place.

Checking what is using the space

Two tools answer two different questions. df reports free space per filesystem. du adds up the size of a directory tree. You reach for df when a disk is filling up and for du when you need to find the thing filling it.

$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda2      ext4    39G   12G   25G  33% /
/dev/sdb1      ext4    98G   40G   53G  44% /data

$ du -sh /data/* | sort -h | tail -3
1.2G    /data/logs
8.4G    /data/backups
28G     /data/media

One trap catches everyone at least once: df says the disk is full but du adds up to far less. That gap is almost always a deleted file that a running process still holds open, so the blocks are not freed. Find it with sudo lsof +L1, then restart or signal the process holding it. The space comes back the moment the last handle closes.

Growing a disk without unmounting it

On a cloud VM or an LVM setup you often expand the underlying volume, then log in and find the filesystem still reports the old size. Growing the volume does not grow the filesystem on its own. It takes two steps, and both run while the disk stays mounted and in use. First stretch the partition to fill the bigger disk, then stretch the filesystem to fill the bigger partition.

$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        98G   40G   53G  44% /data

$ sudo growpart /dev/sdb 1
CHANGED: partition=1 start=2048 old: size=209713152 end=209715200 new: size=419428319 end=419430367

$ sudo resize2fs /dev/sdb1
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/sdb1 is mounted on /data; on-line resizing required
The filesystem on /dev/sdb1 is now 52428539 (4k) blocks long.

$ df -h /data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       196G   40G  148G  22% /data

Watch the space in growpart /dev/sdb 1. The disk and the partition number are two arguments, not the device /dev/sdb1, and passing the joined name is a common early mistake. For an xfs filesystem the second step changes to sudo xfs_growfs /data, and note it takes the mount point rather than the device. This live-grow path is the practical reason both filesystems handle growth the same way in daily work: growing is the operation you actually run, sometimes at 02:00 when a volume is filling faster than expected, and neither ext4 nor xfs makes you unmount to do it.

Command cheat sheet

Myth vs reality

A large share of Linux outages start at storage, usually a full root disk or a rushed fstab edit. The three-step workflow here is the same whether the disk is a physical drive, a volume attached to a cloud VM, or a virtual disk handed out by a hypervisor. Last part we read the machine's memory of what happened in the journal. Next we get the box talking to the network. Add a disk on a spare VM today, then reboot on purpose to prove your fstab line survives. The full path lives in the Complete Guide.

References

• Arch Wiki: fstab
• systemd.mount and x-systemd options
• Red Hat: Managing file systems

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts