CoSc-2042: Operating System

Chapter 5: File Systems

5.1 File Concept

Computers can store information on various storage media, such as magnetic disks, magnetic
tapes, and optical disks. The operating system abstracts from the physical properties of its
storage devices to define a logical storage unit, the file. Files are mapped by the operating
system onto physical devices. These storage devices are usually nonvolatile, so the contents
are persistent through power failures and system reboots.

5.1.1 File Attributes

A file is named, for the convenience of its human users, and is referred to by its name. A
name is usually a string of characters, such as example.c. Some systems differentiate between
uppercase and lowercase characters in names, whereas other systems do not. A file’s
attributes vary from one operating system to another but typically consist of these:
 Name: The symbolic file name is the only information kept in human readable form,
 Identifier: This unique tag, usually a number, identifies the file within the file
system; it is the non-human-readable name for the file.
 Type: This information is needed for systems that support different types of files.
 Location: This information is a pointer to a device and to the location of the file on
that device.
 Size: The current size of the file (in bytes, words, or blocks) and possibly the
maximum allowed size are included in this attribute.
 Protection: Access-control information determines who can do reading, writing,
executing, and so on.
 Time, date, and user identification: This information may be kept for creation, last
modification, and last use. These data can be useful for protection, security, and usage
monitoring.

The information about all files is kept in the directory structure, which also resides on
secondary storage. Typically, a directory entry consists of the file’s name and its unique
identifier.

5.1.2 File Operations

To define a file properly, we need to consider the operations that can be performed on files.
The operating system can provide system calls to create, write, read, reposition, delete, and
truncate files. Let’s examine what the operating system must do to perform each of these six
basic file operations. It should then be easy to see how other, similar operations, such as
renaming a file, can be implemented.
 Creating a file: Two steps are necessary to create a file. First, space in the file system
must be found for the file. Second, an entry for the new file must be made in the
directory.
 Writing a file: To write a file, we make a system call specifying both the name of the
file and the information to be written to the file.
 Reading a file: To read from a file, we use a system call that specifies the name of
the file and where (in memory) the next block of the file should be put.
 Repositioning within a file: The directory is searched for the appropriate entry, and
the current-file-position pointer is repositioned to a given value. Repositioning within
a file need not involve any actual I/O. This file operation is also known as a file seek.

By Dr. Manish Kumar Mishra Page 5- 1

CoSc-2042: Operating System

 Deleting a file: To delete a file, we search the directory for the named file. Having
found the associated directory entry, we release all file space, so that it can be reused
by other files, and erase the directory entry.
 Truncating a file: The user may want to erase the contents of a file but keep its
attributes. Rather than forcing the user to delete the file and then recreate it, this
function allows all attributes to remain unchanged-except for file length.

These six basic operations comprise the minimal set of required file operations. Other
common operations include appending new information to the end of an existing file and
renaming an existing file. These primitive operations can then be combined to perform other
file operations. For instance, we can create a copy of a file, or copy the file to another I/O
device, such as a printer or a display, by creating a new file and then reading from the old and
writing to the new. We also want to have operations that allow a user to get and set the
various attributes of a file.

Most of the file operations mentioned involve searching the directory for the entry associated
with the named file. To avoid this constant searching, many systems require that an open()
system call be made before a file is first used actively. The operating system keeps a small
table, called the open-file table, containing information about all open files. When a file
operation is requested, the file is specified via an index into this table, so no searching is
required. When the file is no longer being actively used, it is closed by the process, and the
operating system removes its entry from the open-file table, create and delete are system calls
that work with closed rather than open files.

The open() operation takes a file name and searches the directory, copying the directory entry
into the open-file table.

Several pieces of information are associated with an open file:

 File pointer: Records the current position in the file, for the next read or write access.
 File-open count: How many times has the current file been opened (simultaneously
by different processes) and not yet closed? When this counter reaches zero the file can
be removed from the table.
 Disk location of the file: Most file operations require the system to modify data
within the file. The information needed to locate the file on disk is kept in memory so
that the system does not have to read it from disk for each operation.
 Access rights: Each process opens a file in an access mode. This information is
stored on the per-process table so the operating system can allow or deny subsequent
I/O requests.

5.1.3 File Types

A common technique for implementing file types is to include the type as part of the file
name. The name is split into two parts-a name and an extension, usually separated by a period
character (Figure 5.1). In this way, the user and the operating system can tell from the name
alone what the type of a file is.

By Dr. Manish Kumar Mishra Page 5- 2

