Making hashed storage a requirement of Geo

doc/administration/geo/replication/configuration.md

@@ -205,7 +205,7 @@ that the secondary can act on those notifications immediately.
 Make sure the secondary instance is running and accessible.
 You can login to the secondary node with the same credentials as used in the primary.
 
-### Step 4. (Optional) Enabling hashed storage (from GitLab 10.0)
+### Step 4. Enabling hashed storage (from GitLab 10.0)
 
 CAUTION: **Warning**:
 Hashed storage is in **Beta**. It is not considered production-ready. See

doc/administration/geo/replication/configuration_source.md

@@ -125,7 +125,7 @@ that the secondary can act on those notifications immediately.
 Make sure the secondary instance is running and accessible. 
 You can login to the secondary node with the same credentials as used in the primary.
 
-### Step 4. (Optional) Enabling hashed storage (from GitLab 10.0)
+### Step 4. Enabling hashed storage (from GitLab 10.0)
 
 Read [Enabling Hashed Storage][configuration-hashed-storage]
 

doc/administration/repository_storage_types.md

@@ -29,19 +29,18 @@ Any change in the URL will need to be reflected on disk (when groups / users or
 projects are renamed). This can add a lot of load in big installations,
 especially if using any type of network based filesystem.
 
+CAUTION: **Caution:**
 For Geo in particular: Geo does work with legacy storage, but in some
 edge cases due to race conditions it can lead to errors when a project is
 renamed multiple times in short succession, or a project is deleted and
 recreated under the same name very quickly. We expect these race events to be
 rare, and we have not observed a race condition side-effect happening yet.
-
 This pattern also exists in other objects stored in GitLab, like issue
 Attachments, GitLab Pages artifacts, Docker Containers for the integrated
-Registry, etc.
+Registry, etc. Hashed storage is a requirement for Geo. 
 
 ## Hashed Storage
 
-
 Hashed Storage is the new storage behavior we rolled out with 10.0. Instead
 of coupling project URL and the folder structure where the repository will be
 stored on disk, we are coupling a hash, based on the project's ID. This makes