improve motivation, add reference

Author: jstriebel

docs/protocol/core/v3.0.rst

@@ -1366,6 +1366,8 @@ Note that any non-root hierarchy path will have ancestor paths that
 identify ancestor nodes in the hierarchy. For example, the path
 "/foo/bar" has ancestor paths "/foo" and "/".
 
+.. _storage-keys:
+
 Storage keys
 ------------
 

docs/storage_transformers/sharding/v1.0.rst

@@ -30,19 +30,22 @@ Abstract
 This specification defines an implementation of the Zarr
 storage transformer protocol for sharding.
 
+Sharding co-locates multiple chunks within a storage object, bundling them in shards.
+
 
 Motivation
 ==========
 
-Sharding decouples the concept of chunks from storage keys, which become shards.
-This is helpful when the requirements for those don't align:
+In many cases it becomes inefficient or impractical to store a large number of chunks in
+single files or objects due to the design constraints of the underlying storage,
+for example as restricted by the file block size and maximum inode number for typical file systems.
 
-- Chunk sizes need to be small for read efficiency requirements, e.g. for data streaming in browser-based visualization software, whereas
-- it becomes inefficient or impractical to store a large number of chunks in single files or objects due to the design constraints of the underlying storage, e.g. as restricted by the file block size and maximum inode number for typical file systems.
+Increasing the chunk size works only up to a certain point, as chunk sizes need to be small for
+read efficiency requirements, for example to stream data in browser-based visualization software.
 
-This does not necessarily fit the access patterns of the data, so chunks might
-need to be smaller than the minimum size of one storage key. In those cases sharding decouples those
-entities. One shard corresponds to one storage key, but can contain multiple chunks:
+Therefore, chunks may need to be smaller than the minimum size of one storage key.
+In those cases it is required to store objects at a more coarse granularity than reading chunks.
+Sharding solves this by allowing to store multiple chunks in one storage key, which is called a shard:
 
 .. image:: sharding.png
 
@@ -115,8 +118,8 @@ where a `key` is a sequence of characters and a `value` is a sequence
 of bytes. A key-value pair is called `entry` in the following part.
 
 This sharding transformer only adapts entries where the key starts
-with `data/root`, as they indicate data keys for array chunks. All other
-entries are simply passed on.
+with `data/root`, as they indicate data keys for array chunks, see
+:ref:`storage-keys`. All other entries are simply passed on.
 
 Entries starting with ``data/root`` are grouped by their common shard, assuming
 storage keys from a regular chunk grid which may use a customly configured