我继续努力提高公共apt档案的透明度和信心。我在“Apt存档透明度“我在其中提到债务分配项目正在进行中。债务发行人负责镜像一些公共apt存档的索引文件。我已经意识到，拥有一个可公开审计和保存的apt存储库镜像是实现apt透明工作的核心，因此debdistget项目对我的项目来说比我想象的更为重要。当前我跟踪特里斯克尔,PureOS（纯操作系统）,侏儒和他们的上游Ubuntu公司,Debian公司和德文.
Debdistget下载发布/包/源文件并将其存储在上发布的git存储库中GitLab公司。由于大小限制，它使用两个存储库：一个用于发布/发布中文件（较小）和一个还包括包/源文件（较大）。请参见的存储库示例Trisquel发布文件和Trisquel包/源文件。可以在中找到所有分发版的存储库debdistutils的存档GitLab子组.
之所以拆分为两个存储库，是因为合并文件的git存储库变得很大，而且我的一些用户只需要发布文件。目前，带有软件包的存储库（现在包含几个月的数据）为9GBUbuntu公司，2.5GB用于特里斯克尔/Debian公司/PureOS（纯操作系统），970MB用于德文和450MB用于侏儒。存储库大小与存档的大小（用于初始导入）以及更新的频率和大小相关。Ubuntu对Apt分阶段更新（这会引发更大的Packages文件修改波动）似乎是其更大的主要原因。
使用大型Git存储库效率很低，GitLab CI/CD作业会产生大量网络流量，反复下载Git存储库。最重的用户是债务差异下载所有发行版包存储库以对发行版之间的包列表执行差异操作的项目。日常工作需要处理80分钟要运行，大部分时间都花在下载档案上。是的，我知道我可以研究运行端缓存，但我不喜欢缓存带来的复杂性。
幸运的是，并非所有的use-case都需要包文件。这个债务清偿项目只需要发布/发布中文件，以便将签名提交给西格斯托尔和Sigsum公司透明度日志。这些工作仍然运行得相当快，但看着存储库大小的增长让我担心Debian公司440MB，PureOS（纯操作系统）130MB，Ubuntu公司/德文90MB，特里斯克尔12MB，侏儒2毫巴。在这里，我认为主要的大小相关性是更新频率，而Debian之所以大，是因为我跟踪的波动性不稳定。
因此，我用第一种方法实现了可扩展性。几个月前，我通过丢弃和重置这些档案库来“解决”这个问题。GitLab CI/CD作业又恢复了速度，一切都很好。然而，这意味着放弃宝贵的历史信息。几天前，我再次达到实用性的极限，并开始探索解决此问题的方法。我喜欢将数据存储在git中（它允许轻松集成软件完整性工具，如保密性卫兵和Sigstore，以及git日志提供了一种数据的时间顺序），因此感觉像是放弃了良好的属性，转而使用传统的基于磁盘的数据库方法。所以我开始了解Git-LFS公司并了解到它能够处理多GB的数据这看起来很有希望。
很快，我编写了一个脚本GitLab CI/CD作业增量更新发布/包/源使用git-LFS存储所有文件的git存储库中的文件。存储库大小现在为Ubuntu 650kb,Debian 300kb,Trisquel 50kb,德文250kb,PureOS 172kb和侏儒鸟17kb正如所料，作业可以快速克隆git存档：debdistdiff管道从运行时间从80分钟减少到10分钟这与存档大小和CPU运行时间之间的关系更为合理。
这些存储库的LFS存储大小为Ubuntu 15GB,Debian 8GB,Trisquel 1.7GB,德福1.1GB,PureOS（纯操作系统）/侏儒4.2亿。这是几天的数据。看起来原生Git比Git-LFS更擅长压缩/重复数据消除：Ubuntu的两天数据总大小已经是15GB，而纯Git的两个月数据总大小为8GB。这可能是GitLab中Git-LFS的次优实现，但我担心这种新方法也很难扩展。在某种程度上，差异是可以理解的，Git-LFS可能存储两个不同的包装文件（Trisquel的每个文件大约为90MB）作为两个90MB文件存储，但本机Git会将其存储为90MB文件的一个压缩版本和一个相对较小的补丁，以将旧文件转换为下一个文件。因此，Git-LFS方法在总体存储大小方面的扩展性出奇地差。不过，原始存储库要小得多，您通常不必提取所有LFS文件。所以这是净赢。
在这项工作中，我一直在思考我的方法与Debian的快照服务。我最终想要的是这两种服务的结合。为了有一个良好的基础来进行透明度工作，我想收集所有发布/包/源文件，以及最终的源代码和二进制文件。虽然从发行版的最新稳定版本开始是有意义的，但这项工作也应该在时间上向后扩展。为了从源代码中重新生成二进制文件，我需要能够安全地找到用于重建的二进制包的早期版本。所以我需要导入所有发布/包/源包从快照到我的存储库。从该服务器检索文件的延迟很慢，因此我无法找到一种高效/并行的方式来下载文件。如果我能完成这项工作，我相信我基于Git-LFS的存储这些文件的新方法将在未来多年内扩展。这还有待观察。也许存储库必须按发行版、体系结构或类似内容进行拆分。
另一个因素是存储成本。虽然基于git-LFS的存储库中包含几年来的文件的git存储库大小可能可以维持，但git-LFS的存储大小肯定不会维持。GitLab似乎对存储库和git-LF中的文件收取相同的费用，而且大约是每100GB 500美元每年。可以设置一个不在GitLab托管的独立Git-LFS后端来服务LFS文件。有人知道适合这种情况的服务器实现吗？我快速看了一下Git-LFS实施列表看起来最合理的方法是设置Gitea-clone福吉乔作为自托管服务器。也许云存储方法a'la S3是未来的发展方向？在GitLab上托管此内容的成本将在以下时间内可控~1TB（5000美元/年）但将其扩展到存储500 TB的数据将意味着每年250万美元这看起来物有所值。
我意识到，最终我想要一个本地的git存储库，其中包含所有apt存档的全部内容，包括它们的二进制和源代码包，并且可以发布。像快照这样的服务（约300TB的数据？）的存储需求目前并不昂贵：20TB的磁盘是500美元一块，因此一个包含36个磁盘的存储机柜大约在500美元左右720TB需要18.000美元使用RAID1意味着360TB，这是一个良好的开端。虽然我听说了~TB大小的Git-LFS存储库，但Git-LFS会扩展到1PB吗？也许拥有数百万个git-LFS指针文件的git存储库的大小将变得无法管理？为了开始使用这种方法，我决定导入Debian的amd64书虫到Git-LFS存储库中。就在附近175GB即使是在GitLab上托管也非常便宜（200GB每年1000美元）。公开此存储库将使编写使用此方法的软件成为可能（例如，移植债务再生产)，以确定这是否有用以及是否可以扩展。通过Git-LFS分发apt存储库还可以使用其他有趣的想法来保护数据。考虑配置apt以使用本地文件：//指向此git存储库的URL，并使用类似于的方法验证git签出Guix信任git的方法内容或Sigstore的gitsign.
天真地推了一下175GB单个git提交中的存档遇到了包大小限制：
remote:fatal:pack超出了允许的最大大小（4.88 GiB）
然而，将提交分解为针对部分存档的较小提交，使得推送整个存档成为可能。以下是创建此存储库的命令：
初始化
git-lfs安装
git lfs track“dists/**”“pool/**”
git添加.gitattributes
git commit-m“添加git-LFS跟踪属性”.gitattributes
time debmirror--method=rsync--host ftp.se.debian.org--root:debian--arch=amd64--source--dist=bookworm，bookworm-updates--section=main--verbose--diff=none--keyring/usr/share/keyrings/debian-archive-keyring.gpg--ignore.git。
git add dists项目
git提交-m“添加”-a
git远程添加源git@gitlab.com：debdistutils/archives/debian/mirror.git
git推送--设置上游源--全部
对于池中的d//; 做
echo$d；
时间git添加$d；
git commit-m“添加$d”-a
git推送
完成
这个结果存储库大小约为27MB，Git LFS对象存储约为174GB。我认为这种方法可以扩展到为一个版本处理所有架构，但为所有架构的所有版本使用单个git存储库可能会导致git存储库太大（>1GB）。那么，每个版本可能有一个存储库？这些存储库还可以拆分为水池/文件，或者每个体系结构或源的每个版本可能有一个存储库。
最后，我担心如何使用SHA1识别对象。Git和Debian的快照服务目前都在使用SHA1。Git有SHA-256过渡GitLab似乎正在致力于支持基于SHA256的存储库。对于这些概念的长期部署，最好直接使用SHA256标识符。Git-LFS已经使用SHA256，但Git内部使用SHA1，Debian快照服务也是如此。
你怎么认为？快乐黑客！