CoSc-2042: Operating System

Figure 5.1: Common file types.

5.2 Access Methods

Files store information. When it is used, this information must be accessed and read into
computer memory. The information in the file can be accessed in several ways.

5.2.1 Sequential Access

The simplest access method is sequential access. Information in the file is processed in order,
one record after the other. This mode of access is by far the most common; for example,
editors and compilers usually access files in this fashion.

Figure 5.2: Sequential-access file.

By Dr. Manish Kumar Mishra Page 5- 3

CoSc-2042: Operating System

A read operation reads the next portion of the file and automatically advances a file pointer,
which tracks the I/O location. The write operation appends to the end of the file and advances
to the end of the newly written material

5.2.2 Direct Access

Another method is direct access (or relative access). A file is made up of fixed length logical
records that allow programs to read and write records rapidly in no particular order. The
direct-access method is based on a disk model of a file, since disks allow random access to
any file block. For direct access, the file is viewed as a numbered sequence of blocks or
records. Thus, we may read block 14, then read block 53, and then write block 7. There are
no restrictions on the order of reading or writing for a direct-access file.

For the direct-access method, the file operations must be modified to include the block
number as a parameter. Thus, we have read n, where n is the block number, rather than read
next, and write n rather than write next.

Not all operating systems support both sequential and direct access for files. Some systems
allow only sequential file access; others allow only direct access.

5.3 Directory Structure

5.3.1 Storage Structure
A disk (or any storage device that is large enough) can be used in its entirety for a file system.
Sometimes, though, it is desirable to place multiple file systems on a disk or to use parts of a
disk for a file system and other parts for other things, such as swap space or unformatted
(raw) disk space. These parts are known variously as partitions, slices, or minidisks. A file
system can be created on each of these parts of the disk. Multiple physical disks can be
combined to form larger structures known as volumes, and file systems can be created on
these as well. Each volume can be thought of as a virtual disk. Each volume that contains a
file system must also contain information about the files in the system. This information is
kept in entries in a device directory or volume table of contents. The device directory (more
commonly known simply as a directory) records information-such as name, location, size,
and type-for all files on that volume. Figure 5.3 shows a typical file-system organization.

Figure 5.3: A typical file-system organization.

5.3.2 Directory Overview
When considering a particular directory structure, we need to keep in mind the operations
that are to be performed on a directory:

By Dr. Manish Kumar Mishra Page 5- 4

CoSc-2042: Operating System

 Search for a file: We need to be able to search a directory structure to find the entry
for a particular file.
 Create a file: New files need to be created and added to the directory.
 Delete a file: When a file is no longer needed, we want to be able to remove it from
the directory.
 List a directory: We need to be able to list the files in a directory and the contents of
the directory entry for each file in the list.
 Rename a file: Because the name of a file represents its contents to its users, we must
be able to change the name when the contents or use of the file changes. Renaming a
file may also allow its position within the directory structure to be changed.
 Traverse the file system: We may wish to access every directory and every file
within a directory structure.

In the following sections, we describe the most common schemes for defining the logical
structure of a directory.

5.3.3 Single-Level directory

The simplest directory structure is the single-level directory. All files are contained in the
same directory, which is easy to support and understand (Figure 5.4).

Figure 5.4: Single-level directory.

A single-level directory has significant limitations:

 When the number of files increases or when the system has more than one user. Since
all files are in the same directory, they must have unique names.
 Even a single user on a single-level directory may find it difficult to remember the
names of all the files as the number of files increases.

5.3.4 Two-Level Directory

A single-level directory often leads to confusion of file names among different users. The
standard solution is to create a separate directory for each user. In the two-level directory
structure, each user has his own user file directory (UFD). The UFDs have similar structures,
but each lists only the files of a single user. When a user job starts or a user logs in, the
system's master file directory (MFD) is searched. The MFD is indexed by user name or
account number, and each entry points to the UFD for that user (Figure 5.5).

Figure 5.5: Two-level directory structure.

By Dr. Manish Kumar Mishra Page 5- 5

CoSc-2042: Operating System

Two-level directory has following features:

 Each user gets their own directory space.
 File names only need to be unique within a given user’s directory.
 A master file directory is used to keep track of each users directory, and must be
maintained when users are added to or removed from the system.
 A separate directory is generally needed for system executable files.
 Systems may or may not allow users to access other directories besides their own
 If access to other directories is allowed, then provision must be made to specify the
directory being accessed.
 If access is denied, then special consideration must be made for users to run programs
located in system directories. A search path is the list of directories in which to search
for executable programs, and can be set uniquely for each user.

5.3.5 Tree-Structured Directories

Once we have seen how to view a two-level directory as a two-level tree, the natural
generalization is to extend the directory structure to a tree of arbitrary height (Figure 5.6).
This generalization allows users to create their own subdirectories and to organize their files
accordingly. A tree is the most common directory structure. The tree has a root directory, and
every file in the system has a unique path name.

Figure 5.6: Tree-structure directory structure.

 It is an obvious extension to the two-level directory structure.

 A directory (or subdirectory) contains a set of files or subdirectories.
 Each user/process has the concept of a current directory from which all (relative)
searches take place.
 Files may be accessed using either absolute pathnames (relative to the root of the tree)
or relative pathnames (relative to the current directory).
 Directories are stored the same as any other file in the system, except there is a bit that
identifies them as directories, and they have some special structure that the OS
understands.

5.3.6 Acyclic-Graph Directories

A tree structure prohibits sharing of files. An acyclic graph allows directories to have shared
subdirectories and files. The same file may be in two different directories. A shared file is not
the same as two copies of the file. Only one actual copy exists, so any changes made by one

By Dr. Manish Kumar Mishra Page 5- 6

CoSc-2042: Operating System

user are immediately visible to the other (Figure 5.7). A common way of implementing
shared files and directories is to create a new directory entry called a link, which is
effectively a pointer to another file or subdirectory. A link can be implemented as an absolute
or relative path name.

Figure 5.7: Acyclic-graph directory structure.

 When the same files need to be accessed in more than one place in the directory
structure (e.g. because they are being shared by more than one user/process), it can be
useful to provide an acyclic-graph structure. (Note the directed arcs from parent to
child).
 UNIX provides two types of links for implementing the acyclic-graph structure.
o A hard link (usually just called a link) involves multiple directory entries that
both refer to the same file. Hard links are only valid for ordinary files in the
same filesystem.
o A symbolic link, that involves a special file, containing information about
where to find the linked file. Symbolic links may be used to link directories
and/or files in other filesystems, as well as ordinary files in the current
filesystem.
 Windows only supports symbolic links, termed shortcuts.
 Hard links require a reference count, or link count for each file, keeping track of how
many directory entries are currently referring to this file. Whenever one of the
references is removed the link count is reduced, and when it reaches zero, the disk
space can be reclaimed.
 For symbolic links there is some question as what to do with the symbolic links when
the original file is moved or deleted:
o One option is to find all the symbolic links and adjust them also.
o Another is to leave the symbolic links dangling, and discover that they are no
longer valid the next time they are used.

5.4 File-System Mounting

Just as a file must be opened before it is used, a file system must be mounted before it can be
available to processes on the system. More specifically, the directory structure can be built
out of multiple volumes, which must be mounted to make them available within the file-

By Dr. Manish Kumar Mishra Page 5- 7

CoSc-2042: Operating System

system name space. The basic idea behind mounting file systems is to combine multiple file
systems into one large tree structure.

The mount procedure is straightforward. The operating system is given the name of the
device and the mount point-the location within the file structure where the file system is to
be attached. Typically, a mount point is an empty directory. For instance, on a UNIX system,
a file system containing a user's home directories might be mounted as /home; then, to access
the directory structure within that file system, we could precede the directory names with
/home, as in /homc/jane. Mounting that file system under /users would result in the path name
/users/jane, which we could use to reach the same directory.

Next, the operating system verifies that the device contains a valid file system. It does so by
asking the device driver to read the device directory and verifying that the directory has the
expected format. Finally, the operating system notes in its directory structure that a file
system is mounted at the specified mount point. This scheme enables the operating system to
traverse its directory structure, switching among file systems as appropriate.

Let us consider an example. Nearly all personal computers have one or more floppy disk
drives into which floppy disks can be inserted and removed. To provide an elegant way to
deal with removable media, UNIX allows the file system on a floppy disk to be attached
(mounted) to the main tree. Consider the situation of Figure 5.8(a). Before the mount call, the
root file system, on the hard disk, and a second file system, on a floppy disk, are separate and
unrelated. However, the file system on the floppy cannot be used, because there is no way to
specify path names on it, UNIX does not allow path names to be prefixed by a drive name or
number; that would be precisely the kind of device dependence that operating systems ought
to eliminate. Instead, the mount system call allows the file system on the floppy to be
attached to the root file system wherever the program wants it to be. In Figure 5.8(b) the file
system on the floppy has been mounted on directory b, thus allowing access to files /b/x
and /b/y. If directory b had contained any files they would not be accessible while the floppy
was mounted, since /b would refer to the root directory of the floppy. If a system contains
multiple hard disks, they can all be mounted into a single tree as well.

Figure 5.8: (a) Before mounting, the files on drive 0 are not accessible. (b) After mounting,
they are part of the file hierarchy.

Let us consider another example. Many computers have two or more disks. On mainframes at
banks, for example, it is frequently necessary to have 100 or more disks on a single machine,
in order to hold the huge databases required. Even personal computers normally have at least

By Dr. Manish Kumar Mishra Page 5- 8

CoSc-2042: Operating System

two disks-a hard disk and a diskette drive. When there are multiple disk drives, the question
arises of how to handle them.

One solution is to put a self-contained file system on each one and just keep them separate.
Consider, for example, the situation depicted in Figure 5.9(a). Here we have a hard disk,
which we will call C :, and a diskette, which we will call A :. Each has its own root directory
and files. With this solution, the user has to specify both the device and the file when
anything other than the default is needed. For example, to copy the file x to the directory d ,
(assuming C : is the default), one would type
cp A:/x /a/d/x

This is the approach taken by systems like MS-DOS and Windows operating systems.

The UNIX solution is to allow one disk to be mounted in another disk’s file tree. In our
example, we could mount the diskette on the directory /b, yielding the file system of Figure
5.9(b). The user now sees a single file tree, and no longer has to be aware of which file
resides on which device. The above copy command now becomes
cp /b/x /a/d/x

exactly the same as it would have been if everything had been on the hard disk in the first
place.

Figure 5.9: (a) Separate file systems. (b) After mounting.

5.5 File Sharing

File sharing is desirable for users who want to collaborate and to reduce the effort required to
achieve a computing goal. Therefore, user-oriented operating systems must accommodate the
need to share files in spite of the inherent difficulties.

5.5.1 Multiple Users

 When an operating system accommodates multiple users, the issues of file sharing,
file naming, and file protection become preeminent. The system can either allow a
user to access the files of other users by default or require that a user specifically grant
access to the files.

By Dr. Manish Kumar Mishra Page 5- 9

CoSc-2042: Operating System

 To implement sharing and protection, the system must maintain more file and
directory attributes than are needed on a single-user system. Most systems use the
concepts of file (or directory) owner (or user) and group.
 The owner is the user who can change attributes and grant access and who has the
most control over the file. The group attribute defines a subset of users who can share
access to the file.
 The owner and group IDs of a given file (or directory) are stored with the other file
attributes. When a user requests an operation on a file, the user ID can be compared
with the owner attribute to determine if the requesting user is the owner of the file.
Likewise, the group IDs can be compared. The result indicates which permissions are
applicable. The system then applies those permissions to the requested operation and
allows or denies it.

5.5.2 Remote File Systems

 With the advent of networks, communication among remote computers became
possible. Networking allows the sharing of resources spread across a campus or even
around the world. One obvious resource to share is data in the form of files.
 The original method was ftp, allowing individual files to be transported across
systems as needed. Ftp can be either account or password controlled, or anonymous,
not requiring any user name or password.
 Various forms of distributed file systems allow remote file systems to be mounted
onto a local directory structure, and accessed using normal file access commands.
(The actual files are still transported across the network as needed, possibly using ftp
as the underlying transport mechanism).
 The WWW has made it easy once again to access files on remote systems without
mounting their file systems, generally using (anonymous) ftp as the underlying file
transport mechanism.

5.5.2.1 The Client- Server Model

 Remote file systems allow a computer to mount one or more file systems from one or
more remote machines. In this case, the machine containing the files is the server,
and the machine seeking access to the files is the client.
 User IDs and group IDs must be consistent across both systems for the system to
work properly. (i.e. this is most applicable across multiple computers managed by the
same organization, shared by a common group of users. )
 The same computer can be both a client and a server.
 There are a number of security concerns involved in this model:
 Servers commonly restrict mount permission to certain trusted systems only. Spoofing
(a computer pretending to be a different computer) is a potential security risk.
 Servers may restrict remote access to read-only.
 Servers restrict which file systems may be remotely mounted. Generally the
information within those subsystems is limited, relatively public, and protected by
frequent backups.
 The NFS (Network File System) is a classic example of such a system.

5.5.2.2 Failure Modes

 Local file systems can fail for a variety of reasons, including failure of the disk
