Disks and Filesystems

Every byte you've written in this course - every file you touched, every directory you mkdir'd - lives on a block device, formatted with a filesystem that knows how to organize bytes into files and directories. This lesson is about seeing that structure instead of taking it for granted.

Block devices and partitions

lsblk ("list block devices") shows the physical (or virtual) disks attached to a machine, and how each one is sliced into partitions:

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    0    50G  0 disk
├─sda1        8:1    0    50G  0 part  /
└─sda2        8:2    0   512M  0 part  [SWAP]

sda is the whole disk; sda1 and sda2 are partitions carved out of it. One partition holds the root filesystem (/); another is swap - disk space the kernel uses as overflow memory when RAM runs low.

Mounting: attaching a filesystem to a path

A partition on its own isn't usable - it has to be mounted: attached to a directory (a "mount point") so its files appear as part of the single filesystem tree everything in Linux lives under. The kernel remembers these attachments in /etc/fstab so they're restored automatically at every boot:

mount /dev/sdb1 /mnt/data      # attach sdb1's filesystem at /mnt/data
umount /mnt/data               # detach it again

This is exactly why Linux has no drive letters like C: or D: - a second disk doesn't get its own root, it gets grafted into the existing tree at whatever path you choose.

Filesystem types

The partition also has a filesystem format - the on-disk data structure that actually tracks which blocks belong to which file:

df vs. du: the question everyone confuses

Both report disk usage, but at different levels:

df -h          # how full is each MOUNTED FILESYSTEM?
du -sh /var    # how much space does this one DIRECTORY use?

df answers "is this disk about to fill up?" du answers "which directory is the one filling it?" A classic troubleshooting sequence runs both back to back: df -h to spot a filesystem that's nearly full, then du -sh /* on it to find the directory responsible.

Inodes: the other thing that can run out

Every file has metadata - owner, permissions, timestamps, and where its data blocks live - stored in a structure called an inode. stat shows you a file's inode number directly:

stat notes.txt

A filesystem has a fixed number of inodes set aside when it's formatted. It's entirely possible to have free disk space (per df -h) but zero free inodes - usually caused by millions of tiny files - and get "No space left on device" anyway. df -i reports inode usage instead of byte usage on a real system.

Hard links vs. symbolic links

ln creates a link, but there are two different kinds:

ln source.txt hardlink.txt        # hard link: another name for the SAME inode
ln -s source.txt symlink.txt      # symbolic link: a small file that just points at a path

A hard link is indistinguishable from the original - both names point at the same data, and deleting either one leaves the file intact under its other name. A symbolic link ("symlink") is its own tiny file containing a path; delete the original and the symlink is left pointing at nothing (a "broken link").

Try it

lsblk
df -h
du -sh /var
stat welcome.txt
mount /dev/sdb1 /mnt/data
mount
umount /mnt/data

Further reading

• "How Linux Works" by Brian Ward (No Starch Press) - its filesystem chapter explains inodes, mounting, and how ext4 actually lays out data on disk.
• "The Linux Command Line" by William Shotts (No Starch Press) - practical coverage of df, du, mount, and /etc/fstab.