Why is Linux's filesystem designed as a single directory tree?

Question

Can anyone explain why Linux is designed as a single directory tree?

Whereas in Windows we can have multiple drives like C:\, and D:\, there is a single root in Unix. Any specific reason there?

Answer 1

Since the Unix file system predates Windows by many years, one may re-phrase the question to "why does Windows use a separate designator for each device?".

A hierarchical filesystem has the advantage that any file or directory can be found as a child of the root directory. If you need to move data to a new device or a network device, the location in the file system can stay the same and the application will not see the difference.

Suppose you have a system where the OS is static and there is an application that has high I/O requirements. You can mount /usr read-only and put /opt (if the app lives there) onto SSD drives. The filesystem hierarchy doesn't change. Under Windows this is much more difficult, particularly with applications that insist on living under C:\Program Files\

Answer 2

This is partly for historical reasons, and partly because it makes more sense this way.

Multics

Multics was the first operating system to introduce the hierarchical file system as we know it today, with directories that can contain directories. Citing “A General-Purpose File System For Secondary Storage” by R.C. Daley and P.G. Neumann:

Section 2 of the paper presents the hierarchical structure of files, which permits flexible use of the system. This structure contains sufficient capabilities to assure versatility. (…)

For ease of understanding, the file structure may be thought of as a tree of files, some of which are directories. That is, with one exception, each file (e.g., each directory) finds itself directly pointed to by exactly one branch in exactly one directory. The exception is the root directory, or root, at the root of the tree. Although it is not explicitly pointed to from any directory, the root is implicitly pointed to by a fictitious branch which is known to the file system. (…)

At any one time, a user is considered to be operating in some one directory, called his working directory. He may access a file effectively pointed to by an entry in his working directory simply by specifying the entry name. More than one user may have the same working directory at one time.

As in many other aspects, Multics sought flexibility. Users can work in a subtree of the filesystem and ignore the rest, and still benefit from directories to organize their files. Directories were also used for access control — the READ attribute allowed users to list the files in a directory, and the EXECUTE attribute allowed users to access files in that directory (this, like many other features, lived on in unix).

Multics also followed the principle of having a single storage pool. The paper does not dwell on this aspect. A single storage pool was a good match with the hardware of the time: there were no removable storage devices, at least none that users would care about. Multics did have a separate backup storage pool, but this was transparent to users.

Unix

Unix took a lot of inspiration from Multics, but aimed at simplicity whereas Multics aimed at flexibility.

A single hierarchical filesystem suited Unix well. Like with Multics, storage pools were usually not relevant to users. However, there were removable devices, and Unix did expose them to users, via the mount and umount commands (reserved to the “super-user”, i.e. the administrator). In “The UNIX Time-Sharing System”, Dennis Ritchie and Ken Thompson explain:

Although the root of the file system is always stored on the same device, it is not necessary that the entire file system hierarchy reside on this device. There is a mount system request with two arguments: the name of an existing ordinary file, and the name of a special file whose associated storage volume (e.g., a disk pack) should have the structure of an independent file system containing its own directory hierarchy. The effect of mount is to cause references to the heretofore ordinary file to refer instead to the root directory of the file system on the removable volume. In effect, mount replaces a leaf of the hierarchy tree (the ordinary file) by a whole new subtree (the hierarchy stored on the removable volume). After the mount, there is virtually no distinction between files on the removable volume and those in the permanent file system. In our installation, for example, the root directory resides on a small partition of one of our disk drives, while the other drive, which contains the user's files, is mounted by the system initialization sequence. A mountable file system is generated by writing on its corresponding special file. A utility program is available to create an empty file system, or one may simply copy an existing file system.

The hierarchical filesystem also has the advantage of concentrating the complexity of managing multiple storage devices into the kernel. This meant that the kernel was more complex, but all applications were simpler as a result. Since the kernel has to care about hardware devices but most applications don't, this is a more natural design.

Windows

Windows traces its ancestry back to two lineages: VMS, an operating system originally designed for the VAX minicomputer, and CP/M, an operating system designed for early Intel microcomputers.

VMS had a distributed hierarchical filesystem, Files-11. In Files-11, the full path to a file contains a node name, an account designation on that node, a device name, a directory tree path, a file name, a file type and a version number. VMS had a powerful logical name feature allowing shortcuts to be defined to specific directories, so users would rarely have to care about a directory's “real” location.

CP/M was designed for computers with 64kB of RAM and a floppy drive, so it went for simplicity. There were no directories, but a file reference could include a drive indication (A: or B:).

When MS-DOS 2.0 introduced directories, it did so with a syntax that was compatible with MS-DOS 1 which itself followed CP/M. So paths were rooted at a drive with a single-letter name. (Also, the slash character / was used in VMS and CP/M to start command line options, so a different character had to be used as a directory separator. This is why DOS and later Windows use backslash, though some internal components also support slash).

