
Git LFS上传时的文件比实际大小更大的问题
简单说一下,还没有解决。
问题描述
首先是项目中有一个文件大小是33.6MB比较大,于是将其改为用LFS进行管理,在此之前已经有其他文件也使用LFS管理并且运行正常。当时在添加了这个33.6MB的文件再进行提交的时候发生报错(用Github Desktop、SourceTree和终端都会报这个错,并且在终端是可以看到这个文件大小是慢慢变大的)。
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs.http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git/info/lfs.locksverify true
Uploading LFS objects: 50% (1/2), 328 MB | 6.8 MB/s, done.
LFS: Put "http://git402.lxblxb.top/402_Laboratory/SportAssistanceSystem-Client.git/info/lfs/objects/d9f956b455547162e7a3ffbb1d052c56f14f5e8c4e6e5ea74c7a0234bea49e0d/35308575": read tcp 192.168.1.103:2351->47.121.28.57:80: i/o timeout
error: failed to push some refs to 'http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git'
大概就是说超时提交不上去。这里就有两个奇怪的点:
前面显示的地址显示的是
10.1.16.174:3000
,而LFS又显示是访问47.121.28.57:80
timeout。(这里xxx.174是内网地址,也就是gitea实际部署的内网服务器;xxx.57是我公网的服务器,用来穿透的。因为方便在外网注册和访问,我将gitea的基本url设为了公网服务器域名,不然发送注册邮件的时候发的是内网IP,外网无法访问;然后git clone项目的时候我又使用的内网的地址想着可以更快的访问。不知道是不是LFS这个服务是默认走基本URL所以导致这两个地址不一致)这里显示在上传一个328MB的文件,然而我整个项目都没有这么大的一个文件,并且通过
git lfs ls-files --long
输出已经跟踪的大文件和对应的哈希来看,d9f956b455547162e7a3ffbb1d052c56f14f5e8c4e6e5ea74c7a0234bea49e0d/35308575
就是那一个33.6MB的文件,这个大小明显对不上。
问题研究
第一个问题
主要是问了一下GPT,提到让我检查一下git和lfs的地址是否一样。
通过git remote -v
得到:
origin http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git (fetch)
origin http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git (push)
通过git config --get-regexp lfs.*
得到:
filter.lfs.clean git-lfs clean -- %f
filter.lfs.smudge git-lfs smudge -- %f
filter.lfs.process git-lfs filter-process
filter.lfs.required true
filter.lfs.clean git-lfs clean -- %f
filter.lfs.smudge git-lfs smudge -- %f
filter.lfs.process git-lfs filter-process
filter.lfs.required true
lfs.repositoryformatversion 0
lfs.http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git/info/lfs.access basic
这么看起来两个地址确实都是内网地址,不知道为什么会出现read tcp 192.168.1.103:2351->47.121.28.57:80: i/o timeout
的问题。然后根据指引再使用curl -I http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git/info/lfs/
来检查LFS是否可以访问,但是得到的是:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 11 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0HTTP/1.1 404 Not Found
Cache-Control: max-age=0, private, must-revalidate, no-transform
Content-Type: text/plain;charset=utf-8
Set-Cookie: i_like_gitea=fe7c08d35dfa4b50; Path=/; HttpOnly; SameSite=Lax
Set-Cookie: _csrf=gL0L-MWajy_4c3W56Z_zeayu3AY6MTc0MTkyMDI3NjkyMDI3MTE4OQ; Path=/; Max-Age=86400; HttpOnly; SameSite=Lax
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Date: Fri, 14 Mar 2025 02:44:36 GMT
Content-Length: 11
居然是404 Not Found,这就很奇怪,明明LFS是可以用的,因为项目里面也已经有其他的文件使用LFS进行管理。
这个暂时还不知道是什么问题。
第二个问题
搜了一下找到几个比较相似的问题,都是在说LFS上传的文件比实际的要大:
大致可能是因为在发送的过程中出了一些问题,然后一直在重新发送,这个重新发送的大小是累计变大的。
其中有一个人提到说他是me -> nginx proxy in front -> gitlab's nginx proxy -> gitlab LFS
这样的流程,在他提高nginx的最大传输限制之后问题就解决了。这看起来跟我的问题有点像,但是经过前面的检查我的lfs应该也是直接访问内网而不是走公网的nginx才对。然后也是检查了一下nginx的设置,本身限制就是1024M,就算是这个也比那个文件的大小要大得多,看起来不是这个问题。
另外有一个人提到说是通过执行下面这个命令就成功了,试了一下也还是不行。
git config lfs.activitytimeout 60
最后根据Gitea LFS 提交大文件超时的问题解决里面的方法,设置了对应的内容,其中本地git的设置执行如下命令。
git config --global filter.lfs.process "git-lfs filter-process"
git config --global filter.lfs.required true
git config --global filter.lfs.clean "git-lfs clean -- %f"
git config --global filter.lfs.smudge "git-lfs smudge -- %f"
git config --global lfs.httptimeout 6200
git config --global lfs.dialtimeout 3600
git config --global lfs.tlstimeout 1200
git config --global lfs.concurrenttransfers 1
git config --global lfs.activitytimeout 3600
git config --global http.postbuffer 524288000
然后再在终端push就成功推上去了,但是仍然是需要等很久的。
Locking support detected on remote "origin". Consider enabling it with:
$ git config lfs.http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git/info/lfs.locksverify true
Uploading LFS objects: 100% (2/2), 116 MB | 7.6 MB/s, done.
Enumerating objects: 29, done.
Counting objects: 100% (29/29), done.
Delta compression using up to 12 threads
Compressing objects: 100% (18/18), done.
Writing objects: 100% (18/18), 11.52 KiB | 5.76 MiB/s, done.
Total 18 (delta 9), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a new pull request for 'lxb/tmp/poseInfoScene':
remote: http://git402.lxblxb.top/402_Laboratory/SportAssistanceSystem-Client/compare/master...lxb/tmp/poseInfoScene
remote:
remote: . Processing 1 references
remote: Processed 1 references in total
To http://10.1.16.174:3000/402_Laboratory/SportAssistanceSystem-Client.git
f863121..2d6ddac lxb/tmp/poseInfoScene -> lxb/tmp/poseInfoScene
这里可以看到LSF objects大小是116MB,这里也是比较奇怪,这次提交的两个文件总共不超过50MB。然而这个116MB倒是与整个仓库的大小所对应。
而且最大的问题是,在网页上查看仓库的LFS文件,并没有这次上传的33.6MB的文件,只有另一个9.3MB的文件。并且直接在网页的代码页面点开33.6MB的文件,会报错:
发生了一个错误:
getFileReader, LFS Meta object does not exist
感觉好像遇到了更严重的问题。
尝试了一下重新git clone这个项目,果然报错了这个文件下不下来。
Downloading Assets/Plugins/TextMesh Pro/Fonts/SIMHEI SDF.asset (35 MB)
Error downloading object: Assets/Plugins/TextMesh Pro/Fonts/SIMHEI SDF.asset (d9f956b): Smudge error: Error downloading Assets/Plugins/TextMesh Pro/Fonts/SIMHEI SDF.asset (d9f956b455547162e7a3ffbb1d052c56f14f5e8c4e6e5ea74c7a0234bea49e0d): [d9f956b455547162e7a3ffbb1d052c56f14f5e8c4e6e5ea74c7a0234bea49e0d] Not Found: [404] Not Found
Errors logged to 'E:\22020100011_LXB\Temporary\25_03_14\SportAssistanceSystem-Client\.git\lfs\logs\20250314T134457.516383.log'.
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: Assets/Plugins/TextMesh Pro/Fonts/SIMHEI SDF.asset: smudge filter lfs failed
接下来我尝试去gitea服务器直接翻了一下文件,在gitea容器的/data/git/lfs/d9/f9
的路径下找到了56b455547162e7a3ffbb1d052c56f14f5e8c4e6e5ea74c7a0234bea49e0d
文件,大小 也是匹配的,看起来gitea是拿哈希的前面四个字符作为了文件的路径。明明文件已经上传了为什么就是说找不到呢?
后面又搜到一个问题提到,有的文件尝试通过再次执行git lfs push --all origin
的方式能够成功上传。但是我试了还是不行,老样子到后面会重复上传然后文件变大。
最后我干脆把gitea服务器上的56b455547162e7a3ffbb1d052c56f14f5e8c4e6e5ea74c7a0234bea49e0d
文件删掉,然后再执行git lfs push --all origin
,经过一番等待之后居然done了,再到网页上检查一下发现已经成功上传了。
但是想着说再git clone一个试一下有没有问题,结果又是同样的报错,再到网页上一看那个lfs文件又没了,刚刚都有了还能不见了,真是离谱了。
最后无奈只能先暂时放弃使用LFS对这个文件进行管理,已经折腾一天了,最近还是有点忙,以后有空再尝试解决这个问题。
git lfs untrack "Assets/Plugins/TextMesh Pro/Fonts/SIMHEI SDF.asset"
git rm --cached "Assets/Plugins/TextMesh Pro/Fonts/SIMHEI SDF.asset"
# 后面再重新提交,让git重新管理这个文件