From: David Coleman (dcoleman_at_cs.washington.edu)
Date: Wed Mar 03 2004 - 15:56:06 PST
CFS is a distributed read-only file system that distributes both
metadata and data blocks throughout a peer-to-peer system to achieve
efficiency, robustness, and load-balancing. It uses similar techniques
to PAST and other peer-to-peer systems but differ significantly in the
details. It distributes each block of every file for better robustness
and load-balancing.
One problem I see with the approach to load-balancing is that the block
ID is hash solely from the contents of the block. If smaller values are
chosen for blocks, it is more likely that blocks will hash to the same
value due to the fact that files often contain blocks of zeroes. These
blocks will all hash to the same value, the same block ID. While that is
an intriguing approach for minimizing redundant data, it is certainly
not intended by this system. I would probably add file size and block
offset into the file to the hashing function to deal with the potential
for identical hashes.
Also, this system assumes that load-balancing is achieved through the
nature of the hashing algorithm. This is only probabilistically randomly
distributed and does not guarantee load-balancing in its own right. The
PAST system acknowledged this shortcoming and would re-hash with a
different random value in extreme cases to redistribute the load.
The successor list and finger table structures are pretty cool
approaches to locating the node responsible for a block. The speed with
which lookups are performed is impressive given the potential number of
nodes. Caching blocks along the lookup path is also very clever.
Also, distributing each block of the file results in significantly more
overhead for locating and retrieving an entire file. The authors
acknowledge this and address it via caching and pre-fetching, but in
very large systems under heavy loads I would expect the additional
overhead of per-block fetches to cause some fairly significant
performance degradation.
The one thing that somewhat disappointed me was the fact that this
system was pretty much designed for read-only statically updated data. I
tried to spend some time thinking about modifications to the system to
allow it to be a read-write file system and quickly ran out of time. I
understand the limitation and like what they’ve done, but I would like
to try to extend the system.
Being a Roxio employee, I’ve noted with some amusement that both papers
reference Napster. Roxio now owns Napster and we’ve watched Napster be
transformed from a peer-to-peer system to a traditional client-server
system (although I’m sure it uses some of the distributed designs that
we studied earlier).
This archive was generated by hypermail 2.1.6 : Wed Mar 03 2004 - 15:56:13 PST