Lfs upload file cannot be ended #12401

New Issue

GiteaMirror · 2025-11-02T10:08:41-06:00

GiteaMirror commented

2025-11-02 10:08:41 -06:00

Originally created by @alvin6233 on GitHub (Jan 29, 2024).

Description

I use lfs upload file about 1G. But it shows that it keeps uploading and the uploaded size exceeds the actual size.
The phenomenon is as follows：

(base) ➜  didi_2 git:(main) ✗ git push
Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://code.org.cn/didi/didi_2.git/info/lfs.locksverify true
Connection to code.org.cn closed by remote host.                                                                                                                                               
Uploading LFS objects:   0% (0/1), 7.9 GB | 3.0 MB/s

The files info as follows:

(base) ➜  didi_2 git:(main) ✗ du -sh *
1.0G	file.json

Gitea Version

1.21.2

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Gitea deployed through k8s cluster

Database

None

Originally created by @alvin6233 on GitHub (Jan 29, 2024). ### Description I use lfs upload file about 1G. But it shows that it keeps uploading and the uploaded size exceeds the actual size. The phenomenon is as follows： ``` (base) ➜ didi_2 git:(main) ✗ git push Locking support detected on remote "origin". Consider enabling it with: $ git config lfs.https://code.org.cn/didi/didi_2.git/info/lfs.locksverify true Connection to code.org.cn closed by remote host. Uploading LFS objects: 0% (0/1), 7.9 GB | 3.0 MB/s ``` The files info as follows: ``` (base) ➜ didi_2 git:(main) ✗ du -sh * 1.0G file.json ``` ### Gitea Version 1.21.2 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Gitea deployed through k8s cluster ### Database None

GiteaMirror added the type/bug label 2025-11-02 10:08:41 -06:00

GiteaMirror commented

2025-11-02 10:08:42 -06:00

@Zokormazo commented on GitHub (Jan 31, 2024):

Is this with minio for lfs backend? I had the same sympthon in https://github.com/go-gitea/gitea/issues/28494

@Zokormazo commented on GitHub (Jan 31, 2024): Is this with minio for lfs backend? I had the same sympthon in https://github.com/go-gitea/gitea/issues/28494

GiteaMirror commented

2025-11-02 10:08:42 -06:00

@alvin6233 commented on GitHub (Feb 21, 2024):

Is this with minio for lfs backend? I had the same sympthon in #28494

Yes, I use minio for lfs backend. When I switch to local storage I don't have the problem, with minio I have this problem

@alvin6233 commented on GitHub (Feb 21, 2024): > Is this with minio for lfs backend? I had the same sympthon in #28494 Yes, I use minio for lfs backend. When I switch to local storage I don't have the problem, with minio I have this problem

GiteaMirror commented

2025-11-02 10:08:42 -06:00

@Zettat123 commented on GitHub (Mar 7, 2024):

Do you often encounter this bug? I only reproduced it once when the network connection was unstable.

@Zettat123 commented on GitHub (Mar 7, 2024): Do you often encounter this bug? I only reproduced it once when the network connection was unstable.

GiteaMirror commented

2025-11-02 10:08:42 -06:00

@yp05327 commented on GitHub (Mar 22, 2024):

It looks like a network issue. Maybe we can add an option to enable minio http trace.

@yp05327 commented on GitHub (Mar 22, 2024): It looks like a network issue. Maybe we can add an option to enable minio http trace. ![image](https://github.com/go-gitea/gitea/assets/18380374/c109df36-dc61-4752-a9c0-3bb68569b38c)

GiteaMirror commented

2025-11-02 10:08:43 -06:00

@stevapple commented on GitHub (Mar 22, 2024):

This should be properly solved by buffering (and implementing ReadAt), which can allow the MinIO client to re-read some part of the LFS object when recovering from a network problem.

We can choose to utilize cache, memory, disk storage, or a combination of them to balance performance and cost overhead.

@stevapple commented on GitHub (Mar 22, 2024): This should be properly solved by buffering (and implementing `ReadAt`), which can allow the MinIO client to re-read some part of the LFS object when recovering from a network problem. We can choose to utilize cache, memory, disk storage, or a combination of them to balance performance and cost overhead.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12401