Filter
Top Products
Lookaside Device State
Bandwidth No Device 2.4.18 2.4.17 2.4.13 2.4.9 2.4.0
100 Mb/s 287.7 (5.6) 292.7 (6.4) 324.7 (16.4) 346.4 (6.9) 362.7 (3.4) 358.1 (7.7)
[-1.7%] [-12.9%] [-20.4%] [-26.1%] [-24.5%]
10 Mb/s 388.4 (12.9) 282.9 (8.3) 364.8 (12.4) 402.7 (2.3) 410.9 (2.1) 421.1 (12.8)
[27.1%] [6.1%] [-3.7%] [-5.8%] [-8.4%]
1 Mb/s 1148.3 (6.9) 424.8 (3.1) 543.6 (11.5) 835.8 (3.7) 1012.4 (12.0) 1094.3 (5.4)
[63.0%] [52.7%] [27.2%] [11.8%] [4.7%]
100 Kb/s 9348.8 (84.3) 884.9 (12.0) 3011.2 (167.6) 5824.0 (221.6) 7616.0 (130.0) 8356.7 (226.9)
[90.5%] [67.8%] [37.7%] [18.5%] [10.6%]
These results show the time (in seconds) taken to compile the Linux 2.4.18 kernel. The column labeled “No Device” shows the
time taken for the compile when no portable device was present and all data had to be fetched over the network. The column
labeled “2.4.18” shows the results when all of the required data was present on the storage device and only meta-data (i.e. stat
information) was fetched across the network. The rest of the columns show the cases where the lookaside device had versions
of the Linux kernel older than 2.4.18. Each data point is the mean of three trials; standard deviations are in parentheses. The
numbers in square brackets give the “win” for each case: that is, the percentage improvement over the “no device” case.
Figure 6. Time for Compiling Linux Kernel 2.4.18
to 543.6 seconds).
On a slow LAN (10 Mb/s), lookaside caching con-
tinues to give a strong win if the portable device has
current data: 27.1% (388.4 seconds to 282.9 seconds).
The win drops to 6.1% (388.4 seconds to 364.8 sec-
onds) when the portable device is one version old
(2.4.17). When the version is older than 2.4.17, the cost
of failed lookasides exceeds the benefits of successful
ones. This yields an overall loss rather than a win (rep-
resented as a negative win in Figure 6). The worst loss
at 10 Mb/s is 8.4% (388.4 seconds to 421.1 seconds).
Only on a fast LAN (100 Mb/s) does the overhead
of lookaside caching exceed its benefit for all device
states. The loss ranges from a trivial 1.7% (287.7 sec-
onds to 292.7 seconds) with current device state to a
substantial 24.5% (287.7 seconds to 358.1 seconds)
with the oldest device state. Since the client cache man-
ager already monitors bandwidth to servers, it would
be simple to suppress lookaside at high bandwidths.
Although we have not yet implemented this simple
change, we are confident that it can result in a system
that almost never loses due to lookaside caching.
5.2 Internet Suspend/Resume
5.2.1 Benchmark Description
Our second benchmark is based on the applica-
tion that forced us to rethink the relationship between
portable storage and distributed file systems. Internet
Suspend/Resume (ISR) is a thick-client mechanism that
allows a user to suspend work on one machine, travel to
another location, and resume work on another machine
there [9]. The user-visible state at resume is exactly
what it was at suspend. ISR is implemented by layer-
ing a virtual machine (VM) on a distributed file system.
The ISR prototype layers VMware on Coda, and repre-
sents VM state as a tree of 256 KB files.
A key ISR challenge is large VM state, typically
many tens of GB. When a user resumes on a machine
with a cold file cache, misses on the 256 KB files
can result in significant performance degradation. This
overhead can be substantial at resume sites with poor
connectivity to the file server that holds VM state. If a
user is willing to carry a portable storage device with
him, part of the VM state can be copied to the device at
6