schelk

Restore block-device datasets to a pristine baseline using dm-era tracking.

50|5|Updated Jan 18, 2026
One-click install
npx skills add https://github.com/tempoxyz/schelk --skill schelk
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: schelk
Source: https://github.com/tempoxyz/schelk/tree/main/docs
Command: npx skills add https://github.com/tempoxyz/schelk --skill schelk

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

schelk eliminates slow, measurement-distorting benchmark reset cycles by restoring large on-disk datasets to a pristine baseline quickly.

Core Features & Use Cases

  • Fast rollback without CoW/overlay distortion: runs benchmarks directly on an ext4 scratch device while using dm-era metadata to track changed blocks, then restores only those blocks from a pristine virgin device.
  • Safe, stateful workflow for benchmarking loops: supports init-new, init-from, mount, recover, restore, promote, status, and full-recover for post-crash or post-reboot safety.
  • Guardrails to prevent data loss and incorrect results: includes Linux-only enforcement, root-only operation, integrity checks (e.g., superblock hash), and destructive-action confirmations for destructive commands.

Quick Start

Use the schelk skill to set up virgin and scratch block devices and then run: schedule init-new, mount, run your benchmark workload, and recover back to the baseline.

Frequently Asked Questions about schelk

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reset block-device benchmarks without copy-on-write overhead skewing storage performance?

Block-device benchmark resets use dm-era metadata on a ramdisk to track changed blocks on an ext4 scratch device, copying only written blocks back from a pristine virgin device to restore a known baseline in seconds.

What is dm-era used for in Linux ext4 storage performance benchmarking?

dm-era tracks incremental block changes on an ext4 scratch device during benchmark writes, enabling fast recovery by restoring only the modified blocks rather than recopying the entire dataset.

How do I set up a repeatable benchmarking loop on a Linux block device?

Use the init-new, mount, and recover workflow: initialize virgin and scratch devices, mount the scratch target, run workloads, then recover changed blocks to restore the pristine baseline for the next run.

Can I recover dm-era benchmark state after a reboot or stale metadata?

Yes, a full-recover workflow handles post-crash or post-reboot safety by validating integrity checks and restoring the ext4 block-device baseline from stale dm-era tracking states.

What are the requirements for restoring block-device datasets to a pristine baseline?

Restoring block-device baselines requires Linux, root privileges, a virgin device, a scratch device, and dm-era metadata on a ramdisk, alongside destructive-operation confirmations to prevent data loss.

Why does block-device benchmarking require a virgin device and a scratch device?

A virgin device stores the pristine baseline untouched, while a scratch device receives benchmark writes, allowing dm-era to track and recover only modified blocks without CoW overlay distortion.