# Repository storage types

> 原文：[https://docs.gitlab.com/ee/administration/repository_storage_types.html](https://docs.gitlab.com/ee/administration/repository_storage_types.html)

*   [Hashed storage](#hashed-storage)
    *   [Translating hashed storage paths](#translating-hashed-storage-paths)
        *   [From project name to hashed path](#from-project-name-to-hashed-path)
        *   [From hashed path to project name](#from-hashed-path-to-project-name)
    *   [Hashed object pools](#hashed-object-pools)
    *   [Hashed storage coverage migration](#hashed-storage-coverage-migration)
        *   [Avatars](#avatars)
        *   [CI artifacts](#ci-artifacts)
        *   [LFS objects](#lfs-objects)
*   [Legacy storage](#legacy-storage)

# Repository storage types[](#repository-storage-types-core-only "Permalink")

版本历史

*   在 GitLab 10.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28283) .
*   静默存储已成为 GitLab 12.0 中新安装的默认存储
*   默认情况下，在 GitLab 13.0 中为新项目和重命名项目启用了哈希存储.

可以将 GitLab 配置为使用一个或多个存储库存储路径/碎片位置，它们可以是：

*   挂载到本地磁盘
*   公开为 NFS 共享卷
*   在自己的计算机上通过[Gitaly](gitaly/index.html)访问.

在 GitLab 中，这是通过`git_data_dirs({})`配置哈希值在`/etc/gitlab/gitlab.rb`进行配置的. 此处讨论的存储布局将适用于其中定义的所有分片.

在未自定义它的任何安装中可用的`default`存储库碎片指向本地文件夹： `/var/opt/gitlab/git-data` . 下面讨论的所有内容都应属于该文件夹.

## Hashed storage[](#hashed-storage "Permalink")

**注意：**在 GitLab 13.0 中，默认情况下启用了哈希存储，并且不建议使用旧存储. 在 GitLab 14.0 中将删除对旧存储的支持. 如果您尚未迁移，请查看[迁移说明](raketasks/storage.html#migrate-to-hashed-storage) . 在管理区域中的哈希存储和旧存储之间进行选择的选项已被禁用.

哈希存储是我们从 10.0 开始推出的存储行为. 与其耦合项目 URL 和将存储库存储在磁盘上的文件夹结构，不如基于项目 ID 耦合散列. 这使得文件夹结构不可变，因此消除了将状态从 URL 同步到磁盘结构的任何要求. 这意味着重命名组，用户或项目将仅花费数据库事务的费用，并且将立即生效.

哈希还有助于将存储库更均匀地分布在磁盘上，因此顶层目录包含的文件夹少于顶层命名空间的总数.

哈希格式基于 SHA256 的十六进制表示形式： `SHA256(project.id)` . 顶级文件夹使用前两个字符，然后是另一个文件夹，其后两个字符. 它们都存储在特殊的`@hashed`文件夹中，以便能够与现有的 Legacy Storage 项目共存：

```
# Project's repository:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"

# Wiki's repository:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.wiki.git" 
```

### Translating hashed storage paths[](#translating-hashed-storage-paths "Permalink")

对 Git 存储库中的问题进行故障排除，添加挂钩和其他任务，将需要您在人类可读的项目名称和哈希存储路径之间进行转换.

#### From project name to hashed path[](#from-project-name-to-hashed-path "Permalink")

哈希路径显示在项目页面的[admin 区域中](../user/admin_area/index.html#administering-projects) .

要访问"项目"页面，请转到" **管理区域">"概述">"项目"** ，然后打开该项目的页面.

此处显示" Gitaly 相对路径"，例如：

```
"@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git" 
```

这是默认 Omnibus 安装中`/var/opt/gitlab/git-data/repositories/`下的路径.

在[Rails 控制台中](troubleshooting/debug.html#starting-a-rails-console-session) ，使用数字项目 ID 或完整路径获取此信息：

```
Project.find(16).disk_path
Project.find_by_full_path('group/project').disk_path 
```

#### From hashed path to project name[](#from-hashed-path-to-project-name "Permalink")

要将哈希存储路径转换为项目名称，请执行以下操作：

1.  启动[Rails 控制台](troubleshooting/debug.html#starting-a-rails-console-session) .
2.  运行以下命令：

```
ProjectRepository.find_by(disk_path: '@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9').project 
```

该命令中带引号的字符串是您在 GitLab 服务器上找到的目录树. 例如，在默认的 Omnibus 安装上，该`.git`将是`/var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git`从目录名称的末尾删除.

输出包括项目 ID 和项目名称：

```
=> #<Project id:16 it/supportteam/ticketsystem> 
```

### Hashed object pools[](#hashed-object-pools "Permalink")

在 GitLab 12.1 中[引入](https://gitlab.com/gitlab-org/gitaly/-/issues/1606) .

**危险：**不要在池存储库中运行`git prune`或`git gc` ！ 这可能会导致依赖于相关池的"实际"存储库中的数据丢失.

通过创建第三个存储库（对象池）对公共项目的分支进行重复数据删除，其中包含来自源项目的对象. 使用`objects/info/alternates` ，源项目和派生将对象池用于共享对象. 当在源项目上运行内务管理时，会将对象从源项目移动到对象池.

```
# object pool paths
"@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git" 
```

### Hashed storage coverage migration[](#hashed-storage-coverage-migration "Permalink")

如果存储在 S3 兼容端点中的文件没有前缀`#{namespace}/#{project_name}` （对于 CI Cache 和 LFS 对象是正确的`#{namespace}/#{project_name}` ，则不会有前面提到的缺点.

在下表中，您可以找到迁移到哈希存储的范围.

| 可存储对象 | 旧版存储 | 杂物箱 | 兼容 S3 | GitLab 版本 |
| --- | --- | --- | --- | --- |
| Repository | Yes | Yes | - | 10.0 |
| Attachments | Yes | Yes | - | 10.2 |
| Avatars | Yes | No | - | - |
| Pages | Yes | No | - | - |
| Docker 注册表 | Yes | No | - | - |
| CI 构建日志 | No | No | - | - |
| CI Artifacts | No | No | Yes | 9.4 / 10.6 |
| CI 缓存 | No | No | Yes | - |
| LFS 对象 | Yes | Similar | Yes | 10.0 / 10.7 |
| 储存库 | No | Yes | - | 11.6 |

#### Avatars[](#avatars "Permalink")

每个文件都以其`id`来自数据库的形式存储在一个文件夹中. 用户头像的文件名始终为`avatar.png` . 替换头像后， `Upload`模型将被销毁，并使用另一个`id`进行替换.

#### CI artifacts[](#ci-artifacts "Permalink")

CI Artifacts 从**9.4** （GitLab Premium）开始兼容 S3，从**10.6**开始在 GitLab Core 中可用.

#### LFS objects[](#lfs-objects "Permalink")

[GitLab 中的 LFS 对象](../topics/git/lfs/index.html)遵循 Git 自己的实现，使用 2 个字符，2 个级别的文件夹实现了类似的存储模式：

```
"shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}"

# Based on object `oid`: `8909029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c`, path will be:
"shared/lfs-objects/89/09/029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c" 
```

LFS 对象也与[S3 兼容](lfs/index.html#storing-lfs-objects-in-remote-object-storage) .

## Legacy storage[](#legacy-storage "Permalink")

**不建议使用：**在 GitLab 13.0 中，默认情况下启用了哈希存储，并且不建议使用旧存储. 如果您尚未迁移，请查看[迁移说明](raketasks/storage.html#migrate-to-hashed-storage) . 在 GitLab 14.0 中将删除对旧存储的支持. 如果您使用的是 GitLab 13.0 及更高版本，则无法将新项目切换到旧版存储. 在管理区域中的哈希存储和旧存储之间进行选择的选项已被禁用.

旧版存储是 10.0 版之前的存储行为. 由于历史原因，GitLab 从项目 URL 复制了相同的映射结构：

*   项目的存储库： `#{namespace}/#{project_name}.git`
*   项目的 Wiki： `#{namespace}/#{project_name}.wiki.git`

这种结构使从现有解决方案到 GitLab 的迁移变得简单，并且管理员可以轻松找到存储库的存储位置.

On the other hand this has some drawbacks:

存储位置将集中大量的顶级名称空间. 可以通过引入[多个存储路径](repository_storage_paths.html)来减少影响.

由于备份是相同 URL 映射的快照，因此，如果您尝试恢复非常旧的备份，则需要验证是否有任何项目代替了共享相同 URL 的旧项目或已重命名的项目. 这意味着您备份中的`mygroup/myproject`可能与今天使用相同 URL 的原始项目不同.

URL 的任何更改都需要反映在磁盘上（重命名组/用户或项目时）. 在大型安装中，这可能会增加很多负载，尤其是在使用任何类型的基于网络的文件系统时.