Merge branch 'lm-pools-v-hashed' into 'master'

Docs: Clarify where repository pools are stored vs. hashed storage

See merge request gitlab-org/gitlab!60603

doc/administration/repository_storage_types.md

@@ -131,7 +131,7 @@ forks use the object pool for shared objects. For more information, see
 [How Git object deduplication works in GitLab](../development/git_object_deduplication.md).
 
 Objects are moved from the source project to the object pool when housekeeping is run on the source
-project. Object pool repositories are stored similarly to regular repositories:
+project. Object pool repositories are stored similarly to regular repositories in a directory called `@pools` instead of `@hashed`
 
 ```ruby
 # object pool paths
@@ -139,8 +139,8 @@ project. Object pool repositories are stored similarly to regular repositories:
 ```
 
 WARNING:
-Do not run `git prune` or `git gc` in object pool repositories. This can cause data loss in the
-regular repositories that depend on the object pool.
+Do not run `git prune` or `git gc` in object pool repositories, which are stored in the `@pools` directory.
+This can cause data loss in the regular repositories that depend on the object pool.
 
 ### Object storage support
 

doc/development/git_object_deduplication.md

@@ -35,9 +35,9 @@ to work, it is of course critical that **no objects ever get deleted from
 B** because A might need them.
 
 WARNING:
-Do not run `git prune` or `git gc` in pool repositories! This can
-cause data loss in "real" repositories that depend on the pool in
-question.
+Do not run `git prune` or `git gc` in object pool repositories, which are
+stored in the `@pools` directory. This can cause data loss in the regular
+repositories that depend on the object pool.
 
 The danger lies in `git prune`, and `git gc` calls `git prune`. The
 problem is that `git prune`, when running in a pool repository, cannot
@@ -45,8 +45,8 @@ reliable decide if an object is no longer needed.
 
 ### Git alternates in GitLab: pool repositories
 
-GitLab organizes this object borrowing by creating special **pool
-repositories** which are hidden from the user. We then use Git
+GitLab organizes this object borrowing by [creating special **pool
+repositories**](../administration/repository_storage_types.md) which are hidden from the user. We then use Git
 alternates to let a collection of project repositories borrow from a
 single pool repository. We call such a collection of project
 repositories a pool. Pools form star-shaped networks of repositories