Windows retained compatibility with DOS and the VMS approach, so it kept the notion of drive letters even when they became less relevant. Today, under the hood, Windows uses UNC paths (originally developed by Microsoft and IBM for OS/2, of related ancestry). Although this is reserved for power users (probably due to the weight of history), Windows does allow mounting through reparse points.

Answer 3

There are no security concerns behind having a single directory tree.

The guys who designed Unix had a bunch of experience with operating systems that required users to know what physical device contained a given resource. Since part of the purpose of an operating system is to create an abstract machine on top of real hardware, they thought it much simpler to dispense with addressing resources by their physical location and decided to put everything into a single tree of names.

This is only one part of the genius behind the design of Unix.

Answer 4

Note that the drive letter names from MS-DOS which persist into modern Windows are a red herring here. Drive letter names are not the best representation of a file system structure which has multiple roots. They are a strawman implementation of such a system.

A properly implemented filesystem that supports multiple roots would allow arbitrary naming for the volumes, like dvdrom:/path/to/file.avi. Such as system would get rid of the laughable user interface issues that plague Windows. For instance, if you plug in a device such as a camera, the Windows Explorer UI makes you believe that there is a device called Camera (or whatever), and that you have a path like Computer\Camera\DCIM\.... However, if you cut and paste the textual version of this path out of Explorer, it doesn't actually work because some of the pathname components are a user interface fiction, not known to the underlying OS. IN a properly implemented system with multiple roots, it would be fine: there would be a camera:\DCIM\... path that is recognized uniformly at every level in the system. Moreover, if you ported over an old hard drive from an OLD PC, you would not be stuck with some drive letter name like F:, but rather you would be able to name it whatever you want, like old-disk:.

So, if Unix did have multiple roots in the filesystem structure, it would be done sanely like this, and not like in MS-DOS and Windows with one-letter drive names. In other words, let us only compare the Unix scheme to a good multi-root design.

So, why doesn't Unix have a sane multiple-roots implementation, in favor of sane one-root implementation? It's probably just for simplicity. Mount points provide all the functionality of being able to access volumes via names. There is no need to extend the namespace with an additional prefix syntax.

Mathematically speaking, any disjoint tree graph ("forest") can be joined by adding a root node and making the disjoint pieces its children.

Moreover, it is more flexible that the volumes do not have to be at the root level. Since there is no special syntax which denotes volume (it is just a path component), mount points can be anywhere. If you bring in three old disks to your machine, you can have them as /old-disk/one, /old-disk/two, etc. You can organize disks however you want, the way you organize files and directories.

Applications can be written which depend on paths, and the validity of paths can be maintained when the storage devices are reconfigured. For instance, applications can use well-known paths like /var/log and /var/lib. It's up to you whether /var/log and /var/lib are on the same disk volume or on separate ones. You can migrate a system to a new storage topology, while preserving the paths.

Mount points are a good idea, which is why Windows has had them since around Windows 2000.

Volume mount points are robust against system changes that occur when devices are added or removed from a computer. Microsoft Technet

Answer 5

Both *nix and Windows mount their drives. In Windows these are automatically mounted in mount points that, by default, are in ascending alphabetical order. These defaults are:

• A: and B: => floppies
• C: => first partition of first hard drive
• D: => next partition or next hard drive or CD/DVD drive if no other partitions are present.

Each of these mount points is a directory.

In *nix, the mount points are decided by the user. For example, I have one partition mounted as /, and another as /home. So, /home is a separate drive, it would be the equivalent of say E: on Windows.

In both cases, Windows and *nix, mount points are separate directories. The only difference is that in *nix, these separate directories are sub-directories of /, of C: while in Windows, every mount point is mounted directly under the /, under My Computer let's say.

From the user's perspective, the main advantage is that the mounts are completely transparent. I don't need to know that the directory /home is actually on a separate partition. I can just use it as a normal directory. Instead, in DOS, I would have to explicitly call it by the mount point's name, say E:\home

External drives are mounted in pretty much the same way in both systems. Say D: for Windows and /mnt/cdrom for Linux. Each of these is a directory, I don't really see the difference. When you put a CDROM into your drive under Windows, the disk is mounted to D: just like in Linux.

Answer 6

I agree with the answers above, especially Doug O'Neal's answer, but I think that they all miss a little something, as does the explicit device mount points like MS-DOS "C:" or "A:".

Rob Pike wrote The Hideous Name about syntax of names, but Russ Cox boiled it down:

Name spaces... are most powerful when new semantics can be added without adding new syntax.

A single name space where devices can be arbitrarily mounted allows for really flexible operations. I regularly use /mnt/sdb1 and /mnt/cdrom to temporarily place a currently-unused disk or CD into the overall file system. It's not at all uncommon to have home directories on a NFS server, so that no matter what machine you log in to, you get the same $HOME everywhere.

