Information Technology Reference
In-Depth Information
fsync Stil Lives
Although
few
file
systems
today
rely
on
scanning
disks
when
recover-
ing
from
a
crash,
fsck
(and
variants
on
other
operating
systems)
is
still
provided
as
an
“emergency
fix”
when
on-disk
data
structures
are
corrupted
for
other
reasons
(e.g.,
due
to
software
bug
or
storage
device
failure).
could take tens of minutes to a few hours for large servers with many disks,
and technology trends indicated that scan times would grow rapidly worse.
Although the first two were significant disadvantages of the approach, it was
the third that finally made depending on careful ordering and
fsck
untenable
for most le systems. New le systems created since the late 1980's almost
invariably use other techniques|primarily various forms of transactions that
we discuss in the rest of this section.
Application-level approaches. Although modern file systems often use trans-
actions internally, some standard file system APIs such as the Posix API provide
only weaker abstractions, forcing applications to take their own measures if they
want to atomically apply a set of updates. Many use application-level transac-
tions, but some continue to use more ad hoc approaches.
For example, suppose that a user has edited several parts of a text file and
then wants to save the updated document. The edits may have inserted text
at various points in the document, removed text at others, and shifted the
remaining text forwards or backwards|even a small insertion or deletion early
in the document could ripple through the rest of the file.
If the text editor application were simply to use the updated file in its mem-
ory to overwrite the existing file, an untimely crash could leave the file in an
incomprehensible state|the operating system and disk schedulers may choose
any order to send the updated blocks to nonvolatile storage, so after the crash
the file may be an arbitrary mix of old and new blocks, sometimes repeating
sections of text, sometimes omitting them entirely.
To avoid this problem, the text editor may take advantage of the semantics
of the Posix
rename
operation, which renames the file called
sourceName
to
be called
targetName
instead. Posix promises that if a file named
targetName
already exists,
rename
's shift from having
targetName
refer to the old file to
having it refer to the new one will be atomic. (This atomicity guarantee may
be provided by transactions within the file system or by ad hoc means.)
So, to update an existing file
design.txt
, the text editor first writes the
