We can usually see mounting a file system to a mountpoint, like:

/usr/bin/truncate -s 128M /tmp/foo
chmod 0700 /tmp/foo
mke2fs -t ext4 -m 1 -F /tmp/foo
mount -t ext4 -o loop /tmp/foo /mnt

I wonder what's the benefit of mounting a file system in the same file system? /tmp/foo and /mnt are in the same file system.

  • This command works for you? Would you give the (respective line of the) output of cat /proc/mounts afterwards? – Hauke Laging Mar 3 '14 at 2:55
  • Do you mean bind instead of loop? – michas Mar 3 '14 at 7:08
  • I have RE-EDITED – user2886717 Mar 3 '14 at 8:00

The command you posted doesn't make much sense, since you typically don't use a loop device to mount physical devices, it's often used for mount ISO files.

At any rate one advantage to mounting 1 file system within another is the ability to blend a system's directory structure form a variety of sources.

For example, say you had a NAS (Network Attached Storage) that provided each user's home directory (/home/<username>). This entire directory structure could be automounted into the existing directory structures of each of your systems, giving the appearance of being part of the local filesystem, all the while it's actually located on some distant remote server's disks.

This is one of the tenets that makes Unix extremely powerful in layering resources such as storage. The analogy to this in the Windows world would be mapping drive letters from UNC paths, which though is somewhat equivalent, is no where near as flexible or as powerful.

Mounting resources like this in Unix is tolerant to being relocated, can be load balanced, along with a whole host of other advantages.


Once upon a time, when disks were much smaller, and when a typical UNIX system had multiple users using the time-sharing system at the same time, it made a lot of sense to have spread files across hard disks and/or partitions:

  • A fairly small root partition
  • /usr would typically be a larger hard disk which was mounted at system init time after the root file system was mounted
  • Before UNIX had quotas, it made sense to put /home in its own file system so users filling up the /home directory do not hoze the system (UNIX also protects against this by having a certain percentage of hard disk space only writable by root)
  • For similar reasons, /tmp should be in its own file system. These days, /tmp is often times a ram file system, which is erased every time the system reboots.

There is a fundamental difference here. The "foo" is a file in the original sense, but it can act as a filesystem image (that is, equivalent to an entire hard drive, not just a file). Your "foo" can contain an entire directory tree. This is used in numerous cases:

  • iso images (you may remember cds), instead of having a real CD drive, you just download an image and loop-mount it, the system won't know the difference.
  • boot images: you may have a file on some server that is actually a disk image from which you boot all computers on the same LAN. Like a school, office or a cluster. You may even have an image in ram, making your system lightning fast (trivial on modern 8-16G machines).
  • backup images: put your hard drive in a single file on a bigger hard drive. If you need backups, loop-mount it and you have the entire directory structure back.
  • virtual machines usually operate on disk images of some sort

A different concept is a "bind" mount, which remounts an existing directory somewhere else. Very useful for remapping your structure. For instance, you have a script that does something with /datadrive/user/foo, but you changed your directories and mountpoints and now this is on /mnt/data/foo. No problem, just bind-mount the second to the first. Hard links may work, but only within the same filesystem (and are more dangerous and permanent). You can also "override" the directory structure like this. For instance, you could just mount another /usr over the current one and use different installed programs. The options are endless.


Commands like you mention are used to set up a disk image to be used e.g. by qemu or bochs to run a guest operating system. I've done this to run very old versions of 386bsd or Linux for demostration purposes. Or you could manipulate the image on (fast) disk to later write it to (slow) USB storage.

If you want to experiment with potentially dangerous operations on some device, an option is to copy contents to a disk file, and fool around with the copy.

For computer forensic analysis, it is crucial that the original data isn't touched. Copy the contents of the device to a file, via loopback you can then analyze to your heart's content.

You can create an ISO image on disk and ship that one around, without the need to burn it.

Creating a filesystem on a file allows you to break it, and test recovery tools on it.

As you can see, there are many potential uses for this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.