5

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?

Community
  • 1
Shrikant Giridhar
  • 1,287
  • 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. – Ipor Sircer Sep 13 '16 at 07:50
  • @IporSircer that doesn't make much sense to me, loop has nothing to do with fragmentation... – Stephen Kitt Sep 13 '16 at 08:05

2 Answers2

3

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.

Michael Daffin
  • 3,948
0

Vaguely described, a loop mount redirects the mount as a "loop device".

A "loop device" is effectively representative of a physical partition (which typically represents sequential device blocks) but must be interpreted through the filesystem on which the image resides in a potentially fragmented state.

Unlike a physical partition, the underlying filesystem must be consulted for each block read. It's less efficient, though more convenient, and allows for nested filesystems of varying filesystem types.

A mount -o loop is not technically identical to a mount operation any more than using swapon for a swap file is identical to using swapon for a swap partition.

On an actual partition, reads and writes are restricted to physical partition/cylinder boundaries. Fragmentation is obfuscated by the partition's filesystem.

In a looped image, fragmentation is hidden behind an apparently sequential mount. The underlying filesystem handles file fragmentation and presents a sequential "partition".

This becomes more apparent in the case of encrypted or compressed disk images like squashfs. In such cases, said image blocks are accessed via the underlying filesystem and then processed through the applicable compression (or encryption) API to present an apparently sequential set of device blocks.

In short, a "block device" is expected to be a sequential list of "device blocks". The special device created by a loop mount pretends that potentially non-sequential device blocks of varying sizes are sequential device blocks of a predetermined size.

codewithmichael
  • 446