containing the file system, corruption of the directory structure or other disk-
management information (collectively called metadata), disk-controller failure, cable

By Dr. Manish Kumar Mishra Page 5- 10

CoSc-2042: Operating System

failure, and host-adapter failure. User or systems-administrator failure can also cause
files to be lost or entire directories or volumes to be deleted. Many of these failures
will cause a host to crash and an error condition to be displayed, and human
intervention will be required to repair the damage.
 Remote file systems have even more failure modes. Because of the complexity of
network systems and the required interactions between remote machines, many more
problems can interfere with the proper operation of remote file systems.
o In the case of networks, the network can be interrupted between two hosts.
Such interruptions can result from hardware failure, poor hardware
configuration, or networking implementation issues.
o Consider a client in the midst of using a remote file system. It has files open
from the remote host; among other activities, it may be performing directory
lookups to open files, reading or writing data to files, and closing files.
Suddenly, the remote file system is no longer reachable. This scenario is rather
common, so it would not be appropriate for the client system to act as it would
if a local file system were lost. Rather, the system can either terminate all
operations to the lost server or delay operations until the server is again
reachable. These failure semantics are defined and implemented as part of the
remote-file-system protocol.
o Termination of all operations can result in users’ losing data-and patience.
Thus, most remote-file-system protocol either enforce or allow delaying of
file-system operations to remote hosts, with the hope that the remote host will
become available again.

5.6 Protection
When information is stored in a computer system, we want to keep it safe from physical
damage (reliability) and improper access (protection). Reliability is generally provided by
duplicate copies of files. Protection can be provided in many ways. For a small single-user
system, we might provide protection by physically removing the floppy disks and locking
them in a desk drawer or file cabinet. In a multiuser system, however, other mechanisms are
needed.

5.6.1 Types of Access

The need to protect files is a direct result of the ability to access files. Systems that do not
permit access to the files of other users do not need protection. Protection mechanisms
provide controlled access by limiting the types of file access that can be made. Access is
permitted or denied depending on several factors, one of which is the type of access
requested. Several different types of operations may be controlled:
 Read: Read from the file.
 Write: Write or rewrite the file.
 Execute: Load the file into memory and execute it.
 Append: Write new information at the end of the file.
 Delete: Delete the file and free its space for possible reuse.
 List: List the name and attributes of the file.

Other operations, such as renaming, copying, and editing the file, may also be controlled.
5.6.2 Access Control
The most common approach to the protection problem is to make access dependent on the
identity of the user. Different users may need different types of access to a file or directory.

By Dr. Manish Kumar Mishra Page 5- 11

CoSc-2042: Operating System

The most general scheme to implement identity dependent access is to associate with each
file and directory an access-control list (ACL) specifying user names and the types of access
allowed for each user.

When a user requests access to a particular file, the operating system checks the access list
associated with that file. If that user is listed for the requested access, the access is allowed.
Otherwise, a protection violation occurs, and the user job is denied access to the file. This
approach has the advantage of enabling complex access methodologies. The main problem
with access lists is their length. If we want to allow everyone to read a file, we must list all
users with read access. This technique has two undesirable consequences:
 Constructing such a list may be a tedious and unrewarding task, especially if we do
not know in advance the list of users in the system.
 The directory entry, previously of fixed size, now needs to be of variable size,
resulting in more complicated space management.

These problems can be resolved by use of a condensed version of the access list. To condense
the length of the access-control list, many systems recognize three classifications of users in
connection with each file:
 Owner: The user who created the file is the owner.
 Group: A set of users who are sharing the file and need similar access is a group, or
work group.
 Universe: All other users in the system constitute the universe.

To illustrate, consider a person, Sara, who is writing a new book. She has hired three graduate
students (Jim, Dawn, and Jill) to help with the project. The text of the book is kept in a file
named book. The protection associated with this file is as follows:
 Sara should be able to invoke all operations on the file.
 Jim, Dawn, and Jill should be able only to read and write the file; they should not be
allowed to delete the file.
 All other users should be able to read, but not write, the file. (Sara is interested in
letting as many people as possible read the text so that she can obtain appropriate
feedback.)

To achieve such protection, we must create a new group-say, text- with members Jim, Dawn,
and Jill. The name of the group, text, must then be associated with the file book, and the
access rights must be set in accordance with the policy we have outlined.

For this scheme to work properly, permissions and access lists must be controlled tightly.
This control can be accomplished in several ways. For example, in the UNIX system, groups
can be created and modified only by the manager of the facility (or by any supervisor).

5.7 Allocation Methods

The direct-access nature of disks allows us flexibility in the implementation of files, in almost
every case, many files are stored on the same disk. The main problem is how to allocate
space to these files so that disk space is utilized effectively and files can be accessed quickly.
Three major methods of allocating disk space are in wide use: contiguous, linked, and
indexed.

5.7.1 Contiguous Allocation

By Dr. Manish Kumar Mishra Page 5- 12

CoSc-2042: Operating System

 Contiguous allocation requires that each file occupy a set of contiguous blocks on the
disk as shown in figure 5.10.
 Performance is very fast, because reading successive blocks of the same file generally
requires no movement of the disk heads, or at most one small step to the next adjacent
cylinder.
 Storage allocation involves the same issues discussed earlier for the allocation of
contiguous blocks of memory (first fit, best fit, fragmentation problems, etc.). The
distinction is that the high time penalty required for moving the disk heads from spot
to spot may now justify the benefits of keeping files contiguously when possible.
 Even file systems that do not by default store files contiguously can benefit from
certain utilities that compact the disk and make all files contiguous in the process.
 Problems can arise when files grow, or if the exact size of a file is unknown at
creation time:
o Over-estimation of the file’s final size increases external fragmentation and
wastes disk space.
o Under-estimation may require that a file be moved or a process aborted if the
file grows beyond its originally allocated space.
o If a file grows slowly over a long time period and the total final space must be
allocated initially, then a lot of space becomes unusable before the file fills the
space.
 A variation is to allocate file space in large contiguous chunks, called extents. When a
file outgrows its original extent, then an additional one is allocated. An extent may be
the size of a complete track or even cylinder, aligned on an appropriate track or
cylinder boundary.

Figure 5.10: Contiguous allocation of disk space.

5.7.2 Linked Allocation

 Linked allocation solves all problems of contiguous allocation. With linked allocation,
each file is a linked list of disk blocks; the disk blocks may be scattered anywhere on
the disk. The directory contains a pointer to the first and last blocks of the file.

By Dr. Manish Kumar Mishra Page 5- 13

CoSc-2042: Operating System

 For example, a file of five blocks might start at block 9 and continue at block 16, then
block 1, then block 10, and finally block 25 (Figure 5.11).
 Each block contains a pointer to the next block. These pointers are not made available
to the user. Thus, if each block is 512 bytes in size, and a disk address (the pointer)
requires 4 bytes, then the user sees blocks of 508 bytes.
 Linked allocation involves no external fragmentation, does not require pre-known file
sizes, and allows files to grow dynamically at any time.
 Unfortunately linked allocation is only efficient for sequential access files, as random
access requires starting at the beginning of the list for each new location access.
 Allocating clusters of blocks reduces the space wasted by pointers, at the cost of
internal fragmentation.
 Another big problem with linked allocation is reliability if a pointer is lost or
damaged. Doubly linked lists provide some protection, at the cost of additional
overhead and wasted space.
 The File Allocation Table (FAT) used by DOS is a variation of linked allocation,
where all the links are stored in a separate table at the beginning of the disk. The
benefit of this approach is that the FAT table can be cached in memory, greatly
improving random access speeds (Figure 5.12).

Figure 5.11: Linked allocation of disk space.

Figure 5.12: File allocation Table.

By Dr. Manish Kumar Mishra Page 5- 14

CoSc-2042: Operating System

5.7.3 Indexed Allocation

 Indexed Allocation combines all of the indexes for accessing each file into a common
block (for that file), as opposed to spreading them all over the disk or storing them in
a FAT table. Each file has its own index block, which is an array of disk-block
addresses (Figure 5.13).
 Some disk space is wasted (relative to linked lists or FAT tables) because an entire
index block must be allocated for each file, regardless of how many data blocks the
file contains. This leads to questions of how big the index block should be, and how it
should be implemented. There are several approaches:
o Linked Scheme - An index block is one disk block, which can be read and
written in a single disk operation. The first index block contains some header
information, the first N block addresses, and if necessary a pointer to
additional linked index blocks.
o Multi-Level Index - The first index block contains a set of pointers to
secondary index blocks, which in turn contain pointers to the actual data
blocks.
o Combined Scheme - This is the scheme used in UNIX inodes, in which the
first 5 or so data block pointers are stored directly in the inode, and then
singly, doubly, and triply indirect pointers provide access to more data blocks
as needed.

Figure 5.13: Indexed allocation of disk space.

By Dr. Manish Kumar Mishra Page 5- 15