APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

What is mount?

© July 2006 Anthony Lawrence

I had a recent email question that asked "How do you use the mount command correctly, in plain English, and what does it do?"

Whenever someone says "in plain English", you know that they have been frustrated by "man" pages. Actually, the beginning of the man page for "mount" isn't too bad. Here it is from my Mac:

The mount command calls the mount(2) system call to prepare and graft a special device or the remote node (rhost:path) on to the file system tree at the point node. If either special or node are not provided, the appropriate information is taken from the fstab(5) file.

That's pretty straight forward and concise, but it does assume you understand what a file system is and what a special device or remote node might be. The man page for the system call (man 2 mount) is a little different:

The mount() function grafts a filesystem object onto the system file tree at the point dir. The argument data describes the filesystem object to be mounted. The argument type tells the kernel how to interpret data (See type below). The contents of the filesystem become available through the new mount point dir. Any files in dir at the time of a suc- cessful mount are swept under the carpet so to speak, and are unavailable until the filesystem is unmounted.

But does that really explain it to the uninitiated? Probably not, but as is so often the case, where do we start? How far back do we need to unwind abstractions before it becomes clear what is going on?

You may be furrowing your eyebrows right now. "What's so difficult", you wonder. Well.. let me take you back a few years.

In the beginning, we had floppy disks. Floppy disks stored files, and that was that. There were no folders, no directories, just files. You had commands to list the files ("dir" on DOS, for example), and commands to execute them if they were programs. You could copy, delete, and so on. Hierarchies of files were actually used long before DOS, so I'm just using that as an example.

Pretty simple. There were limits: you could only have so many files on a disk no matter how small they were, but that didn't bother most folks. You had your disks, and your files were right there in plain sight.

Then came directories, and panic set in. Really.

I was already doing computer support when hierarchical file systems started appearing in PC's. People didn't "get" it. Oh, some did, but for others the leap to this was almost too much. I can well remember being puzzled by it myself at first - I just couldn't "see" it, couldn't get a mental image of what this meant. People would describe this in terms of filing cabinets: you could throw your papers in haphazardly or you could organize them into folders. That analogy helped some, but others were still blank and helpless.

I dredged all that up because it shows that the mental image we have of how our computers work can vary from person to person. When I click on a folder to open it, I "see" that from the perspective of a programmer: I'm opening a file, and reading the contents, which consists of other files. Those files may be documents or they may be directories (folders) that again are lists of more files. From my programmer mind set, I know that each entry must have flags that tell what kind of "file" this is (document or folder or whatever - we'll get to "whatever" in a minute) and pointers that get to actual data storage. But what's the mental image of a non-programmer?

"Magic" is probably the general answer. No clue how it works, and no interest. Nothing wrong with that, and it may be that this has become so ordinary and commonplace that there is no associated imagery: the computer interface itself may be all that is necessary: click on the folder icon to see more files and more folders. The computer has become simple enough that most folks may not even need analogies to understand it.

So now we're back to where we started. How do we, in "plain English", explain "mount"? Do we need to start with the basics: this is all just magnetic domains?

Do we need to get into the "whatever" mentioned above, the magical device files that aren't documents and aren't folders? Maybe, maybe not. In this case, the person asking was using a Mac and was actually asking about a ".dmg" file. With Macs, you ordinarily just click on a ".dmg" (or use "hdiutil attach file.dmg") and a "whatever" file (/dev/disk1 etc.) is allocated for your use and melded with the .dmg, a temporary folder is created under /Volumes, the allocated device is then mounted there, and that's it. More magic, though of course old Unix folk immediately realize that something like a loopback had to have happened in the background: that .dmg got itself associated with a device file somehow. So now we're in a mess: bad enough that we have to try to explain mount, but now we need to get into loopbacks? Oh my.

No, we're getting too geeky. Let's try for a visual: imagine drawing your desktop on a projector transparency. Now let's draw another desktop on another transparency. Put one transparency on top of the other so that just one folder of one is on top of one folder of the other. There's your "mount". Got it?

That may be all some people need. Others are going to want to get into the details, but the projector transparency image is enough for a lot of people.

Is that "plain English"? Maybe. It's not enough for a programmer (but the man page probably was, so that's OK). It probably puts a reasonable image in the minds of most non-geekish computer users - most should grasp "mount" from that. Will it satisfy everyone? Probably not.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> What is mount?

Inexpensive and informative Apple related e-books:

Take Control of iCloud, Fifth Edition

Take Control of Automating Your Mac

Take Control of Numbers

Take Control of Preview

Photos: A Take Control Crash Course

More Articles by © Anthony Lawrence

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. (Arthur Conan Doyle)

Linux posts

Troubleshooting posts

This post tagged:


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode