Client write refactor

Rewriting how client writes out blocks to make it easier to add remote blocks.

The current design is as follows:

Users requests access to a block

```java
Block block = Blocks.createBlock(tachyonFS, blockId, blockCapacityByte);
```

From there, the user can write to it by accessing its `Channel`.

```java
WritableBlockChannel channel = block.write();
channel.write(byteBuffer);
channel.close();
```

When the block is full, write returns -1, so you do this in a loop and create new blocks.

```java
while (buffer.remaining() > 0) {
  int n = mCurrentBlockChannel.write(buffer);
  if (n <= 0) {
    // block full, get new block
    getNextBlock();
  }
}
```

There is still one bug that I am tracking down (TachyonFSTest.unlockBlockTest2 and TachyonFSTest.lockBlockTest2 are failing), but I think the design is good enough to share.
I thought so but when I use it tests fail.

The I'd is only really used as a null check so can remove
On Sep 11, 2014 7:48 AM, "Jie Huang" <notifications@github.com> wrote:

> In core/src/main/java/tachyon/client/FileOutStream.java:
>
> >      }
> >
> >      if (mWriteType.isCache()) {
> >        mCurrentBlockId = mFile.getBlockIdBasedOnOffset(mCachedBytes);
> > -      mCurrentBlockLeftByte = mBlockCapacityByte;
> > -
> > -      mCurrentBlockOutStream =
> > -          new BlockOutStream(mFile, mWriteType, (int) (mCachedBytes / mBlockCapacityByte));
> > +      mCurrentBlockChannel = Blocks.createBlock(mTachyonFS, mFile.getBlockId((int) (mCachedBytes / mBlockCapacityByte)), mBlockCapacityByte).write();
>
>
>    1. This line is over 100 char;
>    2. Why not to use mCurrentBlockId as the second parameter in
>    creatBlock()? The blockId has been already calculated in line#140, right?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/amplab/tachyon/pull/427/files#r17424935>.
>