Introduction
All right. You know what the filesystem is. You know what devices are, and how they're accessed. You know what the mount table is, and how the kernel goes from a request from a program to getting the data from the hardware. Guess what? Four lessons into the course, it's actually time to start doing something meaningful with that knowledge.
Mounting a volume
Adding a volume to the filesystem is accomplished with the
mount() system call. Like other system calls, such as
open() and read(), it is a function, called by a
program, which then requests that the kernel do something. In this case, that
"something" is mounting a volume, with a given filesystem implementation, under
a specific directory (the mount point).
Of course, the vast majority of us will never even touch that system call.
Instead, we just use a program that makes it for us - also called
mount. It takes different options on different systems - the
information I give here is from Linux, and some options may differ - check the
manual page (man mount) for your system.
For this exercise, you will need:
- To be logged in as root
- A CD-ROM or DOS/Windows-formatted floppy disk inserted into the drive, but
not already mounted (this can happen automatically on some systems - if you get
an error message saying such-and-such is already mounted somewhere else, then
unmount it as explained in the next section, then try again).
- A temporary directory to use as a mount point. I'll be using
/mymount/, so either create a directory with that name and follow me to the letter or substitute whatever directory you choose. Unless you're very sure you know what you're doing, don't use/mnt/! Although that directory was originally intended to be used for just what we're doing here (as a temporary mount point), many distributions of Linux, and (I believe) one or two other flavours of UNIX, use directories such as/mnt/cdrom/as normal mount points for removable volumes such as floppy disks and CD-ROMs. For reasons that may already be apparent, it's not a good idea to mount something on/foo/when something on your system may still want to use/foo/bar/. I believe that Mac OS X uses/Volumes/rather than/mnt/for its habitual mount points, which is much more sensible.
For the purpose of these instructions, I will assume that you are running Linux on the Intel i386 ("PC") architecture. The commands are very similar for other architectures, and broadly so for other UNIX flavours. Become root, then perform one of the following:
With a DOS floppy disk in first (or only) floppy drive:
root@rhodium:~# mount -t vfat /dev/fd0 /mymount/
With a CD-ROM in the CD-ROM drive:
root@rhodium:~# mount -t iso9660 /dev/cdrom /mymount/Note - where I use
/dev/cdrom, use the device file which
represents your CD-ROM device. Most systems have a symlink from
/dev/cdrom to the actual device (usually
/dev/hdc), so you can probably execute this command exactly
as given above.
Let's break that command down:
mount |
-t |
iso9660 |
/dev/cdrom |
/mymount |
| Mount a volume | with type: | iso9660 (the filesystem implementation used for CD-ROMs) |
from this formatted volume | on this mount point |
Note that the command for the floppy is exactly the same - it just uses a
different device file (/dev/fd0) and a different filesystem
implementation (vfat, Linux's name for the DOS/Windows FAT16 and
FAT32 filesystems).
Unmounting
When you do not want a volume connected to the filesystem any more, you can
unmount it. This is accomplished by the umount() system
call, but, just as with mount(), it is very rarely used. Instead,
one uses the umount command. It's very simple to use - you just
give it the mount point. To unmount the filesystem we've mounted above:
umount /mymount/
Virtual filesystems
To see a list of filesystem implementations supported by your kernel, look
at the file /proc/filesystems. In fact, while you're at it, you may
wish to take a poke around /proc/ (making sure not to write to
anything you're not sure about!). You'll find it stuffed with "virtual files" -
/proc/cpuinfo is the example I have mentioned before, but there are
also /proc/mem (memory information), /proc/devices
(devices connected to the system), and a host of others, including a directory
for each process currently running on your system, containing information such
as the current working directory, open files, and a bunch of other goodies.
If you look at your mount table (with the mount command, as
explained earlier), you will probably see that you have quite a few filesystems
mounted:
If you look more closely at that mount table, you'll see that only one of the
entries has an actual device (my root filesystem, on /dev/hda1).
The other three, one of which is /proc/, are actually virtual
filesystems. They are mounted like any other filesystem implementation, but
when the kernel asks them to do something, they don't use any hardware device to
supply the data, instead making it up themselves. This is why the "device
names" for these filesystems aren't proper paths. They're never touched. Once
again, it's all about layers of abstraction - nothing except the filesystem
driver itself actually cares that no hardware access is being made at all!
Why is this useful? Well, /proc/ is a fine example. When a
program (say, cat) wishes to open and read
/proc/cpuinfo, the filesystem driver for /proc/
answers the requests as if there were a file there, asks other parts of the
kernel how many CPUs it is running on, and of what type, and answers the
read() requests as if that were the contents of that file.
This mechanism allows files on the proc filesystem to be used
for all sorts of communication between the kernel and programs running on a
system. For example, you can tell the networking segment of the kernel not to
respond to ICMP echo ("ping") requests by writing the number "1" to the file
/proc/sys/net/ipv4/icmp_echo_ignore_all - I once used this
technique to help create a stealth machine to snoop on a network segment without
being visible. More mundanely, you can turn on IP forwarding (routing) by
writing "1" to the file /proc/sys/net/ipv4/ip_forward.
There are other virtual filesystems too - most filesystem implementations
marked as "nodev" in the list provided by
/proc/filesystems are virtual (either that, or networked
filesystems, which don't use any local device). For example,
devpts, which you'll also see in my mount table, is a virtual
filesystem which allows the creation of tty devices on the fly in the
/dev/pts/ directory where it is mounted. There's also
usbdevfs, which, when mounted, uses a set of files and directories
to represent the USB devices plugged into your computer (usually mounted under
/proc/bus/usb). Another virtual filesystem worth a mention, which
may be covered later, is devfs, which is an experimental virtual
filesystem. The idea is that it is mounted under /dev/, and
dynamically creates device files for the hardware plugged into the system (and,
quite usefully, nothing else). It's a good idea, and some distributions are
taking it up early, but I believe (although I get a funny feeling I'm going to
be corrected on this) that it won't be considered mature until the release of
the 2.6.x kernel series.
The above is by no means a complete list - virtual filesystems are, as I have mentioned, one of the primary mechanisms for communication between kernelspace (code and memory belonging to the kernel) and userspace (code and memory belonging to programs running on the system), and there are many, many examples, each for its own particular purpose.
Brief note and mini-exercise
There's one more thing I'd like to mention this lesson, and although it
doesn't really fit into the normal development, I think it's important enough
that I'll mention it anyway. When you mount a volume under a directory, any
existing contents of that directory are hidden until you unmount that volume.
Strange and heavily unpredictable things happen when a file in such a directory
is open, or a program's current working directory is somewhere in that
directory. Try it out - see what happens on your system. Send me (privately,
don't flood the list) a screenshot or copy-and-paste of you trying this one out,
and (optionally) suggest how you think the effects you observe might be caused.
I'll try my best to reply with the best I know about it.
Next Lesson
Lesson 5 will bring us more detail about the options that can be applied to mounted filesystems, and how to handle automatic mounting during boot-up. I'll try my best to reply with the best I know about it.