code: private Void doConcat(SegmentHandle targetHandle, long offset, String sourceSegment) throws IOException {
          long traceId = LoggerHelpers.traceEnter(log, "concat", targetHandle.getSegmentName(),
                  offset, sourceSegment);
  
          Path sourcePath = Paths.get(config.getRoot(), sourceSegment);
          Path targetPath = Paths.get(config.getRoot(), targetHandle.getSegmentName());
  
          long length = Files.size(sourcePath);
          try (FileChannel targetChannel = FileChannel.open(targetPath, StandardOpenOption.WRITE);
               RandomAccessFile sourceFile = new RandomAccessFile(String.valueOf(sourcePath), "r")) {
              if (isWritableFile(sourcePath)) {
                  throw new IllegalStateException(String.format("Source segment (%s) is not sealed.", sourceSegment));
              }
              while (length > 0) {
                  long bytesTransferred = targetChannel.transferFrom(sourceFile.getChannel(), offset, length);
                  offset += bytesTransferred;
                  length -= bytesTransferred;
              }
              targetChannel.force(false);
              Files.delete(sourcePath);
              LoggerHelpers.traceLeave(log, "concat", traceId);
              return null;
          }
      }
docs: Concatenation as currently implemented here requires that we read the data and write it back to target file.
  We do not make the assumption that a native operation exists as this is not a common feature supported by file
  systems. As such, a concatenation induces an important network overhead as each byte concatenated must be
  read and written back when the storage is backed by a remote filesystem (through NFS).
  
  This option was preferred as other option (of having one file per transaction) will result in server side
  fragmentation and corresponding slowdown in cluster performance.