From 39229eed34eb0ec27a09aeb174668919239d8a8c Mon Sep 17 00:00:00 2001 From: Gabriel Mazetto Date: Thu, 13 Jun 2019 05:18:05 +0200 Subject: Hashed Storage is enabled by default on new installations updated documentation for Geo --- doc/administration/repository_storage_types.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) (limited to 'doc') 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 -- cgit v1.2.1