It comes down to this: having special syntax for special things puts definite limits on what you can do. If you can only mount an unused disk or CD or DVD, or a network filesystem/"share" on "E:" or "W:" or whatever, you've got a lot less flexibility.

Answer 7

This is silly. Windows also has a single hierarchy point. But it is hidden and non-standard. As most things windows.

In this case, it is the "My Computer" concept. That is the equivalent of root (/) in Unix. Remember that root is a concept that exists in the kernel. you like it or not. Just like windows treat the "My Computer". of course, you can mount a partition on root in unix, and that is what most people do. And lots of things will look at a specific path for things (e.g. /etc/) but you are not limited by it. By all means, mount your drives in /C:/. you are not forbidden to do that in unix.

C:\ is not a root in windows, it is the mount point of one partition. Which MUST be on the top level "My Computer". While in unix you can mount a partition under any other tree. So linux you can have C: mounted in / while you have D: mounted in /mnt/d/... or even also mounted in / but that is tricky and depends on how the two file systems behave when mounting on top of an already mounted path.

So you can get the exact same as you have with windows by "forcing" yourself to follow the same limitations windows randomly imposes on you.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Then you would have to pass in the mount options on the boot options. since you will not have a /etc/... but that's also simulating the limitations windows imposes, as that what it does.

Answer 8

The reason for Windows having drive letters probably goes back further than Microsoft and DOS. Assigning letters to removable drives was common on IBM systems, so Microsoft may have just been acting on IBM's instructions by copying CP/M. And initially, DOS didn't have directories anyway.

When MS-DOS ran on computers with one or two removable disks and no fixed media, you didn't really need a file system with directories. With one, or maybe two, 180 kilobyte disks, you never had enough files to have much trouble organizing them.

https://en.wikipedia.org/wiki/Drive_letter_assignment

Answer 9

Actually, Linux is based on Unix (or is Unix, see discussion) and Unix comes from mainframe environment, where using multiple devices was quite obvious. Mounting devices within single directory tree gives you maximal flexibility, and doesn't limit the number of devices the operating system can access.

On the other side, DOS letters for drives are a good design for a PC with 1 or 2 floppy stations and single disk drive. Big floppy 5,25' is always A:, little one 3,5' is always B:, and disk drive is always C:. You always know if you copy a file to the floppy or somewhere to the disk. You don't need any flexibility if you can't physically connect more than 2 floppy drives and 2 (or 4) hard disks.

DOS design was more end-user-friendly, while Unix design is administrator-friendly. Now drive letters are a burden for Windows, users more rely on automatically opening explorer window with removable drive content than knowing its letter... Ubuntu does the same, actually.

Answer 10

That's not true, actually. Windows uses another paths scheme (well, not the same)

"Unit Letters" are only something to remember easily paths, disks and partitions.

ARC paths define the path of a file in windows (but they are visible to the user only on boot):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

In Windows NT there's no relation between disks, partitions and unit letters: You can "put" an entire volume in a folder (e.g.: c:\myseconddisk could be an entire physical disk!)

Answer 11

Two things I would like to point out -

1. Hard drives in linux are actually in a way assigned letters/names, like /dev/sdb1. But they can be mounted anywhere to be reached from the single / root structure
2. The most common reason that people (including myself in the past) had separate drives in Windows was to have somewhere to keep documents, music, programs, etc. so that when Windows inevitably needed to be reinstalled or replaced, be it upgrade or virus or file system failure, there was still access to those files. I don't have this problem in linux - the file system is much more reliable, the OS doesn't break unless by some direct action or mistake on my part (ooh! a bleeding edge repo, let's try that!), and upgrades are FAR simpler. And, in the rare case I've had to reinstall, since all the software was available through repos or ppa's that I added (and I could easily copy my home dir with a live disk), starting from scratch and getting back to where I was takes only a couple of hours versus days of searching for new installers and/or old cd keys when restoring my programs in Windows.

Answer 12

If you look back in history you can also see that Unix started at the time of 8 track tape systems for audio and 9 track IBM data systems (8 tracks/8 bits for data, one for parity). Technically very much the same.

At that time the information about the location of files was stored in parts of the information on tape and forward and backward defined when you read data from the tape (like a file, with startposition and end signature); it explains also you why you had not just one FAT at the start of the drive—you had multiple to speed up the lookup. And if you had multiple drives they where linked inside of /dev and via the address of the file you moved between the devices.

I believe you could have the view that it started simply earlier and that the decision behind MS Dos area (CP/M) and later Windows NT is simply related to VM mainframe drive letters instead of a single point of entry because at the time it looked more modern, data amounts of today didn't exist and they didn't think that you would eventually end up having not enough drive letters or that it would be over cluttered.

9-Track-Drive and Drive Letter assignment