An image file is a copy of the data on a block device, in the form of a file (on another filesystem). Image files can have any extension; .img is common.


A disk image, in computing, is a computer file containing the contents and structure of a disk volume or of an entire data storage device, such as a hard disk drive, tape drive, floppy disk, optical disc, or USB flash drive.

Are "disk image" in the second and "image file" in the first the same concept? Or is a "disk image" in the second is a special case of an "image file" in the first?

What does "a disk volume" mean in the second? Is it the same as either a logical volume in LVM, or a partition?

What can an image file be created to mirror:

  • a disk, DVD, CD
  • a logical volume (as in LVM)
  • a partition, or
  • a filesystem, (a file system is contained in a partition, but the partition can contain things outsie the filesystem)
  • ... ?

Is it correct that it is impossible to create an image file for a filesystem, but only possible to create an image file for a partition or a logical volume?

I also have a related question here: how genisoimage can create an image file for a directory? (given that a directory is not listed above).


  • 1
    Disk volume is used interchangeably with partitions, although I think it's a more prevalent term in Windows world, whereas there's clearer definition of a partition in Unix world Commented Feb 26, 2019 at 18:20
  • 1
    It is not impossible, but a very common operation. Commented Feb 26, 2019 at 22:09
  • @炸鱼薯条德里克 could you elaborate? Thanks
    – Tim
    Commented Feb 26, 2019 at 22:11
  • dd if=/dev/zero bs=1M count=100 >fs.img; lo=$(losetup --show --find fs.img); mkfs -t ext4 $lo; mkdir /mnt/lo; mount $lo /mnt/lo. I'm not sure how there's really any difference between "an image file for a filesystem" and "an image file for a partition or logical volume". It's an image file. Commented Mar 1, 2019 at 22:05

1 Answer 1


If data format X can be stored on a UNIX block device, then it can also be stored in a file. [But see nasty details below]. "Image file" is a short, generic name for this. I.e. it is a sequence of bytes that might be copied to or from a block device. If you want to, you can call it different things depending on what you use it for.

"Image file" might mean a disk image... or the image might technically be of a format used on a disc... there are more details about this case below. It might also be a format that can be used on a disk partition. It might also be a filesystem. Which we might call a "filesystem image".

An LVM Logical Volume is another type of block device.

I think the most significant distinction is whether it is a filesystem image or not. If it is a filesystem image, it is a single filesystem that you can mount with mount -oloop.

A complete "disk image" might not be a filesystem image - e.g. if it was a copy of an internal hard disk. But it might - e.g. if it was a copy of a floppy disk. But you might also be able to copy this filesystem image to a partition of an internal disk. Therefore I find "disk image" ambiguous, and not really more specific than "image file".

[Note] You do not mention "host-managed SMR" devices. These impose additional restrictions. Filesystems that were only designed for standard disks do not work within these restrictions. I will not mention them further.

[Nasty details] Ancient devices may also have provided a few numbers to specify the "geometry"; typically the size of a sector, a track, and a cylinder. These were used to optimize data layout on ancient slow disks.

So far, so good. And modern filesystem layouts may be optimized to align them with stripe size of a RAID device.

But a data format used on a disk could also assume that you already know what these numbers are... So if you only have an image of the disk, then you might have difficulties reading the data format. There can be problems with this for the MBR partition table format. There are some more horror stories in the obsolete Large Disk HOWTO.

Modern uses of MBR, and also GPT partition tables, do not use C/H/S geometry. However they still require that you know the sector size! Historically most disks have used 512 byte sectors. So most software will try this sector size when reading an image file. Then if the partitions were created for a disk which reports 4KB sectors, you will have a problem!

Perhaps surprisingly, this means that if USB sticks ever start reporting 4KB sector sizes, it will not be possible to use them for current Linux installer images!

(The legacy Apple format thoughtfully includes both the sector size and the number of sectors. As is mentioned in this story).

Filesystems tend not to have this problem. If you write a filesystem which uses 512 byte blocks to a device which uses 4KB sectors... The superblock will most likely store the block size used. However it is likely the filesystem code will refuse to work, if the block size is smaller than the device sector size.

Some software has attempted to guess the "geometry". For example older versions of fdisk, used to try to guess the C/H/S geometry from existing partitions.

CD-Rs and DVD-Rs use a different sector size: 2048 bytes.

  • It's about creating iso file, not burning a CD. Read again Commented Feb 26, 2019 at 22:27
  • @炸鱼薯条德里克 It is mentioned to avoid incorrect implications. The reason that an image file generated by genisoimage can be written to a CD-R is not that /dev/sr0 supports write(). (Linux can support write() on a block device representing some types of optical disc, but not when the disc is a CD-R).
    – sourcejedi
    Commented Feb 26, 2019 at 22:33
  • 1
    Thanks. Could you also consider to reply unix.stackexchange.com/questions/503211/…
    – Tim
    Commented Feb 27, 2019 at 1:17

Not the answer you're looking for? Browse other questions tagged .