What is mount?

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.

Comments?

More Articles by Anthony Lawrence - Find me on Google+

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.