github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 16:11:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #5388] Ollama fails to create model when blob is already present and drive is full #49880

New Issue
Closed
opened 2026-04-28 13:17:04 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-28 13:17:04 -05:00
Owner
Copy Link

Originally created by @thot-experiment on GitHub (Jun 30, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/5388

Originally assigned to: @joshyan1 on GitHub.

What is the issue?

If I try to create a model from a modelfile that references an existing blob, ollama (i think) copies the entire blob to a temp file before realizing it already exists and creating the model. This makes model import take needlessly long and means you need to have extra free space on you drive to fit the model twice. I would expect it to just create whatever metadata files it needs and leave the model alone.

FWIW there should probably be better a way to use existing models, I've been doing this manually by symlinking models into the blobs directory as the correct name, but the import process still requires a full copy of the model before it figures it out

OS

Windows

GPU

Nvidia

CPU

Intel

Ollama version

0.1.47

Originally created by @thot-experiment on GitHub (Jun 30, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/5388 Originally assigned to: @joshyan1 on GitHub. ### What is the issue? If I try to create a model from a modelfile that references an existing blob, ollama (i think) copies the entire blob to a temp file before realizing it already exists and creating the model. This makes model import take needlessly long and means you need to have extra free space on you drive to fit the model twice. I would expect it to just create whatever metadata files it needs and leave the model alone. FWIW there should probably be better a way to use existing models, I've been doing this manually by symlinking models into the blobs directory as the correct name, but the import process still requires a full copy of the model before it figures it out ### OS Windows ### GPU Nvidia ### CPU Intel ### Ollama version 0.1.47
GiteaMirror added the bug label 2026-04-28 13:17:04 -05:00
GiteaMirror commented 2026-04-28 13:17:07 -05:00
Author
Owner
Copy Link

@thot-experiment commented on GitHub (Jun 30, 2024):

It seems like this behavior actually happens even when the file isn't already present. I'm running ollama create with a modelfile that references D:\model.gguf with Ollama keeping it's models on C. During the transferring model data phase of creating the model it briefly takes up 2x model size on C.

<!-- gh-comment-id:2198447131 --> @thot-experiment commented on GitHub (Jun 30, 2024): It seems like this behavior actually happens even when the file isn't already present. I'm running `ollama create` with a modelfile that references `D:\model.gguf` with Ollama keeping it's models on `C`. During the `transferring model data` phase of creating the model it briefly takes up 2x model size on `C`.
GiteaMirror commented 2026-04-28 13:17:08 -05:00
Author
Owner
Copy Link

@joshyan1 commented on GitHub (Jul 18, 2024):

Hey @thot-experiment, can you share a bit more details on what commands you're running, what models you've been using, and how you're tracking your disk space? Currently, we check for the blob before doing any writes of the model to the models directory. You can see this with ./ollama serve logs.

[GIN] 2024/07/18 - 10:47:12 | 200 |     214.791µs |       127.0.0.1 | POST     "/api/blobs/sha256:cfce48ca57f022cd3676c0623dbc0feb387a043d403ed32b216d3fabd9e5c5ca"
[GIN] 2024/07/18 - 10:47:21 | 200 |  8.962061125s |       127.0.0.1 | POST     "/api/create"
[GIN] 2024/07/18 - 10:49:58 | 200 |      15.959µs |       127.0.0.1 | HEAD     "/"
[GIN] 2024/07/18 - 10:49:58 | 200 |    1.410667ms |       127.0.0.1 | GET      "/api/tags"
[GIN] 2024/07/18 - 10:50:02 | 200 |      16.709µs |       127.0.0.1 | HEAD     "/"
[GIN] 2024/07/18 - 10:50:02 | 200 |  271.763167ms |       127.0.0.1 | DELETE   "/api/delete"
[GIN] 2024/07/18 - 10:50:04 | 200 |          20µs |       127.0.0.1 | HEAD     "/"
[GIN] 2024/07/18 - 10:50:22 | 201 | 10.933092292s |       127.0.0.1 | POST     "/api/blobs/sha256:cfce48ca57f022cd3676c0623dbc0feb387a043d403ed32b216d3fabd9e5c5ca"
[GIN] 2024/07/18 - 10:50:31 | 200 |  8.937056334s |       127.0.0.1 | POST     "/api/create"

The initial POST to the blob finds the blob exists and uses that blob. In the second case with the 201, it copies the blob over since we deleted it prior to the request.

<!-- gh-comment-id:2237293891 --> @joshyan1 commented on GitHub (Jul 18, 2024): Hey @thot-experiment, can you share a bit more details on what commands you're running, what models you've been using, and how you're tracking your disk space? Currently, we check for the blob before doing any writes of the model to the models directory. You can see this with `./ollama serve` logs. ``` [GIN] 2024/07/18 - 10:47:12 | 200 | 214.791µs | 127.0.0.1 | POST "/api/blobs/sha256:cfce48ca57f022cd3676c0623dbc0feb387a043d403ed32b216d3fabd9e5c5ca" [GIN] 2024/07/18 - 10:47:21 | 200 | 8.962061125s | 127.0.0.1 | POST "/api/create" [GIN] 2024/07/18 - 10:49:58 | 200 | 15.959µs | 127.0.0.1 | HEAD "/" [GIN] 2024/07/18 - 10:49:58 | 200 | 1.410667ms | 127.0.0.1 | GET "/api/tags" [GIN] 2024/07/18 - 10:50:02 | 200 | 16.709µs | 127.0.0.1 | HEAD "/" [GIN] 2024/07/18 - 10:50:02 | 200 | 271.763167ms | 127.0.0.1 | DELETE "/api/delete" [GIN] 2024/07/18 - 10:50:04 | 200 | 20µs | 127.0.0.1 | HEAD "/" [GIN] 2024/07/18 - 10:50:22 | 201 | 10.933092292s | 127.0.0.1 | POST "/api/blobs/sha256:cfce48ca57f022cd3676c0623dbc0feb387a043d403ed32b216d3fabd9e5c5ca" [GIN] 2024/07/18 - 10:50:31 | 200 | 8.937056334s | 127.0.0.1 | POST "/api/create" ``` The initial POST to the blob finds the blob exists and uses that blob. In the second case with the `201`, it copies the blob over since we deleted it prior to the request.
GiteaMirror commented 2026-04-28 13:17:09 -05:00
Author
Owner
Copy Link

@thot-experiment commented on GitHub (Jul 23, 2024):

i'm using "is the command failing because i run out of diskspace"/"do i end up with 0 disk space" as my disk space metric, and i was using ollama create model_name -f Modelfile where Modelfile starts with FROM ollamadir/models/blobs/sha256-00e832ab2a729f48c19...

i think perhaps what's going wrong here is that the ground truth in ollama is in some database rather than the file on disk, so if ollama isn't aware of the file it just blindly goes through some copy process rather than seeing that the file exists and matches the sha?

<!-- gh-comment-id:2244021477 --> @thot-experiment commented on GitHub (Jul 23, 2024): i'm using "is the command failing because i run out of diskspace"/"do i end up with 0 disk space" as my disk space metric, and i was using `ollama create model_name -f Modelfile` where Modelfile starts with `FROM ollamadir/models/blobs/sha256-00e832ab2a729f48c19...` i think perhaps what's going wrong here is that the ground truth in ollama is in some database rather than the file on disk, so if ollama isn't aware of the file it just blindly goes through some copy process rather than seeing that the file exists and matches the sha?
GiteaMirror commented 2026-04-28 13:17:11 -05:00
Author
Owner
Copy Link

@joshyan1 commented on GitHub (Jul 23, 2024):

Thanks for the response. We use the files on the server (on disk in your case) to check if the blob exists. The copy only occurs when the blob (with the matching SHA) does not exist in your model directory. Would you be able to share your logs for your model create? Could you also include a screenshot of your models directory on disk before and after you create the model? This is likely in place like \Users\____\.ollama\models\blobs

<!-- gh-comment-id:2245871432 --> @joshyan1 commented on GitHub (Jul 23, 2024): Thanks for the response. We use the files on the server (on disk in your case) to check if the blob exists. The copy only occurs when the blob (with the matching SHA) does not exist in your model directory. Would you be able to share your logs for your model create? Could you also include a screenshot of your models directory on disk before and after you create the model? This is likely in place like `\Users\____\.ollama\models\blobs`
GiteaMirror commented 2026-04-28 13:17:12 -05:00
Author
Owner
Copy Link

@joshyan1 commented on GitHub (Jul 24, 2024):

We found the cause for this bug, thanks for pointing it out. This PR should fix the create times for you

<!-- gh-comment-id:2246626490 --> @joshyan1 commented on GitHub (Jul 24, 2024): We found the cause for this bug, thanks for pointing it out. This PR should fix the create times for you
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#49880
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?