General Mounting

Normal Stuff

Mounting a normal thing in the normal Linux way:

mount /dev/sdc2 /mnt/c/2

This mounts the device /dev/sdc2 to a mount point at /mnt/c/2.

Loopback

Here’s how to mount a CD image file so that you can poke around it:

mount -t iso9660 -o ro,loop /cds/distro.iso /mnt/cd

fstab

The /etc/fstab/ file is a list of known mount points that can be used by the mount command to do things with out providing more explicit details. If you have a mount for /dev/sdc to mount to /data if you have an fstab entry for it, you can just say:

mount /data

Mounting normal volumes

Sample /etc/fstab
# <fs>              <mountpoint>    <type>      <opts>   <dump/pass>
/dev/md1            /boot           ext2        noatime      1 2
/dev/md3            /               ext3        noatime      0 1
/dev/md4            /data           ext3        noatime      0 1

raven:/xeddrive     /ravendisk      nfs    rsize=8192,wsize=8192  0 0

Removable Media Devices

This is almost always handled by automount and magical stuff that mounts to /media/ on modern distros. However if you need them to be explicit, here’s how.

/dev/cdrom0     /mnt/cdrom      iso9660     noauto,ro    0 0
/dev/fd0        /mnt/floppy     auto        noauto       0 0

Swap

This is not technically a mount point per se, but it belongs in your fstab if you want the swap space activated automatically.

/dev/hda2       none            swap        sw           0 0

Virtual

There may be some weird entries already in your fstab. If so, leave them alone. The proc filesystem is usually a good idea to put in here if you’re building a Gentoo system, for example. But just keeping whatever fashionable weird entries that came with your distro’s fstabe is probably the best plan:

proc            /proc      proc        defaults    0 0
shm             /dev/shm   tmpfs       nodev,nosuid,noexec 0 0

Mounting RAM As A File System - tempfs

Here’s a good description of tempfs.

https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

This kind of thing is possible.

# mount tmpfs /dev/shm -t tmpfs -o size=32m

Mounting Partitions On A Whole Disk Image File

Imagine you did something like this.

dd if=/dev/sda of=/mnt/otherdisk/mywholedisk.img bs=512

Fun! That gets the MBR and the partition table and, well, everything. How do you pull that apart? One way which is described in this article is to mount with an offset. Like in the article this can sometimes not work. It can be helpful to pull out a particular partition from an entire disk image. First get the geometry details by running parted, changing units (u B) to "B", and printing (p) the partition information. You then need to divide the start and size (which are in bytes) by 512 to use for dd block counts.

time dd if=/mnt/sdb5/wholedisk.img of=/tmp/justtheboot.img bs=512 skip=2048 count=1024000
file /tmp/justtheboot.img  # Confirms it's a partition.
fsck.ext4 /tmp/justtheboot.img # Reset the journal if need be.
mount -t ext4 -o loop,ro /tmp/justtheboot.img /mnt/image

This is helpful to be able to do. It turns out that there is an even easier and better way. The kpartx utility is found on systemrescuecd and works great for exactly this job.

kpartx -av /archives/thewholedrive.img
ls /dev/mapper
fsck.ext4 -y /dev/mapper/loop2p5
mount -o ro /dev/mapper/loop2p5 /mnt/image
# Do what you need to do...
kpartx -dv /archives/thewholedrive.img

Note that I wasn’t sure that the last step actually worked (removed the mappings). But powering off will!

Auto Mount

The automount daemon is a kernel level function that allows the system to mount the needed volumes at the moment it is needed. This cuts down on a lot of open connection overhead for a busy file server.

Configuration

Automount is configured with a series of files that normally live in /etc/.

/etc/auto.master

This is the master map for the automounter. Here’s what a typical one contains.

/       /etc/auto.xed    --timeout 15
/misc   /etc/auto.misc   --timeout 15
/net    -hosts
+auto.master

The first field here is the directory that contains the mount point. So if you want to mount at /pro/ you’ll need an entry here for /.

Note
 Some reasonable seeming people believe that it’s probably better to not make / an automounted directory parent. The way to get the same effect is to create a link to the automounted path in the top directory. I’m not sure if I fully believe in this.

If you want to mount at /home/xed you’ll need an entry here for /home. If the directory /home/xed doesn’t exist or even if /home doesn’t exist, it will be created temporarily.

The second field is where to find instructions on what to do with requests to access this part of the file system.

/etc/auto.misc

Here’s what was in my auto.misc.

/etc/auto.misc
cd      -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom

From the example above, there’s a reference to /etc/auto.xed which is a custom mount mapping.

/etc/auto.xed
lab     -rw,soft,intr,rsize=8192,wsize=8192 fs.xed.ch:/files/lab
home     -rw,soft,intr,rsize=8192,wsize=8192 fs.xed.ch:/files/users

This means that when a user does something like ls /lab, the automount daemon will realize that it has instructions about certain points attached to /. It looks in /etc/auto.master by default and determines that since the desired directory does have a definition where / is defined in /etc/auto.xed, that it will use the lab line of that configuration and mount fs.xed.ch:/files/lab at /lab.

Once these files are configured, you need to start the automount daemon.

sudo /sbin/service autofs start

Or if it’s already running do either of these to get configuration file changes enacted:

sudo /sbin/service autofs restart
sudo /sbin/service autofs reload

A an interesting place to see what the kernel knows about automount mapping points is with:

cat /proc/mounts
Note
 This seems to not always be completely accurate. For me it showed some old mappings that I had gotten rid of. Don’t know how to clear this.

Union FS

This is a complex topic that I don’t have a complete notes for. Basically a union file system is able to take two volumes and mount them both as one. This sounds kind of neurotic, but there are good reasons for doing this.

Potential Use Cases

Media optimizing

First, let’s say that you have a lot of memory in a machine, you might want all disk transactions to attempt to be performed on a virtual disk but have the option of spilling over into slower media if the RAM gets full. This is also useful for certain devices like some netbooks with SSD drives that probably should not be used for transient file thrashing due to media write fatigue issues. A union fs can put a lot of that load on the memory.

Standardized images

You can also boot from a static image such as a CD ROM or a read only NFS root export. This is normally quite inflexible, but with a union file system, you can also mount some other kind of media that will be where all changes and modifications go. This allows, for example, many users to share a root image, but still be able to customize their own.

Implementations