From: Ian King (iking_at_killthewabbit.org)
Date: Tue Mar 02 2004 - 23:11:46 PST
The authors describe a protocol for distributed file storage among peer servers.
The system is premised on common x86-based personal computers with Internet
connections, and supports reading, writing and replication of whole files.
There is an approach to load balancing, and caching is supported to improve
performance.
I think it is significant that the majority of this paper is spent discussing
the algorithm for placing file copies across the network; the authors correctly
concern themselves with assuring that replication will actually provide for
redundancy (instead of the scenario where the twelve copies of the file live on
twelve servers in the same building - which just burned down). Their naming
scheme for files and nodes is quite clever, as they leverage it to generate this
distribution while still providing a "quick and dirty" heuristic for quickly
locating a replica of a file. The protocol also makes use of network metrics to
find the logically closest copy.
The authors do not provide a simple interface or search facility; locating a
file is dependent on knowing its fileID, a rather non-intuitive label; however,
there is nothing in the protocol that precludes a separate directory service.
(Needless to say, that service would introduce its own issues with coherency and
redundancy, but that was handily sidestepped by the authors.)
One especially noteworthy feature is that a file is not "deleted", it is
"reclaimed." This obviates the fairly complex requirements of ensuring actual
deletion of a given file in a loosely connected network of machines that do not
share the same administrative domain. Despite the loosely coupled nature of the
network, the protocol provides reasonably good assurance to an originating
client that its "insertion" has been successful, through the use of receipts.
Locating a file is clearly its own verification.
The protocol implements an aspect of load balancing by allowing a target machine
(to receive a replica) to forward the replica to another if its disk is too
full; the protocol deals with the situations where a forwarding machine then
fails, as well as when all machines are too full (after three attempts, the
operation is considered a failure and the client is so advised). There is a
certain amount of "soft state" retained, in that connecting nodes provide a
statement of their usable storage capacity. (While a node may underrepresent
its storage to preserve some for local use, it is conceivable it may also
overrepresent, which could corrupt the algorithms used.) Retrieval load
balancing is through simple caching, implemented by making use of the
uncommitted portion of a machine's storage and caching any file that "passed
by"; the system establishes simply tuned parameters to avoid clogging a cache
with large files, on the empirical data that small files are more commonly
retrieved. The measurements provided by the authors demonstrate that caching is
critical to the performance of this system.
Performance is measured with two dissimilar test corpi, and the data are
satisfyingly similar for each, demonstrating that the principles implemented
here are not idiomatic for either type of file collection (although two is a
fairly small set). The system's read performance is sensitive to disk
utilization, although it does not degrade significantly until utilization is
quite high - mostly because of the inability to use disk space for caching.
While the behavior of occasionally connected systems can be inferred, it would
have been interesting for the authors to have addressed that situation
explicitly. Further, mobility of systems (e.g. laptops) could cause conflict
between the distribution of nodeIDs and the network metrics as heuristics for
determining appropriate target machines for either write or read operations.
This archive was generated by hypermail 2.1.6 : Tue Mar 02 2004 - 23:29:31 PST