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`.
As of this moment only client write exists.  As we have agreed, client
won't touch tiered storage.

So the only way that memory write can use this abstraction is if remote
write goes in.  When that happens, this api is not the best and should be
rethought.
On Oct 21, 2014 10:02 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
>
> memory will also managed by tiered storage. current cacheBlock logic in
> WorkerStorage will be replaced.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/amplab/tachyon/pull/461/files#r19194517>.
>