Is there a CPU/RAM overhead associated with using loop-mounted images versus using a physical partition under Linux?

  • When you loop-mount, it is usually because the thing you are mounting is not already a block device. So it comes down to comparing mounting a physical partition and mounting... something else. So it completely depends what that other thing is. This is not a meaningful comparison. – Celada Apr 23 '16 at 21:43
  • Could we assume, for argument's sake, that we have a choice of using the image file as a storage device and creating a partition for it? – hayavuk Apr 23 '16 at 22:21
  • I don't follow. You are in possession of a filesystem image in a (regular) file? Then you basically don't have a choice but to use loopback. You say "creating a partition for it" by which I assume you mean "creating a block device for it", and that it exactly what a loopback device does for you! – Celada Apr 23 '16 at 22:51
  • 1
    I have a choice between creating a partition as an image file and then loop-mounting it, or creating a physical partition. They would both be used the same way. – hayavuk Apr 23 '16 at 23:01

Yes, unless you have a very recent kernel there is significant overhead when using loop devices on linux: data accessed through the loop device has to go through two filesystem layers, each doing its own caching so data ends up cached twice, wasting much memory (the infamous "double cache" issue)

Aside from casual use better alternatives would be to use a dedicated partition or a chroot so data can be accessed directly.

Or use latest kernel, the issue is fixed in linux 4.4 and newer:

Faster and leaner loop device with Direct I/O and Asynchronous I/O support

This release introduces support of Direct I/O and asynchronous I/O for the loop block device. There are several advantages to use direct I/O and AIO on read/write loop's backing file: double cache is avoided due to Direct I/O which reduces memory usage a lot; unlike user space direct I/O there isn't cost of pinning pages; avoids context switches in some cases because concurrent submissions can be avoided. See commits for benchmarks.

  • I found the quoted text here and the commit with the benchmarks, but I am having trouble reading them... it seems that IO is actually faster using loopback than using ext4? I'm guessing that using loopback for hibernate to swapfile with btrfs will make no noticable difference then. – Tom Hale Oct 25 '16 at 9:08

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.