Loop mounting files vs mounting directories

Question

I was reading Trouble with understanding the concept of mounting and came across this explanation:

By using mount -t iso9660 /dev/cdrom /media/cdrom, you tell the system: "take this very long string of bytes that you have in /dev/cdrom, interpret it as a directory tree in the iso9660 format, and allow me to access it under the location /media/cdrom"

and other answers along this line. This makes sense and from this logic, I understood that mounting essentially couples a filesystem to a device which interprets the contents of the device in a way that the kernel can fit it into the existing filesystem hierarchy.

If this is indeed the case, why is a loop mount needed?

Since a mount -o loop is technically identical to the operation mount is meant to do: read a file and interpret its content in the context of a filesystem, why can we not generalize the mount operation without creating a special device?

Edit: I understand that a loop device provides a block-device API to a file. My question is, however, more general. How is reading from a regular file (iso or similar disk image formats) different from reading from a special file, if they contain the same data?

My mental model of how mount works is this: given an arbitrary set of bytes exposed by a /dev/device file which are consequently interpreted by a filesystem driver (ext4, for example), the mount command associates it with the root hierarchy so that it appears transparent to the end user.

However, this arbitrary set of bytes can occur anywhere. If interpreted by a filesystem driver they should be recognized as a valid filesystem. What constrains a filesystem driver to read only from a special file and not a regular file?

Solution

Block devices are not normal files, they allow programs like mount to perform special functions on them that are required for it to correctly work.

A loop device is a translation device, it translates block file calls into normal filesystem calls to a specific file. You can use losetup to create fully fledged loopback devices backed by a file (will appear as /dev/loopX and then treat them as normal block devices or pass -o loop to mount to tell it to create the block device transparently. You can also use losetup to inspect loopback devices and what they are backed by.

Note that with modern mount it will attempt to detect a normal file and automatically create the loopback device for you. So you do not need to pass it the loop option.

Also, technically a bind mount is where you remount a directory to a new location (so it is mounted twice). This can be done with the --bind flag to mount. I get your meaning, but it can get confusing as the term bind has a specific meaning in terms of mounting.

Edit: You mental model is effectively correct, but you can think of loop devices as an abstraction layer, it allows mount to talk to any file as though it was a block device, without having to understand the differences between reading/writing to a filesystem or to a raw block device - the kernel handles all of that. All mount needs to know is how to ask the kernel to set up the loop device, then treat is as a block device; this keeps the low level code simpler and allows anything that can talk to a block device talk to a file instead without being modified.

Comments

[Ipor Sircer]

In /dev every device is a raw unfragmented file. On filesystem every file is fragmented, so the loop module create a virtual unfragmented device from in /dev.

[Stephen Kitt]

@IporSircer that doesn't make much sense to me, loop has nothing to do with fragmentation...

[Shrikant Giridhar]

Thanks. I've replaced 'binds' with 'couples' in my question to avoid confusion with bind mounts.