Information Technology Reference
In-Depth Information
14.3
Conclusion and future directions
Although individual storage devices include internal error correcting codes, ad-
ditional redundancy for error detection and correction is often needed to provide
acceptably reliable storage. In fact, today, it is seldom acceptable to store valu-
able data on a single device without some form of RAID-style redundancy. By
the same token, many if not most file systems designed over the past decade have
included software error checking to catch data corruption and loss occurrances
that are not detectable by device-level hardware checks.
Increasingly now and in the future, systems go beyond just replicating data
across mulitple disks on a single server to distributed replication across mul-
tiple servers. Sometimes these replicas are configured to protect data even if
significant physical disasters occur.
For example, Amazon's Simple Storage Service (S3) is a cloud storage service
that allows customers to pay a monthy fee to store data on servers run by
Amazon. As of when this paragraph was written (January 2012), Amazon
stated that the system was \designed to provide 99.999999999% durability ...
of objects over a given year." To provide such high reliability, Amazon must
protect against disasters like a data center being destroyed in a fire. Amazon
S3 therefore stores data at muliple data centers, it works to quickly repair
lost redundancy, and it periodically scans stored data to verify its integrity via
software checksums.
Exercises
1. Suppose that a text editor application uses the
rename
technique dis-
cussed on page 403 for safely saving updates by saving the updated file
to a new filed (e.g.,
#doc.txt#
and then calling
rename(``#doc.txt#'',
``doc.txt'')
to change the name of the updated file from
#doc.txt#
to
doc.txt
. Posix
rename
promises that the update to
doc.txt
will be
atomic|even if a crash occurs,
doc.txt
will refer to either the old file or
the new one. However, Posix does not guarantee that the entire rename
operation will be atomic. In particular, Posix allows implementations in
which there is a window in which a crash could result in a state where
both
doc.txt
and
#doc.txt#
refer to the same, new document.
a. How should a text-editing application react if, on startup, it sees
both
doc.txt
and
doc.txt
and (i) both refer the same file or (ii)
each refers to a file with different contents?
b. Why might Posix permit this corner case (where we may end up with
two names that refer to the same file) to exist?
c. Explain how an FFS-based file system without transactions could use
the \ad hoc" approach discussed in Section 14.1.1 to ensure that (i)
