I previously used to create image files using dd, set up a filesystem on them using mkfsand mount them to access them as mounted partitions. Later on, I have seen on the internet that many examples use losetup beforehand to make a loop device entry under /dev, and then mount it. I could not tell why one would practically need an image file to behave as a loop device and have its own /dev entry while the same behaviour can be obtained without all the hassle.

Summary: In a real-life scenario, why do we need a /dev/loopXentry to be present at all, when we can just mount the fs image without it? What's the use of a loop device?

  • 9
    "... while the same behaviour can be obtained without all the hassle." - You're wrong there ;) - on Linux, a file cannot be mounted without the "hassle" of a loop device. It's just that nowadays mount is clever enough to do the hassle for you. (as Stephen Harris shows in his answer) – marcelm Oct 17 at 20:14
  • 1
up vote 17 down vote accepted

Mounts, typically, must be done on block devices. The loop driver puts a block device front-end onto your data file.

If you do a loop mount without losetup then the OS does one in the background.

eg

$ dd if=/dev/zero of=/tmp/foo bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0798775 s, 1.3 GB/s
$ mke2fs /tmp/foo
mke2fs 1.42.9 (28-Dec-2013)
....


$ losetup    
$ mount -o loop /tmp/foo /mnt1    
$ losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         1  0 /tmp/foo
$ umount /mnt1
$ losetup
$ 

You may need to call losetup directly if your file image has embedded partitions in it.

eg if I have this image:

$ fdisk -l /tmp/foo2      

Disk /tmp/foo2: 104 MB, 104857600 bytes, 204800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x1f25ff39

     Device Boot      Start         End      Blocks   Id  System
/tmp/foo2p1            2048      204799      101376   83  Linux

I can't mount that directly

$ mount -o loop /tmp/foo2 /mnt1
mount: /dev/loop0 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

But if I use losetup and kpartx then I can access the partitions:

$ losetup -f /tmp/foo2
$ losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         0  0 /tmp/foo2
$ kpartx -a /dev/loop0
$ mount /dev/mapper/loop0p1 /mnt1
$
  • You don't need explicit losetup, just use mount -o loop,offset=$((512*2048)), where 512 is sector size, and 2048 is what fdisk gave as Start of the partition. – Ruslan Oct 18 at 10:48
  • Yes, this was just an example of usage. In this specific example it might be easier to do the offset calculation but there may be use cases (eg multiple partitions you want to mount at the same time) where it can be easier to just losetup and kpartx. Let the tools do the hard work :-) – Stephen Harris Oct 18 at 18:26

File systems expect to read from and write to block devices, but image files aren’t block devices. Loop devices provide a block device on top of a file (or another block device, optionally with remapping).

There’s no need to consider loop devices when mounting images in many cases because mount takes care of everything for you; but loop devices are still involved. losetup -l -a will show them.

See also What is the difference between mount and mount -o loop.

  • So the block device-ization is implicitly handled by mount? – corsel Oct 17 at 15:33
  • 2
    Yes, mount takes care of losetup, adding -o loop etc. – Stephen Kitt Oct 17 at 15:34
  • @corsel, In most cases having mount call losetup for you works fine, but there are exceptions such as mounting multiple partitions from a disk image. – hildred Oct 18 at 11:48

You seem to be on Linux and Linux uses a wrong name for that feature.

I invented that feature in 1988 on SunOS-4.0 and I call that feature fbk - File emulates BlocK device.

The background is that the device driver emulates a block device on top of a plain file. You need this as a filesystem cannot use a plain file as a background storage for a filesystem. It rather needs a block device and this is what fbk emulates.

Since a while some people made the program mount a bit more clever and there are mount implementations that automatically create a fbk instance for a file in case that the mount program detects that the argument that is expected to be a block device appears to be a plan file instead.

  • 3
    Very impressive CV you got on your profile. Respect... – corsel Oct 17 at 16:50
  • 9
    Your post comes off as somewhat elitest. You may have written the first implementation, but Linux uses a different implementation, so its not using the 'wrong' name, just a different one from what you chose for your implementation. – Austin Hemmelgarn Oct 17 at 17:33
  • 2
    I never said they used the right name, I just said that claiming it was wrong makes you sound like an opinionated elitist. – Austin Hemmelgarn Oct 17 at 19:05
  • 7
    The 'loop' name is short for "loopback"' and refers to the way that operations on the block device are "looped back" to the VFS. Solaris 8 introduced a lofi ("loopback file") device that worked similarly; BSD introduced them under the name vnd ("vnode disk") so the concept has had a lot of different names over the years. – caf Oct 17 at 23:51
  • 1
    The two hardest problems in CS: cache coherence, identifier naming, and off-by-one errors. – Jens Oct 18 at 9:51

Even if it was not needed in the background for mounting filesystems from files, you would still need it for any setup using a driver or program that absolutely expects a block device. Think nbd (network block device) servers, compound block device drivers like mdraid, lvm etc....

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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