Merge pull request #1 from amplab/master

merge
Merge pull request #2 from amplab/master

merge from tachyon master
Merge pull request #3 from amplab/master

merge from tachyon master
Revert "remove gfs"

This reverts commit ee07614ffbc7127dc9dd4f57b072a412e4d75b16.
add glusterfs configuration setting info
switch glusterfs repo to sonatype
Introduce fine-grained, hierarchical pinning

When a file is pinned, Tachyon will not evict it -- effectively, this
allows Tachyon to provide two-level priority caching. The only way to
configure the files that should be pinned, however, is via the
"pin list", which is determined by system properties that are set when
the Tachyon master is started, and cannot be changed at runtime or
at a finer granularity than a directory.

This PR introduces a per-Inode "pinned" flag. Only files will be pinned
in memory, but a folder's pinned flag is used as the default value
for new files and folders created inside that folder.

The pinned flag on a file or folder may be updated dynamically. Setting
the flag on a folder will cause us to recursively apply the update to
all children. This can be an expensive operation for large nodes.

A few implementation notes:
  - The pinlist has been removed.
  - InodeFile.mPin and MasterInfo.mFileIdPinList were reused, but with
    the updated semantics.

Outstanding issues:
  - This change does not provide backwards compatibility for EditLog,
    as I had to add a new field. We should have a more general solution
    that logs the Tachyon version in the EditLog so we can provide
    backwards compatibility, or else provide a script to upgrade old
    journals.
  - Use of cached ClientFileInfos can lead to unexpected behavior, because
    we have no way of pushing the fact that a file was either pinned
    or unpinned to the users. This only impacts the caching of files,
    not the eviction, as the latter always re-fetches the mFileIdPinList.
Throw IOException instead of RuntimeException
update the delete semantics
Update web app and documentation
Merge pull request #212 from aarondav/propSetting

Introduce fine-grained, hierarchical pinning
format thrift
thrift gen
better handle worker's address
better handle TachyonFS's network address
Merge pull request #4 from amplab/master

merge from tachyon master
import class NetworkUtils
Merge pull request #218 from CrazyJvm/netutil-import

Netutil import
Use JSON as the EditLog's serialization format

Using JSON as a serialization format brings a couple great benefits:
  - Evolvability of the log format -- JSON allows us to easily add,
    remove, or change fields in our serialization format and still
    successfully read from old logs. This is infeasible today.
  - Human readability of the log, enabling easier manual intervention
    if something goes wrong during recovery and better error reports.

There are some potential downsides of using JSON over binary:
  - Performance overheads of serializing more data and as JSON.
    Deserialization costs are less important, as they are only during
    recovery.
  - Space overheads of human-readable String data overy binary data.

In order to help quantify the cost of JSON, I did a brief performance
evaluation between this implementation and the prior binary format.
The evaluation included simply continuously writing one type of log
message for 10 seconds, then counting (A) how many entries were written
and (B) how large the log had grown. Note that a flush() was inserted
after every write.

The results are as follows:

**Large Entries [1]**
```
Version | Ops/sec | Bytes/op
JSON    | 105,894 | 300
Binary  |   5,410 | 155
```

**Small Entries [2]**
```
Version | Ops/sec | Bytes/op
JSON    | 174,400 | 100
Binary  | 124,267 |  10
```

Somewhat inexplicably, the JSON version always won in speed, perhaps because
it buffers each entry before writing it out, whereas the binary format
writes every field individually. Regardless of relative difference, the JSON
format was able to sustain >100k operations per second, which seems sufficient.

There was certainly significant blowup in the actual log size, though, up to
10x for very small logs. Hopefully this will not be impactful on actual disk
usage, though, as we continuously clean up old edit logs as we merge them into
the durable image file.

[1] Large entry:

```java
editLog.createDependency(Lists.newArrayList(1,2,3), Lists.newArrayList(4,5,6), "commandPrefix",
    Lists.newArrayList(ByteBuffer.wrap(new byte[4]), ByteBuffer.wrap(new byte[8])),
    "comment", "framework", "frameworkVersion", DependencyType.getDependencyType(1),
    1234, 34932482432L);
```

[2] Small entry:
```java
editLog.setPinned(123, true)
```
fix line length