特性请求: 支持 LFS 按块上传

** 说明问题**

我使用Git LFS管理一个主要存储连续生成的CSV数据和日志文件的大型项目. 我的工作流程需要添加,承诺,并把这些文件推到一个 Git LFS 服务器上,然后把它们拉到其他服务器上进行分析——所有这一切都保留了每个文件的更改历史的全部可追溯性.

由于CSV和日志数据是连续生成的,因此每项承诺都涉及越来越多的文件. 即使只有一小部分数据被新附后,整个文件也必须被重新上载到LFS服务器上,因为Git LFS将每个文件视为由它的SHA-256散列所识别的不透明blob. 这造成了大量的冗余带宽和存储费。

说明你想要的解决方案

我希望 Git LFS 支持以块( 如 4 MiB 固定大小块) 上传文件 。 当作出新的承诺时,只需要上传新的或修改过的块,而不是整个文件. 这可以与分解或以块为基础的转让协议如何运作类似:

• 一个大文件被分割成客户端的固定大小块。
• 每一个块是散列并独立上传的
• LFS服务器从组成块重建完整文件.
• 其后,如果附有数据,只转移新的数据块。

** 说明你考虑过的备选办法**

• ** 手册文件分割**: 执行前手动分割大型 CSV/ log 文件 。 然而,这打破了数据的逻辑完整性并使得下游分析复杂化.
• ** 递增文件旋转**: 定期旋转文件(如小时日志). 这减少了每个文件的大小,但并没有消除重装大回旋文件的问题,它把负担转移到了应用层.
• ** 外部去除工具**:使用restic'或borg'等工具进行去除备份。 然而,这些并没有与Git的版本控制工作流程相融合,失去了Git LFS提供的可追溯性.

** 其他情况**

这一特点对于涉及不断增长的仅附加文件的案件特别有价值,例如:

• 时间序列CSV数据集
• 应用程序/服务器日志文件
• 机器学习训练记录
• IOT传感器数据出口

区块级分解将大大减少这些情景的上传时间,带宽消耗和服务器侧存储成本,同时保持了Git的版本和可追溯性效益.