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.
May be.  Was going for correctness here and not perf.  If people are OK
with the style, I'll change
On Sep 11, 2014 3:01 AM, "shimingfei" <notifications@github.com> wrote:

> In core/src/main/java/tachyon/client/LocalWritableBlockChannel.java:
>
> > +
> > +  @Override
> > +  public int write(ByteBuffer src) throws IOException {
> > +    if (!mCanWrite) {
> > +      throw new IOException("Can not write cache.");
> > +    }
> > +
> > +    if (!mTachyonFS.requestSpace(src.remaining())) {
> > +      mCanWrite = false;
> > +      String msg =
> > +          "Local tachyon worker does not have enough " + "space (" + src.remaining()
> > +              + ") or no worker for " /* + mFile.mFileId + " " */ + mBlockId;
> > +
> > +      throw new IOException(msg);
> > +    }
> > +    return mLocalFileChannel.write(src);
>
> Based on our testing, Channel.write() is slower than Memory Map on large
> file size.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/amplab/tachyon/pull/427/files#r17413112>.
>