In-progress work to implement inode map loading at server start.

This will be used to restore filesystem state from the cloud when the
program starts up again.  It still needs more optimization, needs journal
replay to be run afterwards, and bugfixing.

Improve object deserialization: properly parse object headers.

Start at writing out inode maps to cloud storage.

Fixes for journal replay, and drop the "superblock" cloud item.

That file in the cloud wasn't storing useful information any longer and
wasn't being used much; drop it.  It's functionality will be replaced with
some form of commit log in the cloud journal.

Fix some resource leaks in journal replay.

Implement basic full log replay.

This still needs some checking over for bugs and minor fixes.  It replays
the entire journal from the start to rebuild filesystem state.  Still
needed: partial joural replay, starting from a checkpoint in the cloud.

Update CRC-32 implementation.

Invert the result of the CRC computation at the end.  This will catch extra
null bytes at the end of the buffer, but required updating the CRC
validation.

Add in some support for journal replay.

This isn't all functional yet, but making it fully functional will require
updating the data fields that are written to the journal first...

Start work on log replay for filesystem recovery.

Right now this implements scanning of one journal segment with consistency
checking to find items that were written out.

Also fix the checksum calculation on log entries so that they will validate
properly (we want to compute the checksum so that on validation, computing
the checksum of the entire object results in a value of zero).

Add an inode map data structure to track the location of inodes in logs.

Update logic for flushing data to cloud.

Do not force a commit of the most recent data, and instead just write out
whatever was last written to the journal.

This could be a win or a loss:
  - We do not need to force a sync of all data to the journal when we
    upload data to the cloud.
  - But, we may end up writing out old data, which we'll then need to
    overwrite a short time later.

Make cache size run-time configurable.

Implement new scheme for retaining needed journal segments.

Write full filesystem snapshots to the cloud, and keep track of the journal
position before the snapshot process starts.  When it finishes, the journal
segments before that mark can be reclaimed (if needed).

This could be improved but should at least be safe.

Fix a longstanding(?) memory-leak bug when truncating a file.

Back out dirty reference tracking, as the design was flawed.

Objects can be written to the journal but not to the cloud--for example, if
a data block is written to the journal but overwritten before the file is
flushed to the cloud.  This write-combining is good, but the old code for
tracking when a journal segment could be reclaimed couldn't handle this.

So, back out that dirty reference tracking code, in preparation for
replacing it with another approach.

Make cloud storage more robust.

  - Do not consider data committed until we get a reply from the cloud.
  - Add retries on write and on read.

Add a target size for the cache, and prune the cache when it gets larger.

Track journal files which contain dirty data and which can be reclaimed.

Implement a (dumb) cache garbage collector.

This is a proof of concept; it doesn't delete journal files and deletes
cache files nearly as soon as they are unused, so it needs better
algorithms for choosing when to delete files.  But it does seem to work.

Improve journal/cloud cache locking and add access time tracking.

Debugging/refcount cleanups.

Minor bugfixes/tweaks.

First attempt at supporting reading data back from cloud log segments.

There are still some bugs, hacks, race conditions, etc., but this seems to
be doing mostly the right thing and so is a good start.

Serialized inode data should be dropped from caches, too.

Attempt at limiting the rate at which memory is dirtied.

Reference counting bugfix.

Newly-created inodes should be marked as modified.

The NFS proxy code previously didn't do this, with the result that some
inodes (symlinks were first noticed, but the problem affected other areas
too) would not get entered into the appropriate LRU lists.

More aggressively use memory-mapped data for cloud log items.

Replace a string with a memory-mapped version as soon as possible when the
item is written out.  The intent is that memory-mapped versions rely on the
kernel's memory management, and don't need to be written to swap like a
private copy would, and so should give better overall system memory
management.

Improve tracking of memory usage in BlueSky.

Most data, except for dirty data blocks not flushed out to the journal yet,
will be in the form of cloud log entries.  Create statistics counters to
track how many cloud log items are in each of several states (in memory
only, writeback, on disk, in cloud).

More fixes to BlueSky cache management.

Drop old code for flushing data to the cloud.

Work to unify the cloud segment writing with other cache management.

Split cloud log segments into modestly-sized chunks.

Add a null storage implementation.

This simply discards all data written to it.  Useful for testing purposes,
if all the data remains in the local log and so we never need to fetch data
from the storage implementation.

Fix some memory leaks.

Make links between cloud log entries direct.

Rather than giving the ID provide a direct pointer to the object.

Rework caching of data blocks to eliminate double-caching.

Previously data could be cached both as a cloud log item and as a string at
the inode level.  Now cache as a string for dirty data and a cloud log item
for clean data.

Fix up reference counting for cloud log items.

