I understand what mounting is in Linux, and I understand device files. However I do not understand WHY we need to mount.
For example, as explained in the accepted answer of this question, using this command:
mount /dev/cdrom /media/cdrom
we are mounting the CDROM device to /media/cdrom and eventually are able to access the files of CDROM with the following command
ls /media/cdrom
which will list the content of the CDROM.
Why not skip mounting altogether, and do the following?
ls /dev/cdrom
And have the content of the CDROM Listed. I expect one of the answers to be: “This is how Linux is designed“. But if so, then why was it designed that way? Why not access the /dev/cdrom directory directly? What’s the real purpose of mounting?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
One reason is that block level access is a bit lower level than ls would be able to work with. /dev/cdrom, or dev/sda1 may be your CD ROM drive and partition 1 of your hard drive, respectively, but they aren’t implementing ISO 9660 / ext4 – they’re just RAW pointers to those devices known as Device Files.
One of the things mount determines is HOW to use that raw access – what file system logic / driver / kernel modules are going to manage the reads/writes, or translate ls /mnt/cdrom into which blocks need to be read, and how to interpret the content of those blocks into things like file.txt.
Other times, this low level access can be good enough; I’ve just read from and written to serial ports, usb devices, tty terminals, and other relatively simple devices. I would never try to manually read/write from /dev/sda1 to, say, edit a text file, because I’d basically have to reimplement ext4 logic, which may include, among other things: look up the file inodes, find the storage blocks, read the full block, make my change(s), write the full blocks, then update the inode (perhaps), or instead write this all to the journal – much too difficult.
One way to see this for yourself is just to try it:
[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="691b06061d29281b0a012139">[email protected]</a> dev]# cd /dev/sda1 bash: cd: /dev/sda1: Not a directory
/dev is a directory, and you can cd and ls all you like. /dev/sda1 is not a directory; it’s a special type of file that is what the kernel offers up as a ‘handle’ to that device.
See the wikipedia entry on Device Files for a more in depth treatment.
Method 2
Basically, and to put it easily, the operating system needs to know how to access the files on that device.
mount is not only “giving you access to the files”, it’s telling the OS the filesystem the drive has, if it’s read only or read/write access, etc.
/dev/cdrom is a low-level device, the operating system functions wouldn’t know how to access them… imagine you put a weirdly formatted cdrom in it (even an audio cd), how would ls tell which files (if any) are there on the cd-rom without “mounting” it first?
Note that this happens automatically in many OSes (even Linux on some distributions and graphic interfaces), but that doesn’t mean other OSes are not “mounting” the drives.
Method 3
I’d call it historical reasons. Not that the other answers are wrong, but there’s a bit more to the story.
Compare Windows: Windows started as a single-computer, single-user OS. That single computer probably had one floppy drive and one hard drive, no network connection, no USB, no nothing. (Windows 3.11 had native networking capabilities; Windows 3.1 didn’t.)
The kind of setting Windows was born into was so simple that there was no need to be fancy: Just mount everything (all two devices) automatically every time, there aren’t (weren’t) many things that could go wrong.
In contrast, Unix was made to run on server networks with multiple users from the very start.
One of the Unix design decisions was that the file system should appear as a single uniform entity to the end users, no matter how many computers the physical disks were spread over, no matter what kind of disk, and no matter which of dozens of computer the user would access it from. The logical path to the user’s files would stay the same, even if the physical location of those files had changed overnight, e.g. due to server maintenance.
They were abstracting the logical file system, paths to files, from the physical devices that stored those files. Say server A is normally hosting /home, but server A needs maintenance: Just unmount server A and mount backup server B on /home instead, and noone apart from the administrators would even notice.
(Unlike the Windows convention of giving different names to different physical devices – C:, D:, etc. – which works against the transparency that Unix was striving for.)
In that kind of setting, you can’t just mount everything in sight willy-nilly,
In a large network, individual disks and computers are out of commission constantly. Administrators need the ability to say what is mounted where and when, e.g. to do a controlled shutdown of one computer while another computer transparently takes over hosting the same files.
So that’s why from a historical perspective: Windows and Unix came from different backgrounds. You could call it a cultural difference, if you like:
- Unix was born in an environment where the administrator needed to control mounting; of the dozens of storage devices on the network the admin must decide what is mounted where and when.
- Windows was born in a setting where there was no administrator and only two storage devices, and the user would probably know whether their file was on the floppy or the hard drive.
- (Linux was born as a single-computer OS, of course, but it was also explicitly designed from the start to mimic Unix as closely as possible on a home computer.)
More recently, the OSes have been moving closer to each other:
- Linux has added more single-computer, single-user stuff (like automounting); as it became frequently used in single-computer settings.
- Windows has added more security, networking, support for multiple users etc.; as networking became more ubiquitous and Microsoft started making an OS for servers as well.
But it’s still easy to tell that the two are the result of different traditions.
Method 4
For consistency
Imagine you have some partitions on the first hard drive in your system. For example, /dev/sda2. You later decide that the drive isn’t large enough so you purchase a second one and add it to the system. All of a sudden, that becomes /dev/sda and your current drive becomes /dev/sdb. Your partition is now /dev/sdb2.
Using your proposed system, you’d have to change all scripts, applications, settings, etc. that access the data on your old partition to reflect this change in names.
However, mounting allows you to still use the same mount point for this renamed drive. You’d have to edit /etc/fstab to tell your system that (for example) /media/backup is now /dev/sdb2 instead, but that is only one edit.
Note that modern day systems are even easier. Instead of referencing the device as /dev/sda2 or /dev/sdb2, they have UUIDS, which look similar to c5845b43-fe98-499a-bf31-4eccae14261b or can be given friendlier labels such as backup which can be used to reference the device when mounting. This way, the device name doesn’t change when adding a new device which makes administration even simpler:
# mount LABEL="backup" /media/backup
For Safety
By requiring a device to be mounted, the administrator can control access to the device. The device can be removed when unmounted, but not when in use (unless you want to suffer data loss). If you are (were) a Windows user, remember the little green icon in the notification area that tells you it’s safe to remove a USB stick? That is Windows mounting and unmounting the stick for you. So the principle isn’t just a Unix/Linux one.
Method 5
There are several advantages to the current arrangement. They can be grouped into advantages of block special files and advantages of mountpoints.
Special files are files that represent devices. One of the Ideas that unix was built on is everything is a file. This makes many things simple, for example user interaction is just file reads and writes on a tty device, which is a character special file. likewise checking for bad blocks, partitioning or formatting a disk is just file operations. It does not mater if the disk is mfm, ide, scsi, fiberchanel, or something else it is just a file.
But on the other hand you may not want to deal with the whole disk or partition just the files, and in many cases more files than will fit on a disk. So we have mountpoints. A mountpoint allows you to put a whole disk (or partition) on a directory. Back in my Slackware days when a good sized hard disk was a couple hundred MB, It was common to use the CD as /usr and the hard disk for /, /usr/local, and swap. Or you could put / on one drive and /home on another.
Now I noticed that you mentioned mounting your CD on /media/cdrom, which is handy for computers with only one cdrom drive, but what if you have more than one? where should you mount the second? or the third? or the fifteenth? you could certainly use /media/cdrom2, etc. Or you could mount it on /src/samba/resources/windows-install, or /var/www, or wherever it made sense to do so.
Method 6
The question title asks: Why do we need to mount on Linux?
One way to interpret this question: Why do we need to issue explicit mount commands to make file systems available on Linux?
The answer: we don’t.
You don’t need to mount file systems explicitly, you can arrange for it to be done automatically, and Linux distributions already do this for most devices, just like Windows and Macs do.
So that probably isn’t what you meant to ask.
A second interpretation: Why do we sometimes need to issue explicit mount commands to make file systems available on Linux? Why not make the operating system always do it for us, and hide it from the user?
This is the question I am reading in the question text, when you ask:
Why not skip mounting altogether, and do the following
ls /dev/cdrom
and have the content of the CD-ROM listed?
Presumably, you mean: why not just have that command do what
ls /media/cdrom
does now?
Well, in that case, /dev/cdrom would be a directory tree, not a device file. So your real question seems to be: why have a device file in the first place?
I’d like to add an answer to the ones already given.
Why do users get to see device files?
Whenever you use a CD-ROM, or any other device that stores files, a piece of software is used that interprets whatever is on your CD-ROM as a directory tree of files. It is invoked whenever you use ls or any other kind of command or application that accesses the files on your CD-ROM. That software is the file system driver for the particular file system used to write the files to your CD-ROM. Whenever you list, read or write files on a file system, it’s the job of that software to make sure that the corresponding low-level read and write operations are performed on the device in question. Whenever you mount a file system, you’re telling the system which file system driver to use for the device. Whether you do this explicitly with a mount command, or leave it to the OS to be done automatically, it will need to be done, and of course the file system driver software will need to be there in the first place.
How does a file system driver do its job? The answer: it does it by reading from and writing to the device file. Why? The answer, as you stated already: Unix was designed this way. In Unix, device files are the common low-level abstraction for devices. The really device-specific software (the device driver) for a particular device is supposed to implement opening, closing, reading and writing on the device as operations on the device file. That way, higher-level software (such as a file system driver) doesn’t need to know as much about the internal workings of individual devices. The low-level device drivers and the file system drivers can be written separately, by different people, as long as they agree on a common way to interface with each other, and that is what the device files are for.
So file system drivers need the device files.
But why do we, ordinary users, get to see the device files? The answer is that Unix was designed to be used by operating system programmers. It was designed to allow its users to write device drivers and file system drivers. That is in fact how they get written.
The same is true for Linux: you can write your own file system driver (or device driver), install it, and then use it. It makes Linux (or any other variant of Unix) easily extensible (and it is in fact the reason Linux was started): when some new piece of hardware comes on the market, or a new, smarter way to implement a file system is designed, someone can write the code to support it, make it work, and contribute it to Linux.
Device files make this easier.
Method 7
Many database engines can work directly with raw disks or partitions. For example, MySQL:
http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html
This avoids the overhead of going through filesystem drivers, when all the DB engine really needs is one huge file that fills the disk.
Method 8
Because /dev/cdrom is a device, whereas /media/cdrom is a filesystem. You need to mount the former on the latter in order to access the files on the CD-ROM.
Your operating system is already automatically mounting the root and user filesystems from your physical hard disk device, when you boot your computer. This is just adding more filesystems to use.
All operating systems do this — however, some (such as Windows, when it mounts a CD-ROM on to D:) do it transparently. Linux leaves it to you so that you have greater control over the process.
Method 9
It does so because there is, with many media for desktop and laptop UIs, ambiguity about what to do when the media is inserted, because user intuition is that inserting the disk in the physical box with which the user interacts is not different to, say, inserting it into a device next to the computer that has a network connection.
Thus in the fundamental sense, the UI for media needs to treat the two kinds of potential mount events similarly, and there is no good way for computers to handle network mounts in as intuitive manner as one can for network mounts with other UIs to computers, such as smartphones, tablets and wearable computers, that lack the possibility of inserting physical media in the devices. (Note how horrible the iPhone interface is for switching SIM cards, the one kind of physical media iOS devices have inserted into them.
Note also that other popular approaches to UIs for this type of physical box (for example, Windows 98, Windows 8, Mac OS X v10.2 (Jaguar), and Mac OS X v10.9 (Mavericks)) run into the same issues, and use additional GUI dialogs to sort out the potential confusion (for example, Windows 8 is typically configured to prompt for each new CD inserted whether it should be mounted as a filesystem, a music media, or if appropriate, a collection of MP4 videos). There is no reason why any of these user dialogs cannot be used with Linux or other UNIXes.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0