Description of problem:

Found a bug while reading code where if a readv() falls partly in a region of the sharded file that contains holes which are represented by the existence of zero-byte shards (for instance block-0 file is one example which will exist by default since creation under its parent directory but _may_ not have any data written into it and there could be other blocks that are written to by the application). In this case, a read on such a shard would return 0 bytes, although internally shard translator is supposed to interpret that as a hole (filled with zeroes) and update op_ret (the final exit status of the read which is the number of bytes read) based on the following logic:

  read size of ith shard = { shard_block_size if (last_shard_index > i),
                             (offset % shard_block_size)     otherwise 

Failing to do so could cause reads from the application to prematurely exit if shard translator returns "zero bytes read" status,
or in some cases return fewer bytes read than are actually filled in the actual buffer, which could mislead the translators above shard or even the application.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: