Local file system mounting Mounting remote file systems

3 min

Local file system mounting

Before an OS can allow a user to access a particular file system, it will need to do certain things. The metadata that describes the partition must be read, some part of the free space mechanism must be read into RAM perhaps some blocks preallocated, the directory that represents the root of the directory tree must be read in, and so on. This process is called mounting. When the OS is installed there will be some partitions that it is told to access, and normally those partitions will be mounted whenever the OS is booted. Local file system mounting These partitions are normally the ones that are on local hard drives. There are differences between OSs, however, with respect to removable media, OSs treat them in one of three ways: implicit mount when the media is inserted in the drive, implicit mount when the media is first accessed, or explicit mount command must be given.

UNIX and most of its variants have traditionally used the last mechanism. Until the user gives a specific mount command the removable medium cannot be accessed. Since floppy disks formatted for MS-DOS were so pervasive, this actually had a good side effect since it allowed the user to specify which file system format a floppy disk contained: UNIX, MS-DOS, or Mac. Later versions of Linux and UNIX have begun experimenting with implicit mounting when the media is inserted.

The term used for this is automounting. MS-DOS and the Windows products have always used implicit mounting when an attempt is first made to access the media. Historically the Mac OS automatically mounted a removable media whenever it was inserted into the drive. Since Mac OS X is based on UNIX, it now mounts as UNIX does.

Mounting remote file systems

A similar process must also take place when an OS is requested to provide access to a file system on a remote computer, but the details are vastly different. The remote file system might be an entire file system that is made available to users, but more likely it is some portion of a file system rather than the whole thing. A large difficulty that must be overcome is that the platform that the remote file system is running on may be entirely different from the local file system. Local file system mounting Data representation may be different, file naming conventions may be different, directory structures may be different, and so forth. In order to overcome these differences, we have to have well-established rules about how the information is to be presented and the protocols to be used for exchanging the information. In most cases, the rules and protocols are de facto rules that are established by one platform vendor to allow their systems to interoperate.

Other vendors will create packages to access these systems from other platforms. Sometimes these rules become open standards, as with network file system ( NFS; see Section 13.4.2), and sometimes they are reverse engineered by other vendors. Whatever the case, the remote system will do the accessing of the directories but the information must be mapped into the context of the client OS. Local file system mounting For example, if the client is a Windows system, then the metaphor of the remote file system is that of a “drive letter.” Initially, these letters were used in DOS to indicate real drives on a system.

Remote file systems use the same convention, assigning any drive letter that is not used for a local resource. In contrast, UNIX sees all file systems as a tree structure, including pseudo-directories like proc and dev. So mapping a remote file system in UNIX-like systems simply involves adding (or replacing) a directory node in the file system tree structure with a node that identifies itself as pointing to a remote resource.


As in many other instances, an OS will present to the API abstraction of a file. The program should not be aware of what the file system is like. There are likely to be performance differences if the wrong file system is used for an application, but the coding of the application should not be affected. That is really a system engineering issue. If the application is designed for accessing a file randomly and the file system supports random access, then the application should be unaware of any other differences.

In most systems, it will be necessary for the OS to support several different file systems. If for no other reason, it is necessary because different file systems are best suited for different media. For CD, there is normally only ISO-9660 to consider, although a few very early CDs were created in proprietary formats. For floppy disks, it is almost a given that the OS will need to be able to read and write FAT12 floppy formatted disks derived from MS-DOS. But Mac and UNIX formats are widely used as well. Even with hard drives, it will sometimes be desirable to support a format other than the native format of the OS.

Also Read:-

Like it? Share with your friends!


Your email address will not be published. Required fields are marked *

error: Content is protected !!