How to Turn a File into a Virtual Block Device with Linux Loop Devices

Background

In Linux, a file can be treated as a block device using a loop device, allowing you to format, mount, and test file systems without a physical disk. This is useful for learning file‑system internals and observing how a file system interacts with block devices.

How to Use a Loop Device

There are two common ways to employ a loop device:

Mount the file directly with the -o loop option, which skips explicit loop device creation.

Create a loop device explicitly with losetup, then mount it; this method makes the underlying mechanism clearer.

Method 1: mount -o loop

Create a 1 GiB file, format it with the Minix file system, and mount it:

dd if=/dev/zero of=./minix_test.img bs=1M count=1024

mkfs.minix ./minix_test.img

mount -o loop ./minix_test.img /mnt/minix/

After mounting, any operation under /mnt/minix is reflected in minix_test.img. You can create a file inside the mount point and inspect the image with hexdump to see inode, data, and bitmap changes.

Method 2: Explicit Loop Device Creation

First create the same image file and format it, then associate it with a loop device using losetup:

dd if=/dev/zero of=./minix_test.img bs=1M count=1024

mkfs.minix ./minix_test.img

Associate the file with a specific loop device or let losetup pick a free one:

# Bind to a known free loop device
losetup /dev/loop5 ./minix_test.img
# Let losetup find a free device automatically
losetup --find --show ./minix_test.img

List current loop devices with losetup -a, then mount the device: mount /dev/loop5 /mnt/minix The resulting mount behaves identically to Method 1.

What Is a Loop Device?

A loop device is a special virtual block‑device driver in the Linux kernel (source: drivers/block/loop.c). It does not correspond to physical hardware; instead, it presents a regular file as a block device, enabling the file system layer to operate on it.

Loop Device Implementation Details

The driver follows the typical block‑device programming pattern:

Allocate and initialise a gendisk structure representing the device.

Initialise a request queue to handle I/O requests.

Provide a request‑handling function that processes queued operations.

Define a block_device_operations table with callbacks such as open, read, write, and ioctl.

How the Loop Device Binds to a Backend File

In user space, losetup or mount -o loop performs the following steps:

Open the backend file and obtain a file descriptor.

Open the loop device file (e.g., /dev/loop5) and obtain its descriptor.

Issue an ioctl call ( LOOP_CONFIGURE) to associate the two descriptors.

Inside the kernel, the lo_ioctl function handles the ioctl, allocating and initialising the loop device structures. The crucial assignment is lo->lo_backing_file = file;, which stores the pointer to the backend file.

Request Flow Through the Loop Device

When a file system issues I/O, it calls submit_bio, which eventually reaches the loop driver’s loop_queue_rq function. This function enqueues the request onto the device’s workqueue:

static const struct blk_mq_ops loop_mq_ops = {
    .queue_rq = loop_queue_rq,
    .complete = lo_complete_rq,
};

The work function loop_workfn processes the request, delegating reads to lo_read_simple and writes to lo_write_simple. The write path ultimately calls vfs_iter_write to write data into the backend file.

Typical Applications of Loop Devices

System simulation and testing – emulate storage configurations without real hardware.

File‑system development – mount and debug new file systems on a disposable image.

ISO image mounting – access ISO contents without burning media.

Encrypted containers – combine with dm‑crypt to create secure, file‑backed encrypted disks.

Summary

Loop devices let any regular file act as a block device, enabling disk‑like operations without physical media.

The kernel driver resides in drivers/block/loop.c and follows the standard block‑device model.

Requests flow from the file system through the block layer, into the loop driver, and finally to the backing file via VFS write/read helpers.

Common use cases include testing, file‑system development, ISO mounting, and encrypted disk images.