This is a LinuxChix course page. This and the other courses pages are yet to be ported to the new LinuxChix website. Please feel free to browse the course in the meantime.

We appreciate your patience.

The UNIX Filesystem: Lesson 4

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:

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/
OR

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.