Open a fresh Linux shell and muscle memory reaches for a drive that is not there. No C: drive. No D:. Linux gives the whole machine one tree. It starts at a single slash, and every disk, USB stick, and network share you ever attach hangs somewhere off that one tree. Windows hands each device its own root and a letter. Linux mounts everything into a single hierarchy, and once that picture clicks, the filesystem stops feeling like trivia you have to memorize.

Ask the machine where you are standing the moment you log in, then climb to the top and look around:

Linux has one directory tree rooted at /. There are no drive letters; storage gets attached into the tree at a mount point. Roughly eight top-level directories cover almost everything you do day to day. Learn what each one holds, learn the difference between an absolute path and a relative one, and you can find your way around any distribution from Ubuntu to Rocky. This part is the map of that tree, plus the two defaults that quietly trip people up.

The slash on its own, /, is the root of the whole system. Every path that begins with a slash is an absolute path: it spells out the full route from the root, so /home/pranay/notes.txt means the same file no matter where you are standing when you type it. A path that does not begin with a slash is relative: it is read starting from your current directory. If you are in /home/pranay and you type notes.txt, you get the same file. Move somewhere else and that same relative path points at something different or nothing at all.

Two shorthand characters do most of the walking. A single dot . means the current directory. Two dots .. mean the parent, one level up. So cd .. climbs toward the root and cd ../.. climbs two levels. The tilde ~ is your home directory, whatever its real path happens to be, and cd - jumps back to wherever you just were.

pwd prints where you are. cd moves you. ls shows what is here. That is ninety percent of navigation. Here is a real short session that starts lost and ends oriented:

Notice the . and .. entries at the top of ls -la. They are real directory entries, present in every directory, which is why cd .. works everywhere. The -a flag reveals names that start with a dot, the hidden files where most of your personal config lives.

The layout is not random. It follows the Filesystem Hierarchy Standard, a written spec that tells distributions where system files belong. That is why an admin who learned on Debian can sit down at a Red Hat box and still know that config lives in /etc and logs land in /var/log. You do not need all of it on day one. You need the handful you touch constantly, and a rough idea of what the rest is for so you do not go poking in the wrong place.

Two of these are worth a second look because they are not files on any disk. /proc and /sys are virtual filesystems the kernel builds in memory. When you read /proc/cpuinfo you are not opening a file someone saved, you are asking the running kernel a question and getting the answer formatted as text. That is the practical face of the old Unix idea that most things can be reached as if they were files. Storage that you plug in later, a second disk or a USB stick, gets mounted into /mnt or /media, which ties straight into how cloud block storage and virtual machine disks show up inside a Linux guest.

Here is the default that catches out people who learned the old layout. On every current mainstream distribution, /bin, /sbin, and /lib are no longer separate directories. They are symbolic links that point into /usr. Check it yourself and the arrows give it away:

The leading l and the arrow tell you these are links, not directories. So /bin/ls and /usr/bin/ls resolve to the exact same file on disk. This change is called the /usr merge, and Fedora shipped it back in Fedora 17, with Ubuntu, Debian, Arch, and the Red Hat family all following. Fedora went a step further and folded /usr/sbin into /usr/bin as well, so the split between ordinary and admin commands is disappearing too.

Why did it happen? The original reason for a tiny /bin separate from /usr was hardware from decades ago. Disks were small and expensive, so the boot-critical tools sat on the fast local disk in /bin while /usr could live on a slower or networked disk mounted later. Modern boot handles /usr during early startup through the initramfs, so the split no longer buys anything. Merging the directories makes the system simpler and easier to reason about. The takeaway for you: do not waste effort memorizing which commands sit in /bin versus /usr/bin. On the machines you will work on, it is one place wearing two names.

Two commands answer the question you will ask most often about the filesystem: how full is it. df reports free space per mounted filesystem. du adds up the size of a directory and what is under it. Start with df to see the big picture:

