我继续努力提高公共apt档案的透明度和信心。我在“公寓档案透明度“我在其中提到债务分配项目正在进行中。债务发行人负责镜像一些公共apt存档的索引文件。我已经意识到，拥有一个可公开审计和保存的apt存储库镜像是实现apt透明工作的核心，因此debdistget项目对我的项目来说比我想象的更为重要。当前我跟踪Trisquel公司,PureOS（纯操作系统）,侏儒和他们的上游Ubuntu公司,Debian公司和德文。
Debdistget下载发布/包装/来源文件并将其存储在上发布的git存储库中GitLab公司。由于大小限制，它使用两个存储库：一个用于发布/发布中文件（较小）和一个还包括包/源文件（较大）。请参见的存储库示例Trisquel发布文件和Trisquel包/源文件。可以在中找到所有分发版的存储库debdistutils的存档GitLab子组。
之所以拆分为两个存储库，是因为合并文件的git存储库变得很大，而且我的一些用户只需要发布文件。目前，带有软件包的存储库（现在包含几个月的数据）为9GBUbuntu公司，2.5GB用于Trisquel公司/Debian公司/PureOS（纯操作系统），970MB用于德文和450MB用于侏儒。存储库大小与存档的大小（用于初始导入）以及更新的频率和大小相关。Ubuntu对Apt分阶段更新（这会引发更大的Packages文件修改波动）似乎是其更大的主要原因。
使用大型Git存储库效率很低，GitLab CI/CD作业会产生大量网络流量，反复下载Git存储库。最重的用户是债务差异下载所有分发包存储库的项目，以便在分发之间对包列表进行差异操作。日常工作需要80分钟要运行，大部分时间都花在下载档案上。是的，我知道我可以研究运行端缓存，但我不喜欢缓存带来的复杂性。
幸运的是，并非所有的use-case都需要包文件。这个债务清偿项目只需要发布/发布中文件，以便将签名提交给西格斯托尔和Sigsum公司透明度日志。这些工作仍然运行得相当快，但看着存储库的规模增长，我很担心Debian公司440MB，PureOS（纯操作系统）130MB，Ubuntu公司/德旺90MB，Trisquel公司12MB，侏儒2MB。在这里，我认为主要的大小相关性是更新频率，而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（纯操作系统）/侏儒420MB。这是几天的数据。看起来原生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，并使用类似于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快照服务也是如此。
你怎么认为？快乐黑客！