Is there a CPU/RAM overhead associated with using loop-mounted images versus using a physical partition under Linux?
4
-
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.– CeladaApr 23, 2016 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?– hayavukApr 23, 2016 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!– CeladaApr 23, 2016 at 22:51
-
1I 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.– hayavukApr 23, 2016 at 23:01
Add a comment
|
1 Answer
On Linux <4.4, 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, other alternatives would be to use a dedicated partition or a chroot so that data can be accessed directly.
Release notes for the first version with improved performance:
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 HaleOct 25, 2016 at 9:08