Now the failure that eats an afternoon. A service starts throwing No space left on device. You run df -h, and it calmly reports the disk is only sixty percent full. Everything looks fine, yet writes keep failing. The disk is not out of space. It is out of inodes, the fixed-count records that track each file. Millions of tiny session files or cache entries can exhaust the inode table long before the bytes run out. There is a second flag for exactly this:

There it is: IUse% 100. Every inode is spoken for. The fix is to find and clear the directory full of tiny files, often something like a runaway session or mail queue. Track it down by size and by count. du handles size:

That one lesson, that a full inode table looks nothing like a full disk in df -h, separates people who fix the outage in five minutes from people who spend an hour deleting large files that were never the problem.

Linux paths are case sensitive. Documents, documents, and DOCUMENTS are three different names, and a script that works on your Mac can fail on a Linux server for that single reason.

The other classic: running a destructive command with a relative path while standing in the wrong directory. rm -rf logs deletes whatever logs means right now, which depends entirely on your current directory. Run pwd before anything with rm in it. Cheap habit, saved careers.

Plenty of beginner guides hand you a flashcard list of all twenty top-level directories and tell you to drill them. That is wasted effort. In real work you touch /etc, /home, /var, /tmp, /usr, and the mount points, and you look up the rest the two times a year you need them. Memorizing /srv versus /opt from a table teaches you nothing about why a service will not start. Learning to read /var/log when it does teaches you everything.

One more piece of received wisdom worth trimming. You will hear that in Linux everything is a file. It is a useful mental model and it is why /proc and /dev work the way they do, but taken as gospel it misleads. Network sockets, processes, and threads are not files you can cat. Treat the phrase as a design instinct, not a law. Believe the instinct enough to try reading something as a file, and check the man page when it does not behave like one.

What is the difference between /bin and /usr/bin?

The honest 2026 answer: on any current distribution, none. /bin is a symlink to /usr/bin, so both names resolve to the same files. Historically /bin held the small set of commands needed to boot and repair a system before /usr was mounted, while /usr/bin held the rest. The /usr merge collapsed that split. Saying the split still exists as separate directories is the wrong answer, and mentioning the merge shows you have looked at a real modern system.

Prove the /usr merge on your own machine and confirm two names point at one file. Run this and read the arrows and the inode numbers:

ls -ld /bin
ls -i /bin/ls /usr/bin/ls

If the two paths report the same inode number from ls -i, you have proven they are the same file, not a copy.

What is the difference between /mnt and /media? Both are mount points for extra storage. The convention is that /media is where the system auto-mounts removable drives like USB sticks, while /mnt is where you mount things by hand for temporary work. Nothing enforces it; it is a habit that keeps manual mounts from colliding with automatic ones.

Why is there a /root when /home already exists? The root user gets its own home outside /home on purpose. If /home lives on a separate disk that fails to mount, the administrator can still log in and their home directory still works, because /root sits on the root filesystem that is always present.

Is /tmp really wiped on reboot? Often, but do not count on it. Many distributions clear /tmp at boot or on a timer, and some mount it in RAM so it vanishes on shutdown. Behavior varies by distribution, so never leave anything in /tmp you would miss.

Can I make my own top-level directory? You can, as root, but resist it. Custom software belongs in /opt or /srv, and your own files belong under /home. A stray /myapp at the root confuses every other admin and every backup script that assumes the standard layout.

What is actually inside /proc? A live view of the kernel and every running process, generated on demand. cat /proc/cpuinfo shows your processors and cat /proc/meminfo shows memory. Nothing there occupies disk space; it disappears when the machine powers off.

You can now stand anywhere in the tree, name any file two different ways, and read how full the disk really is. Next we leave the map behind and pick up the tool you drive it all with: the shell itself, where every command you just ran gets its real power. Keep the Complete Guide open and work through the parts in order.

Filesystem Hierarchy Standard 3.0, Linux Foundation
The Case for the /usr Merge, freedesktop.org
Unify /usr/bin and /usr/sbin, Fedora Project