A few attempted bugfixes for log data lifetimes.

A much better fix will depend on reworking this code a bit more.

Fix up reference counting for memory-mapped journal log segments.

Improve the reading back of objects committed to the journal.

Implement a cache of memory-mapped log files so that when multiple objects
are requested we can re-use the mapping.  Make log files fixed sizes (call
ftruncate when opening the log file) so the entire thing can be memory
mapped at the start.

More cache behavior tweaks.

Preliminary support for dropping cached file data from memory.

Work to allow mmap-ed log entries to be used for data blocks.

Gradually converting code to use cloud logs for storing data.

Dump cloud location of data items in debug output.

(Mostly) merge local and cloud logging together.

Preparatory work before implementing proper cloud writing.

Some initial work on logging gathering data into cloud log segments.

This is still in progress, and needs to be better hooked in to cache
management as well as actually writing out a proper sequence of logs
instead of overwriting the same location each time.  But it should have the
basics of gathering up data for dirty inodes into a segment and writing it.

Initial work on cloud log-structured storage.

Right now this is just the first work towards tracking what objects are
stored where (a log in the cloud, in local memory, on local disk, etc.).

Code cleanup.

Add checksumming to filesystem journal.

This will be used to check for consistency during log recovery.

Allow batched log writes when writing dirty inodes.

Basic filesystem journaling.

Infrastructure for writing log entries synchronously (though the log format
is not yet finished and isn't yet useful), and a partial hook into the
BlueSky filesystem.

Add synchronous inode logging in the NFS server.

This is in preparation for adding inode logging for data durability.

Barriers did not handle requests that finished too quickly.

Commit a few log benchmark results.

Bugfix.

Update commit log benchmarks.

Make the log benchmark configurable and make a parameter sweep script.

A new microbenchmark tool to figure out what format to use for logs.

We want to log filesystem operations to disk so they are persistent across
proxy crashes, but should do so in a manner that is relatively high
performance...  Try to figure out what that should be.

Attempt to batch together database writes for performance.

Doesn't seem to help all that much though...

Switch to an explicit BDB operations queue instead of thread pool.

Create a dedicated thread for handling BDB operations, and pass gets/puts
to it via a queue.  This is in preparation for batching operations
together in transactions to see if we can improve performance that way.

Remove localstore.c; for now BDB work will be done in store-bdb.c.

Some test work with using Berkeley DB for a local disk cache.

Implement this at first by simply making it a new storage backend.  Later
we will have to make it a separate layer so we can stack a Berkeley DB
cache/write log with a remote storage option.

Some new format design notes.

Add another S3 benchmark tool.

More S3 benchmark work.

Add an S3 test script for range requests.

Add results from a simple test run of the multi:s3 backend.

Testing S3 with more object sizes.

More Amazon S3 test script updates.

Fix a possibel deadlock from synchronizing the superblock.

Add a "multi" storage backend which doubles all GET requests.

This can be used to test whether the performance with S3 improves when
making parallel requests to reduce latency.

Updates to script for testing multiple parallel fetches.

Testing of multiple requests in parallel.

Add a few more test scripts.

More trace analysis scripts.

Improve analysis of S3 packet traces.

Keep IP addresses with network measurements.

More S3 performance evaluation scripts.

Compile fix for directory renaming; use virtual host access method for S3.

More cloud storage performance-measurement scripts.

Directory reorganization.

Work on more tools for automating cloud storage performance measurement.

A few more Azure/analysis updates.

Another update to the Azure test code.

Start work on a test program to communicate with Windows Azure.

This could provide another backend for BlueSky, and it might be nice to at
least make a few benchmark measurements of Azure to complement the S3 ones.

Simple tool for analyzing a dump of a single S3 connection.

Will try to extract information about any delays in the transfers.

More playing with parsing of packet traces.

Extract window size values (and handle TCP window scaling).

More updates to S3 pipelining test.

It seems there is a bug in S3 with many pipelined requests that we are
triggering in testing:
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=39907

Create a simple Python script for sending pipelined GET requests to S3.

S3 doesn't seem to respond properly to these yet.

Print flow identification in TCP parsing output.

Also fix a division-by-zero bug in computing bandwidth if no data is
transferred.

Some initial results of running the NFS replay code.

Fix a memory leak in the NFS-over-UDP code.

The TCP code still has a per-connection leak, but at least this should help
with the UDP per-request leak.

Enable real-time trace replay instead of maximum-speed replay mode.

Allow longer server names; fixes (temporarily) a buffer overflow.

Code fixes for TBBT.

Add two missing files from the TBBT import.

Import TBBT (NFS trace replay).

Code downloaded from http://www.ecsl.cs.sunysb.edu/TBBT/.