Linux Directory Structure (File System Structure) Explained with Examples

http://www.thegeekstuff.com/2010/09/linux-file-system-structure/

by skala • 14 years ago

182 24 14 years ago

Thank you. I wish they would just rename the directories already.

Obligatory link to the standard (FHS), since it's buried in the comments under that blog post: http://proton.pathname.com/fhs/pub/fhs-2.3.html

pfraze• 14 years ago

So /usr/local implies that the binaries were built for the local machine, and might not work elsewhere?

zdw• 14 years ago

Generally, or "local to the site".

In the mid-80's to 90's when disk space was at a premium, it was quite common to have one big file server that had the /usr/local, /opt, /home, etc. hierarchies on it, shared out over NFS to the other desktop machines on the network.

As most/all of the machines would be similar architectures, they could share the binaries. In cases where there was more than one architecture, there would frequently be multiple file servers, one per arch. Another remnant of this on modern systems: "/usr/share" usually contains data like machine-independent help files that could be mounted across architectures.

The result of this was that users could hotseat from machine to machine, and site-specific software would only need be installed once, which was a space/complexity win.

harshreality2• 14 years ago

/usr/local/ is a place to put software that's not managed the same way. It keeps the systemwide package management from overwriting or otherwise disrupting software it doesn't know about.

Software in /s?bin/ /usr/s?bin/ /usr/lib/ etc. is not guaranteed to work on another machine. A binary could be for a different architecture, even if it was installed by the main package manager. You can't copy /usr/bin/ binaries from an arm platform to an x86 platform, for instance. You can't copy optimized crypto software using aes-ni instructions to pre-aes-ni systems; it'll crash. You can't even reliably copy binaries from a different machine with the same cpu model, if the machines are using different package sets that will result in library incompatibilities.

dredmorbius3• 14 years ago

It's "locally managed". Under, say, Debian Policy, a Debian package may create directories under /usr/local, but it may not create files, or delete either files or directories. Which means that the local administrator can add/remove software here.

/opt is another directory that's generally intended for third-party software. So, say, you'll find /opt/oracle/, /opt/dell/, /opt/google/, /opt/ibm/, etc., in which various enterprise tools go. There's no reason for space rationalization you can't move this to /usr/local/opt and symlink back up to the root filesystem, as some prefer and I generally do.

Where things get confusing is when you're on, say, an Mac and install software from the DarwinPorts project, which creates a managed tree ... under /usr/local. This strikes me as somehow wrong (/opt/darwinports/ would be a better choice IMO).

http://www.debian.org/doc/debian-policy/

IsaacL• 14 years ago

I've been using Linux for about 4 years now, and I've tried to find a document like this a few times and failed. This is probably the best reference on this topic I've seen yet.

nirkage2• 14 years ago

`man hier`

javert• 14 years ago

Wow. How would one go about discovering this?

paisible• 14 years ago

Very cool - thanks for mentionning this !

kazoolist• 14 years ago

FWIW, I think the true Filesystem Hierarchy Standard (see other comments on this page) is a much better reference.

Ideka• 14 years ago

There's https://wiki.archlinux.org/index.php/Filesystem_Hierarchy_St... too. Probably Arch-specific, but I bet most stuff applies to Unix in general as well.

jamesu• 14 years ago

This merely tells you what is usually placed in the filesystem, not why.

I find the explanation provided on the busybox mailing list to be far more insightful: http://lists.busybox.net/pipermail/busybox/2010-December/074...

mtrn• 14 years ago

Yes, that was eye-opening; it even got 800+ on HN: http://news.ycombinator.com/item?id=3519952

keithpeter• 14 years ago

The autobiography The Periodic Table, by Primo Levi, see Chapter 12, Chromium. Recipes are perpetuated. Reasons forgotten!

Spoiler: The extract mangles the humour, but you get the idea.

http://www.philosophyblog.com.au/extract-from-the-periodic-t...

dewitt• 14 years ago

And if you want more technical details, the Filesystem Hierarchy Standard is the place to look:

  http://www.pathname.com/fhs
  http://www.pathname.com/fhs/pub/fhs-2.3.html

Somewhat Linux-specific, but worth reading even if you're on OS X, as much of the content is the same.

zarvox• 14 years ago

Heh. The OS landscape has changed over time, as disks have gotten much faster and much larger, and some of the design decisions made decades ago no longer make sense.

Fedora is moving everything from /bin, /sbin, /lib, and /lib64 into /usr because maintaining this separation no longer really makes sense: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...

dredmorbius3• 14 years ago

It's fair to say that some of the specific design constraints no longer apply.

However, that's not to say that we haven't arrived at similar conclusions (a root filesystem accessible at boot, multiply hierarchies of additional storage under, say, /usr, /usr/local, etc.

I mean, the ultimate conclusion of the UsrMerge argument would be to put all directories on root.

I find the justifications for UsrMerge to be specious at best, and better described as counterfactual. I strongly suspect that a large part of the reasoning is Red Hat's chronic inability to enforce discipline among its software packagers (both within and outside of Red Hat).

koenigdavidmj• 14 years ago

Fedora put everything in /usr so that if you are sharing it, you can NFS mount just one directory instead of several.

andrewflnr• 14 years ago

I wrote something a bit more detailed a couple years ago, partly as a school project and partly because I couldn't find it anywhere else: http://andrewfleenor.users.sourceforge.net/fhs/fhs.xml

It goes into much more depth, and you can expand and close directories to see what's inside them. I was pretty proud of it.

zanny• 14 years ago

I've always wondered, are the directories hard coded into the kernel or are there some EV's somewhere or something pointing to them?

I can guarantee one of the bigger problems with mainstream Linux adoption is that the top level of the file system is covered in OS directories. For all its faults, keeping the OS under C:/Windows keeps most Grandmothers from deleting system32.

Linux Directory Structure (File System Structure) Explained with Examples

Related Stories