Refactor storage dir

I propose that we make `StorageDir` the entry point and drop `BlockHandler`.  The core reasons for this are that:

`BlockHandler` is the same thing as java's `Channel`.  Easier to use one std convention than create a new one.
`StorageDir` is the main entry point anyways, since the path is relative to the tier, so `BlockHandler` can't be the gateway since it's path depends on the `StorageDir`.
If I understand you correctly, you're concern is who's patch goes in first.

From the networking side and from the write side, it's always memory as was
agreed to in JIRA.  In that case tired is not needed in the write path of
the block.  It's only needed in read and eviction.

Since it's not needed on the write path, then it doesn't matter which patch
goes in first; no patch is dependent on the other.
On Oct 21, 2014 9:50 PM, "shimingfei" <notifications@github.com> wrote:

> In core/src/main/java/tachyon/worker/hierarchy/StorageDir.java:
>
> > -   * @param blockId Id of the block
> > -   * @return true if success, false otherwise
> > -   * @throws IOException
> > -   */
> > -  public boolean cacheBlock(long userId, long blockId) throws IOException {
> > -    String srcPath = getUserTempFilePath(userId, blockId);
> > -    String dstPath = getBlockFilePath(blockId);
> > -    long blockSize = mFs.getFileSize(srcPath);
> > -    boolean result = mFs.rename(srcPath, dstPath);
> > -    if (result) {
> > -      addBlockId(blockId, blockSize);
> > -    }
> > -    return result;
> > -  }
> > +//  /**
> > +//   * Move the cached block file from user temporary directory to data directory
>
> because I am working with the integration now, unless this PR will merged
> after hierarchy code or hierarchy code will be merged after both remote
> write code and this PR.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/amplab/tachyon/pull/461/files#r19194359>.
>