You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
returnfmt.Errorf("failed to initialize root node %q: %w", fsID, err)
}
ok=true
break
}
if!ok {
returnfmt.Errorf("failed to get a unique id for metadata reader")
}
returnr.initNodes(toc)
}
This means that we create a new FS tree every time we create a reader for a TOC, regardless of whether it exists in the DB. This causes a-lot of duplication and eats up a-lot of disk space on the host machine (eg: when restoring the snapshotter).
ls -l --block-size=MB metadata.db
-rw------- 1 root root 23MB Dec 11 19:33 metadata.db
Note: I was originally expecting the size to double, there may be some fancy bbolt storage optimization going on here.
Describe the results you expected
Ideally, we shouldn't write a TOC to the DB if it already exists. One possible solution is to have the FS bucket's identified by the hash of the TOC/zTOC instead of using a random id.
Host information
OS:
Snapshotter Version:
Containerd Version:
Any additional context or information about the bug
No response
The text was updated successfully, but these errors were encountered:
Description
When converting TOC to metadata, we create a root FS bucket for every TOC, where each FS bucket is identified by a random ID.
soci-snapshotter/metadata/reader.go
Lines 120 to 139 in 8752222
This means that we create a new FS tree every time we create a reader for a TOC, regardless of whether it exists in the DB. This causes a-lot of duplication and eats up a-lot of disk space on the host machine (eg: when restoring the snapshotter).
Steps to reproduce the bug
systemctl kill soci-snapshotter systemctl restart soci-snapshotter
Note: I was originally expecting the size to double, there may be some fancy bbolt storage optimization going on here.
Describe the results you expected
Ideally, we shouldn't write a TOC to the DB if it already exists. One possible solution is to have the FS bucket's identified by the hash of the TOC/zTOC instead of using a random id.
Host information
Any additional context or information about the bug
No response
The text was updated successfully, but these errors were encountered: