P
←→

Lab Notes: Music Server

date: 2026-06-18
author: Peterino

Test shape

  • Payload: 1,126 files, 13.45 GiB.
  • Repository: local release loreserver.
  • Branch: music.
  • Client and server were both release binaries.

Staging

lore stage --scan music

Staging was fast: 393 directories and 1,126 files staged in 0.128 seconds.

They’re fast as hell because all they do is just check file state. Content is only read during commit.

Commit

lore commit "Add half music library stress set"

The successful commit took 129.696 seconds and recorded 13.45 GiB.

lore commit created a new local revision and moved the local branch latest. In normal online mode, the content payloads were also uploaded to the remote immutable store during commit.

lore commit --stats for some reason crashed with capacity overflow. had to retry without stats.

Push

lore push music

Push took 0.851 seconds.

fast as heck because its just updating pointers on the server.

Clone

lore clone --branch music lore://127.0.0.1:42337/music-stress music-clone

Default full clone checked out 1,127 files and 13.45 GiB in 56.022 seconds.

lore clone --direct-file-write --branch music lore://127.0.0.1:42337/music-stress music-direct-write

Direct-file-write clone checked out the same payload in 55.406 seconds. In this test, direct writes were not materially faster than the default temp-file-then-rename path.

lore clone --bare --branch music lore://127.0.0.1:42337/music-stress music-bare

Bare clone took 0.125 seconds because it fetched revision state without materializing files.

Status

lore status --scan --count

A full status scan in the checked-out clone took 9.051 seconds and reported a clean worktree in sync with the remote branch.

Storage terms

Term Meaning
Payload The actual file bytes, split into fragments for storage.
Fragment A content-addressed chunk. Large files become many fragments plus a small fragment list.
Immutable store Content-addressed storage for payload fragments, tree data, metadata, and revisions.
Mutable store Small pointer storage: branch latest pointers, names, and local instance state.
Packfile An on-disk file that batches many immutable fragments together.
Client .lore The local repo state and cache. It may hold metadata without holding all payload bytes.

Storage

The bytes pushed to server are physically in the server’s immutable store. each client’s .lore directories stayed small because they mostly held metadata and local state.

Location Measured size What it means
Server immutable store 13.04 GiB The committed file payloads and immutable Lore data.
Server mutable store 704 bytes Branch and pointer state only.
Original worktree .lore 0.038 GiB Local metadata after commit uploaded payloads remotely.
Full clone .lore 237,989 bytes Clone metadata; checked-out files live in the worktree. 
server-store/immutable/index/<bucket>/pack/1

That path is Lore’s local-server backing store: fragments are spread across hash buckets, then packed into packfiles. The small mutable store is expected; it only needs to remember which branch points at which revision.

running clone streams payloads from the remote into the working tree.

Takeaways

  • stage --scan is cheap.
  • commit is the same as creating a commit or shelf on the server, this moves files over to the server.
  • push Just merges pointers and content on the remote.
  • Full clone just clones the content.
  • commit --stats needs follow-up for large payloads.

Related: chunk fetch lab notes.

← Previous Lore auth guide Next → Lab Notes: Chunk Fetch