anchor.diff:  =====
   `count`::
   (integer)
  -The numer of write operations performed in the test.
  -
  -`total_bytes`::
  -(integer)
  +The number of write operations performed in the test.
  +
  +`total_size`::
  +(string)
  +The total size of all the blobs written in the test.
  +
  +`total_size_bytes`::
  +(long)
   The total size of all the blobs written in the test, in bytes.
   
  +`total_throttled`::
  +(string)
  +The total time spent waiting due to the `max_snapshot_bytes_per_sec` throttle.
  +
   `total_throttled_nanos`::
  -(integer)
  +(long)
   The total time spent waiting due to the `max_snapshot_bytes_per_sec` throttle,
   in nanoseconds.
   
  +`total_elapsed`::
  +(string)
  +The total elapsed time spent on writing blobs in the test.
  +
   `total_elapsed_nanos`::
  -(integer)
  +(long)
   The total elapsed time spent on writing blobs in the test, in nanoseconds.
   =====
   
  
positive.code: The name of the blob.
  
  `size`::
  (long)
  The size of the blob in bytes.
  
  
negative.code: 
  For some blob-level tasks, the executing node will overwrite the blob while its
  peers are reading it. In this case the data read may come from either the
  original or the overwritten blob, but the read operation must not return
  partial data or a mix of data from the two blobs. If any of these reads returns
  partial data or a mix of the two blobs then the repository does not implement
  the necessary atomicity semantics that {es} requires for overwrites.
  
  The executing node will use a variety of different methods to write the blob.
  For instance, where applicable, it will use both single-part and multi-part
  