Glacier Review

Glacier Review
Review By: Troy Ronda

Computing hosts often have underutilized disk space and network bandwidth.
Distributed storage systems exploit these properties to create a huge and
self-scaling storage resource. Individual desktop computers are not
dependable enough to provide redundant storage on their own. Many papers
claim that since hosts fail independently we can replicate data. The
claim, however, of independence is not realistic. Stored data represents
an important (monetary) asset to many organizations. Glacier,
unsurprisingly, trades storage efficiency for durability. That is, it will
sacrifice space to ensure that data survives the worst-case failure
scenarios. The authors claim that the system can be configured to prevent
data loss even when there are correlated failures on 85% of the storage
nodes. Glacier is intended to operate in an organizational intranet.
Glacier has three operating modes: normal, failure, or recovery. In the
normal operating mode, glacier performs background tasks aggregation of
coding meta-data, coding, storage of newly created objects, and fragment
maintenance. A strong minority of nodes can be off-line but only a small
fraction can be faulty. In failure mode, glacier cannot assume
communication is possible and thus tries to protect data from faulty
nodes. Recovery mode initiates after a failure node when enough of the
faulty nodes have been removed. Glacier includes versioning support,
allowing objects to be immutable. It uses erasure codes to reduce storage
overhead (splitting an object into fragments). These fragments are stored
pseudo-randomly but are locatable after a failure. Glacier achieves
durability by using massive redundancy. It is resistant to attacks and
resilient to failure. Experiment show that for the price of increased
storage overhead we can have a highly available and durable storage system
with low maintenance overhead. An example applications is a small group of
users without a central server.

I find the assumption of using an organizational intranet much more
realistic than a storage system on the Internet. The main insight that I
gained from this paper is that it is possible to create a system with
guarantees without introspection. The idea of making data immutable is
very interesting to me. I was thinking about this problem when I read
TotalRecall and a possible solution is presented in Glacier. Since disks
are largely underutilized, why not store multiple versions of a file.
There does seem to be an issue with extremely large files, such as videos.
I found the first experiment interesting. It pointed me to thinking that
this technique can be used for creating a reliable server-less environment
for an intranet. I am not sure, however, that this is a good idea.

I did not like this paper, for the most part. I found much of the paper to
be, ironically, fragmented. The ideas did not seem to carry from one
section to the next. If systems have underutilized disk space then why do
we need a self-scaling storage resource? The authors alluded to this point
by suggesting its use might be in an intranet. However an intranet does
not have independent hosts. Speaking of an intranet, is it really so
difficult for users to store their data on a server? I do not see the
benefit of this system over data server(s) that an organization might
operate. It seems that centralized data server(s) is a much simpler and
generally better feeling solution than a P2P storage (for an
organizational intranet, at least). Also, glacier maintains 2-3 full data
replicas anyways. Let me repeat, what is the point of this paper? The
intended environment seems like a completely useless example. Why is there
going to be a large scale byzantine failure *inside* an organizational
intranet? I suppose this is possible due to worms as suggested but it
still seems that the data servers should be well-protected (and
backed-up). If so, life will be good (without some complicated P2P
storage).
Received on Thu Nov 24 2005 - 10:54:48 EST