Linux

Fedora project proposes major changes to filesystem hierarchy

Red Hat developers are proposing a fairly significant change to the Linux/Unix filesystem hierarchy. Find out what they're trying to fix, and what it could potentially break, if it goes forward.

For many years, Linux and Unix-like operating systems have adhered to a particular way of organizing files, but with the evolution of the OS, this system has grown in complexity and, some would say, downright messiness. This has led two Red Hat developers, Harald Hoyer and Kay Sievers, to propose a solution. But even though the current filesystem has some inherent quirks that can make it confusing for some, trying to clean it up introduces its own new set of problems.

First, here's a quick snapshot of the root filesystem:

  • bin: Essential command binaries
  • boot: Static files of the boot loader
  • dev: Device files
  • etc: Host-specific system configuration
  • lib: Essential shared libraries and kernel modules
  • media: Mount point for removeable media
  • mnt: Mount point for mounting a filesystem temporarily
  • opt: Add-on application software packages
  • sbin: Essential system binaries
  • srv: Data for services provided by this system
  • tmp: Temporary files
  • usr: Secondary hierarchy
  • var: Variable data

In a nutshell, the Fedora change would "move all executable files into the /usr/bin directory and their libraries into /usr/lib or /usr/lib64, as needed," as reported by IT World's Brian Profitt.

While most agree that the changes make good sense, the problem is that it goes against the Filesystem Hierarchy Standard (FHS) based on Version 7 Unix and Sun operating system/ Solaris. In addition, it has repercussions for shell scripts. Profitt goes on to explain the dilemma:

A lot of shell scripts have #!/bin/sh as their first line (or #!/bin/bash or what have you). If /bin went away, any script with a call like this inside would break. Some scripts might use env to locate the script interpreter, and since env is already in /usr/bin/env, these won't have problems.

Then there's the convention used to override shell built-ins by calling the full path to the non-built-in version. If the full path is used and the built-in has been relocated, that's going to break, too.

This is an experiment that developers will definitely want to keep tabs on. What do you think of this proposal?

About

Selena has been at TechRepublic since 2002. She is currently a Senior Editor with a background in technical writing, editing, and research. She edits Data Center, Linux and Open Source, Apple in the Enterprise, The Enterprise Cloud, Web Designer, and...

4 comments
peter_erskine
peter_erskine

There are dozens of aspects of Red Hat and Fedora that do need looking at (starting I suggest with some working terminfo data!) so it is really annoying that that start fritzing with things that "ain't broke".

pgit
pgit

Why move things down? Why not dump /usr/lib and /usr/lib into just plain /lib and /bin? It would seem to me making the system shallower/shorter would be the advantage. The only way this would help is if you have /usr on a separate partition, which very few Linux distributions do by default. Then you wouldn't need such a large /, as that would have boot related stuff, a few internal commands and the configs, which being plain text they don't take up a lot of space. But then in this era of TB drives, NAS etc, there's no critical need to squeeze the / into as small a space as possible. I'll have a look at the link seanferd posted when I get a moment. Meantime I'll try to imagine what those arguments for this idea are. Drawing a blank atm. :)

dajomu1
dajomu1

Can't backward compatibility be retained by symlinks even though the proposed changes from Red Hat gets implemented?

seanferd
seanferd

Some have almost entirely different hierarchies, so I wonder how well they would adhere to a new one. RH is going to have to convince at least IBM and Dell, so I wonder what they will have to say about this. As described here, though, I don't see much of a change, just enough to break existing software. I see from the linked article that doing snapshots (btrfs is the example) would be easier, but what about changing the method of doing snapshots instead? I don't really have a goat in this fight at this time, but I expect there should be a long list of good reasons before making this change or something similar. The post in the lists at least makes a decent argument. (Link from article: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus%3D155792 )

Editor's Picks