47

I am trying to understand what the relationship a xxx.iso file has to the other aspects of a block device, e.g. partitions and a file system.

It's common for people to describe accessing or making a .iso usable as "mounting the ISO".

So to put the question another way: If I, or some piece of software, wanted to "mount" a xxx.iso file onto a USB device, is it necessary to have a pre-existing partition complete with filesystem (e.g. FATx or extX) or is the .iso file - once in the "mounted" state - a lower level construct that performs the same/similar role a file system (or even a partition) does?

3
  • 15
    Just a remark: The term "ISO file" in most cases means a file which contains a file system in the ISO 9660 standard for optical disc media. You can get an ISO file by copying a CD- or DVD-ROM using dd, for example.
    – Dubu
    Apr 25, 2016 at 8:52
  • 4
    Mount on a USB? You mean like make the ISO contents appear as part of the VFS tree under the mount point of the USB stick? You mean like mount /dev/my_usb_stick /media/usb_stick && mount -o loop,ro foo.iso /media/usb_stick/some_dir? (Linux's mount command supports the loop mount option to set up a loop block device, because wanting to mount FS images like a .iso is common.)
    – Peter Cordes
    Apr 25, 2016 at 13:22
  • You are using the file as a block device when you mount an ISO.
    – user146970
    Apr 26, 2016 at 17:48

3 Answers 3

Reset to default
64

An ISO file isn't a file system. It contains a file system. From a usage point of view, it functions the same way as a hard disk or USB device or DVD - you need to have a mount point, i.e. a place in your file system where you can mount it in order to get at the contents.

10
  • 1
    thanks, so then would the iso - once in a mounted state - be more analogous to a block device or a partiton in that case? - or is it not possible to draw a direct analogy as an iso is a totally different thing again?
    – the_velour_fog
    Apr 25, 2016 at 7:45
  • @the_velour_fog That's a very good analogy!
    – Jenny D
    Apr 25, 2016 at 7:48
  • 20
    The reason you cannot write to it is not because it is a mounted regular file instead of a device special file, but because the file system driver does not support it. If the image contained another filesystem like FAT32 or EXT2 instead of ISO9660, you would be able to read-write.
    – rexkogitans
    Apr 25, 2016 at 9:13
  • 4
    @rexkogitans: ... or UDF, aka ISO 13346. This is the file format used by rewritable CD-R's.
    – MSalters
    Apr 25, 2016 at 15:26
  • 1
    @hobbs: USB sticks, HDDs, etc. also don't need to have partitions. Partition-less block devices are sometimes called "SuperFloppy"s. There is no need to partition something when you only put one partition on it. It's just that some operating systems simply expect a partition table to be there, and don't recognize a filesystem directly on the block device. Embedded OSs in point&shoot digital cameras, for example, often refuse to mount SD cards in SuperFloppy format.
    – Jörg W Mittag
    Apr 26, 2016 at 0:54
45

There are three separate concepts here:

  • A block device, which is a physical or virtual device that represents a series of equal sized data blocks. HDDs are block devices. So are data CDs.
  • A filesystem, which defines a way of storing data in a block device that represents a series of files and directories and other filesystem information. ext3 is a file system, as is ISO9660.
  • 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 .iso file is usually an image file of a block device containing an ISO9660 filesystem. It contains an exact representation of the data stored on a CD. Analogously, you could have a .img file (call it .ext3 if you prefer) that is an image file of a block device containing an ext3 filesystem. This is a common way of distributing bootable USB or floppy images. The name is arbitrary, .iso is just what we call image files containing an ISO9660 filesystem (or, sometimes, a UDF filesystem, which is more modern).

You cannot directly mount image files, as they are not block devices, but merely a copy of the data in a block device. However, Linux and other OSes have a feature called loop devices which allows an image file to be accessed as a block device. To mount an ISO file, you first create a loop device that represents a virtual block device with the same contents as the ISO file. Then you can mount it just like you would a physical CD, or like you would a USB drive containing an ext3 filesystem, or anything else. The mount command may do this for you automatically, but under the hood they are separate steps.

Partitions are a way of breaking up a block device into multiple, smaller, logical block devices. Partitions are optional. A CD is analogous to an unpartitioned USB drive or a floppy disk in this respect, one where the filesystem is stored on the entire device with no partition table. ISO files therefore do not contain a partition table. Nothing stops you from, say, creating an ISO9660 filesystem on an HDD partition, though. When you do have partitions, an image file may be of a single partition or of the entire physical device including the partition table, but CDs aren't partitioned, so the distinction is irrelevant for ISO images.

You do not have to mount a device - or an image file - in order to access the files contained within. Some applications and libraries have the ability to access the data directly, without involving the operating system. They simply understand the filesystem directly, and have code that mimics what the OS does when it accesses files in a filesystem. This is why tools exist that can show you the contents of an ISO file, without actually mounting it via the OS. Mounting is an operating system concept, but it's not the only way of accessing data on a block device. Some people might consider the mere action of doing this "mounting" in a way.

What you mount a device (or an ISO file through a loopback device) onto is irrelevant. That's just where in the path hierarchy you ask the OS to show the contents of a device. On Linux, you usually would pick a directory on some already mounted file system. But nothing stops you from, say, booting from a CD and asking the kernel to mount it as the root filesystem. Of course, since an ISO file is, well, a file, it probably exists on some file system to begin with, which you need to have mounted somewhere in order to access the ISO at all.

11

No, the ISO image file is not a file system in its own right. Just like a partition can contain a file system, but isn't a file system, does an ISO image file contain a file system, but it isn't a file system.

But you need a file system for two things:

  • a place to store the .iso file (assuming if it doesn't come as a shiny silver disc)
  • a directory where to mount e.g. /mnt/isotmp

After that, if a path resolves to something under /mnt/isotmp, the code for the ISO image filesystem will do the resolving, opening, etc.

4
  • nice, the arrangement you've describes is similar to how a hard disk gets mounted, i.e. having a block device/partition/filesystem/ mounted at /some/directory. so am I right then to assume the iso basically does perform the function of a filesystem?
    – the_velour_fog
    Apr 25, 2016 at 7:42
  • I would not put it such. The ISO file contains a filesystem. Just like a partition contains a filesystem. You wouldn't say that a partition is a filesystem either (I hope)
    – Anthon
    Apr 25, 2016 at 8:02
  • How is this different from saying "a png file contains a picture, but isn't a picture", i.e. a silly and useless distinction?
    – Nick Matteo
    Apr 26, 2016 at 14:50
  • @the_velour_fog: More accurate to say the iso basically performs the function of the block device.
    – TMN
    Apr 26, 2016 at 16:14

You must log in to answer this question.

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