Hashed Storage is enabled by default on new installationshashed-storage-enabled-default

updated documentation for Geo

1 files changed, 4 insertions, 10 deletions

diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index 38842693d73..834b41b3a2c 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -47,18 +47,12 @@ 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. Hashed storage is a requirement for Geo. 
-
 ## Hashed Storage
 
+CAUTION: **Important:**
+Geo requires Hashed Storage since 12.0. If you haven't migrated yet,
+check the [migration instructions](#how-to-migrate-to-hashed-storage) ASAP.
+
 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