diff options
Diffstat (limited to 'doc/administration/repository_storage_types.md')
| -rw-r--r-- | doc/administration/repository_storage_types.md | 43 |
1 files changed, 18 insertions, 25 deletions
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md index 834b41b3a2c..3ee8673b297 100644 --- a/doc/administration/repository_storage_types.md +++ b/doc/administration/repository_storage_types.md @@ -6,19 +6,19 @@ Two different storage layouts can be used to store the repositories on disk and their characteristics. GitLab can be configured to use one or multiple repository shard locations -that can be: +that can be: - Mounted to the local disk - Exposed as an NFS shared volume - Acessed via [gitaly] on its own machine. In GitLab, this is configured in `/etc/gitlab/gitlab.rb` by the `git_data_dirs({})` -configuration hash. The storage layouts discussed here will apply to any shard +configuration hash. The storage layouts discussed here will apply to any shard defined in it. The `default` repository shard that is available in any installations that haven't customized it, points to the local folder: `/var/opt/gitlab/git-data`. -Anything discussed below is expected to be part of that folder. +Anything discussed below is expected to be part of that folder. ## Legacy Storage @@ -80,26 +80,19 @@ by another folder with the next 2 characters. They are both stored in a special ### Hashed object pools -CAUTION: **Beta:** -Hashed objects pools are considered beta, and are not ready for production use. -Follow [gitaly#1548](https://gitlab.com/gitlab-org/gitaly/issues/1548) for -updates. +> [Introduced](https://gitlab.com/gitlab-org/gitaly/issues/1606) in GitLab 12.1. -For deduplication of public forks and their parent repository, objects are pooled -in an object pool. These object pools are a third repository where shared objects -are stored. +Forks of public projects are deduplicated by creating a third repository, the +object pool, containing the objects from the source project. Using +`objects/info/alternates`, the source project and forks use the object pool for +shared objects. Objects are moved from the source project to the object pool +when housekeeping is run on the source project. ```ruby # object pool paths "@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git" ``` -The object pool feature is behind the `object_pools` feature flag, and can be -enabled for individual projects by executing -`Feature.enable(:object_pools, Project.find(<id>))`. Note that the project has to -be on hashed storage, should not be a fork itself, and hashed storage should be -enabled for all new projects. - DANGER: **Danger:** 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 @@ -108,9 +101,9 @@ question. ### How to migrate to Hashed Storage To start a migration, enable Hashed Storage for new projects: - + 1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section. -2. Select the **Use hashed storage paths for newly created and renamed projects** checkbox. +1. Select the **Use hashed storage paths for newly created and renamed projects** checkbox. Check if the change breaks any existing integration you may have that either runs on the same machine as your repositories are located, or may login to that machine @@ -123,13 +116,13 @@ If you do have any existing integration, you may want to do a small rollout firs to validate. You can do so by specifying a range with the operation. This is an example of how to limit the rollout to Project IDs 50 to 100, running in -an Omnibus Gitlab installation: +an Omnibus GitLab installation: ```bash sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100 ``` -Check the [documentation][rake/migrate-to-hashed] for additional information and instructions for +Check the [documentation][rake/migrate-to-hashed] for additional information and instructions for source-based installation. #### Rollback @@ -138,14 +131,14 @@ Similar to the migration, to disable Hashed Storage for new projects: 1. Go to **Admin > Settings > Repository** and expand the **Repository Storage** section. -2. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox. +1. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox. -To schedule a complete rollback, see the +To schedule a complete rollback, see the [rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions. The rollback task also supports specifying a range of Project IDs. Here is an example -of limiting the rollout to Project IDs 50 to 100, in an Omnibus Gitlab installation: - +of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation: + ```bash sudo gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=50 ID_TO=100 ``` @@ -190,7 +183,7 @@ CI Artifacts are S3 compatible since **9.4** (GitLab Premium), and available in ##### LFS Objects -LFS Objects implements a similar storage pattern using 2 chars, 2 level folders, following git own implementation: +LFS Objects implements a similar storage pattern using 2 chars, 2 level folders, following Git own implementation: ```ruby "shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}" |