Skip to content

rolling tape optimizations - #6

Merged
Boog900 merged 3 commits into
Cuprate:mainfrom
redsh4de:feat/o1-rolling-tape
Sep 12, 2026
Merged

Boog900 merged 3 commits into
Cuprate:mainfrom
redsh4de:feat/o1-rolling-tape

Conversation

@redsh4de

Copy link
Copy Markdown
Contributor

Rolling tapes:

  • Look up files by index, not by deque position. Reads, writer() and commits were O(n) in the number of files. They are now O(1).
  • Commits visit only the files that go out of range, not every file.
  • A truncate below the oldest file no longer creates every file in between. The tape creates each file when it writes to it.
  • Old files past the new end stay on disk, but the tape no longer keeps them open. It reuses them when it grows back.
  • Moving the start forward marks old files for deletion. A truncate that moves the start back now unmarks every file it needs again. Before, it unmarked only one, so the tape could delete files that held new data.
  • read_bytes returns an error if a file in the range does not exist. Before, it returned Ok and left part of the buffer unchanged.
  • Reserve the tape name metadata. A rolling tape with this name could delete the database metadata.

Other:

  • Reject a fixed-sized tape whose start is not a multiple of the entry size.
  • Cached tape: start the cache at start_index for a new tape. Before, the cache started at 0, which could cause a panic.
  • Cached tape: release the cache lock before a disk read, so appends do not wait for the read.

Behaviour changes:

  • A commit can delete the last file when the start moves past it. Before, the tape always kept the last file.
  • The name metadata is rejected for every rolling tape, also when tape has its own directory.
  • A fixed-sized tape whose stored start is not a multiple of the entry size does not open. Before, it opened, but its entries could not be read.

@redsh4de
redsh4de marked this pull request as ready for review September 11, 2026 13:43
@redsh4de
redsh4de force-pushed the feat/o1-rolling-tape branch from 5fad9f8 to 2308d76 Compare September 11, 2026 14:22

@Boog900 Boog900 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a nit and a simplification

Comment thread src/tapes/rolling_tape.rs
Comment on lines +187 to +194
let first_file_touched = {
let files = self.files.read();
let slot = current_file_idx
.checked_add(1)
.map_or(files.len(), |next| slot_for(&files, next));
slot.checked_sub(1)
.map_or(current_file_idx, |slot| files[slot].file_index)
};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This confused me, couldn't we just do first_file_touched: current_file_idx without all this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ensures that if the current file is missing, we sync the previous one as it might not have been synced yet

Made it easier to reason about

@Boog900 Boog900 Sep 12, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't there be more than 1 previous file that we haven't synced yet? If we write 2 files but only buffer their writes then this will only sync one of the 2 right?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll merge this anyway as it is harmless

Comment thread src/tapes/rolling_tape.rs
redsh4de and others added 2 commits September 11, 2026 22:41
Co-authored-by: Boog900 <boog900@tutanota.com>
remove the upfront file creation, the file will be created when we actually start writing

simplify the previous-file sync in writer
@Boog900
Boog900 merged commit 04562f4 into Cuprate:main Sep 12, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants