FILE-SYSTEM MANAGEMENT AND OPTIMIZATION
of the disk
Disk is divided into
cylinder groups, each
with its own i-nodes
(a) I-nodes placed at the start of the disk.
(b) Disk divided into cyl-
inder groups, each with its own blocks and i-nodes.
For instance, SSDs have peculiar properties when it comes to reading, writing, and
deleting. In particular, each block can be written only a limited number of times, so
great care is taken to spread the wear on the disk evenly.
4.4.5 Defragmenting Disks
When the operating system is initially installed, the programs and files it needs
are installed consecutively starting at the beginning of the disk, each one directly
following the previous one. All free disk space is in a single contiguous unit fol-
lowing the installed files. However, as time goes on, files are created and removed
and typically the disk becomes badly fragmented, with files and holes all over the
place. As a consequence, when a new file is created, the blocks used for it may be
spread all over the disk, giving poor performance.
The performance can be restored by moving files around to make them contig-
uous and to put all (or at least most) of the free space in one or more large contigu-
ous regions on the disk. Windows has a program,
, that does precisely this.
Windows users should run it regularly, except on SSDs.
Defragmentation works better on file systems that have a lot of free space in a
contiguous region at the end of the partition. This space allows the defragmentation
program to select fragmented files near the start of the partition and copy all their
blocks to the free space.
Doing so frees up a contiguous block of space near the
start of the partition into which the original or other files can be placed contigu-
ously. The process can then be repeated with the next chunk of disk space, etc.
Some files cannot be moved, including the paging file, the hibernation file, and
the journaling log, because the administration that would be required to do this is
more trouble than it is worth. In some systems, these are fixed-size contiguous
areas anyway, so they do not have to be defragmented. The one time when their
lack of mobility is a problem is when they happen to be near the end of the parti-
tion and the user wants to reduce the partition size. The only way to solve this
problem is to remove them altogether, resize the partition, and then recreate them
Linux file systems (especially ext2 and ext3) generally suffer less from defrag-
mentation than Windows systems due to the way disk blocks are selected, so man-
ual defragmentation is rarely required. Also, SSDs do not really suffer from frag-
mentation at all.
In fact, defragmenting an SSD is counterproductive. Not only is
there no gain in performance, but SSDs wear out, so defragmenting them merely
shortens their lifetimes.
4.5 EXAMPLE FILE SYSTEMS
In the following sections we will discuss several example file systems, ranging
from quite simple to more sophisticated. Since modern UNIX file systems and
Windows 8’s native file system are covered in the chapter on UNIX (Chap. 10) and
the chapter on Windows 8 (Chap. 11) we will not cover those systems here.
will, however, examine their predecessors below.
4.5.1 The MS-DOS File System
The MS-DOS file system is the one the first IBM PCs came with.
It was the
main file system up through Windows 98 and Windows ME.
It is still supported
on Windows 2000, Windows XP,and Windows Vista, although it is no longer stan-
dard on new PCs now except for floppy disks. However, it and an extension of it
(FAT -32) have become widely used for many embedded systems.
cameras use it. Many MP3 players use it exclusively.
The popular Apple iPod uses
it as the default file system, although knowledgeable hackers can reformat the iPod
and install a different file system. Thus the number of electronic devices using the
MS-DOS file system is vastly larger now than at any time in the past, and certainly
much larger than the number using the more modern NTFS file system. For that
reason alone, it is worth looking at in some detail.
To read a file, an MS-DOS program must first make an
system call to get
a handle for it. The
system call specifies a path, which may be either absolute
or relative to the current working directory. The path is looked up component by
component until the final directory is located and read into memory.
It is then
searched for the file to be opened.
Although MS-DOS directories are variable sized, they use a fixed-size 32-byte
directory entry. The format of an MS-DOS directory entry is shown in Fig. 4-30. It
contains the file name, attributes, creation date and time, starting block, and exact