Basically you are using loopback to make a file appear to be a block device. Block devices transfer in “block size” chunks. A real disk is 512 bytes or multiples of 512 bytes, e.g., 4096 is common in some SSDs, but most old style hard drives stick to 512 bytes. There might be some improved efficiency in using a larger block size if on average your file sizes are larger, but for all cases you can’t go wrong with 512 bytes (consider that if the underlying disk holding the loopback file has a 512 byte block size, then that is read in 512 byte chunks, and thus there is never improvement on larger block sizes for a loopback file on that hard drive…the eMMC is 512 bytes…see “sudo gdisk -l /dev/mmcblk0”).
“dd” is creating a blank file of a specified size. There are many ways of doing this, e.g., the “truncate” command can reduce or enlarge files, while dd only creates from scratch or overwrites an existing content. However, dd might be more efficient for some uses due to working at a lower level than does truncate. Let’s say you want 4GB. Call it “410241024*1024 == 4294967296”. In 512 byte blocks this is “4294967296/512 == 8388608”. So this would create an empty file capable of holding a 4GB file system (raw bytes) using 512 byte blocks:
dd if=/dev/zero of=/some/where/empty.dat bs=512 count=8388608
Once this is covered by loopback it can be treated as if it were a hard disk partition by addressing the loopback device.
FYI, you need to be root (use sudo) for much of the losetup command. A non-root user can query what the first unused loopback device is via:
losetup --find
If the result is “/dev/loop0”, then you can check existence:
ls /dev/loop0
Here is the subtle tip: Running “losetup --find” as non-root will report the first unused loop device. This device might not exist, and if not, it won’t be created. On the other hand, if you use “sudo”, then a simple query of “sudo losetup --find” will also create the device reported as first unused device. You have a limited number of loopback devices available, and it is a leak if you create too many and never release.
So to “cover” a file with loopback, in its simplest form form where the device name is created if needed and also reported as to which device:
sudo losetup --find --show /some/where/empty.dat
If it turns out it was “/dev/loop0” reported, then you could detach loopback in a number of ways, but this is for the specific device:
sudo losetup -d /dev/loop0
To detach all loopback devices which are not bound to some process:
sudo losetup -D
Don’t for get to detach after you are done.
To format this as ext4:
sudo mkfs.ext4 /dev/loop0
To mount this and use it as if it were a partition:
sudo mount /dev/loop0 /some/where/else/
To umount you can do either of these:
sudo umount /dev/loop0
sudo umount /some/where/else
Something you can do is examine:
sudo gdisk -l /dev/loop0
You cannot modify a mounted partition, but if the file is covered by loopback and not mounted, then you can dynamically resize it via:
sudo gparted /dev/loop0
Now if you needed a larger partition, you could change partition size (I won’t guarantee data isn’t lost, but most of the time this is ok). Assuming the file is not covered by loopback and not mounted, and that we are going from 4GiB to 8GiB (originally “bs=512 count=8388608”, so we double count and get "512*83886082 == 8589934592"…this is bytes not count…it is “dd” which uses countbs):
truncate /some/where/empty.dat --size=8589934592
sudo losetup --find --show /some/where/empty.dat
sudo gpart /dev/loop0
# ...now just do as normal with gparted telling it to extend the file system...
# ...then use the file for loopback mount as you would normally...
Experiment with it on a test file before doing this on something you value.
NOTE: I know nothing about the virtual machine, but this file would have to be accessible by any VM as a regular file, and the VM kernel would have to support loopback. The loop device is what the VM works with, but the loop device can’t cover a file it can’t see. A Jetson does not normally run a VM, so I guess you are doing something custom.