Ytdyklly

Having read both What is meant by mounting a device in Linux? and understanding "mount" as a concept in the OS, I have a problem where it is stated that

All accessible storage must have an associated location in this single directory tree. This is unlike Windows where (in the most common syntax for file paths) there is one directory tree per storage component (drive). Mounting is the act of associating a storage device to a particular location in the directory tree.

But there is already an accessible location for say a cdrom drive under /dev/cdrom which obviously comes in the directory hierarchy. So why the need for creating a separate "mount point" under /media/cdrom? Why accessing directly from /dev/cdrom is made impossible? I heard that that the device node files are just like ordinary files. And reading and writing to them is just like ordinary files. So does this mean that the filesystem in the cdrom is not available if we access it from /dev/cdrom. And the filesystem hierarchy(inside the cdrom) "comes alive" when we "mount" it?

You can read or write /dev/cdrom (eg, using dd or cat) but when you do that you are just reading or writing the raw bytes of the device. That can be useful in various circumstances (like cloning a partition), but generally we want to see the directories and files stored on the device.

When you mount a device you're basically telling the kernel to use a layer of software (the filesystem driver) to translate those raw bytes into an actual filesystem. Thus mounting a device associates the filesystem on that device to the directory hierarchy.

I think about this in the following manner: mount is a tool that tells the system to interpret the contents of some files as directory trees.

• The filesystem has directories and files, and each file is a label for some string of bytes.


• 
  /dev/cdrom is a file, it represents the string of bytes stored on the CD.


• You can read this very long string directly, but this is not very practical except for special purposes (e.g. creating a full disk image).


• This long string has additional internal structure: it contains a file system, which has information on what directories and files are stored and where in this very long string.


• By using mount -t iso9660 /dev/cdrom /media/cdrom, you tell the system: "take this very long string of bytes that you have in /dev/cdrom, interpret it as a directory tree in the iso9660 format, and allow me to access it under the location /media/cdrom".


• In fact, this works also for regular files. You can make a regular file that contains a disk image, and then use mount to access it. Try this:

dd if=/dev/zero of=fs-image bs=1M count=50

mke2fs fs-image

sudo mount fs-image /some/mount/point

(the first two commands are only required the first time, when preparing the image file.)

/dev/cdrom refers to a device file. This is not the contents of whatever disc you might wish to insert into your optical drive, but rather it is a reference to the bit of hardware (and probably software drivers) that you might call on to show that to you. When you mount /dev/cdrom to some path in your tree you attach its contents to your file system.

The thing is - I can't really think of another way to do it. Even in Windows - though it is not as apparent - there is still the filesystem abstraction for \?volumename. It took me a minute to remember what that looked like, and I found this googling it:

...the volume name is just a symbolic link which points back to a real volume device, usually in the form of DeviceHarddiskVolume23. There is another example of an MS-DOS device which is the drive letter. If your volume has the C: drive letter, you will then have a symbolic link called \?C: which points to a real volume in the DeviceHarddiskVolumeXX format.

And so maybe it is not all that different - though I would argue less complicated - it is just more obvious, I think. They're not one and the same system, but they're not fundamentally different, either.

Probably the most important distinction between /dev/device and /path/to/its/mount is that at the latter path a file-system - some bit of software intended to handle data in an organized way - is interpreting the contents of the former. You can't just read a disk - somebody's got to read it to you. The filesystem interprets the contents of the device.

In addition to the items mentioned above, a driver or other program can cache data from a device. On a read-write device, such as a hard disk or thumb drive, data written to the device may not have been written yet. Journaling file systems can also require flushing the journal before it doesn't see the device anymore. Then you've got filesystems that overlay other filesystems, such as cryptfs, which need to know when the underlying filesystem is no longer available.

Granted, for a read-only device this makes less sense, but it still applies.