Storage · XB Field Notes

LVM snapshots capture a block device in time

Mon, 10 Apr 2028 00:00:00 +0000

A classic LVM snapshot uses a copy-on-write exception store attached to an origin logical volume. lvcreate -s -L 5G -n snap vg/data requests a 5 GiB store, subject to allocation granularity and available volume-group space. It avoids copying the whole origin at creation, but does not guarantee zero work or instant completion. Thin snapshots use a different shared-pool mechanism.

The exception store must cover distinct changed chunks and metadata for the entire retention window, including writes during backup. A burst can consume it earlier than a quiet-workload estimate predicts. If a classic store fills, the snapshot becomes invalid and reads fail. Monitor validity and growth early enough to extend or finish the backup; a nominal percentage alone is not a recovery plan.

An exception store, not a copy

The origin uses the snapshot-origin target, while snapshot combines unchanged origin chunks with preserved exceptions. Writes to the snapshot itself go to its COW device. Repeated changes to an already-excepted chunk do not require another original copy for that snapshot. The earlier million-write, sixteen-chunk, fifteen-exception result has no recovered trace; touching all sixteen distinct chunks would require sixteen data exceptions, plus metadata.

lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size exposes type, state and usage. swi-a-s--- is illustrative, not one universal attribute string; the fifth character I means invalid snapshot. Alert thresholds must leave room for observed write rates and response time. lvextend needs available VG extents. lvchange --monitor y enables monitoring, not guaranteed extension: dmeventd, configured autoextend policy and free capacity are also required.

Exhaustion is invalidation

Kernel documentation says an exhausted classic COW store is disabled and returns errors. The lvcreate manual’s twenty-percent-of-origin command is an example, not a general sizing recommendation. Account for chunk granularity, metadata, workload bursts and the full backup duration. Increasing capacity before exhaustion preserves a valid snapshot; an invalid recovery point must not be treated as complete merely because its LV still exists.

Origin writes normally continue when a classic snapshot overflows, but this does not guarantee that unrelated origin or storage failures cannot occur. An invalid snapshot is unusable as the recovery point; it did exist and may have supplied an earlier verified backup. Do not confuse current snapshot validity with the separate integrity of a copy already completed elsewhere.

Merging, and why thin changes the failure

lvconvert --merge vg/snap merges a persistent COW snapshot back into its origin and consumes the snapshot. It starts immediately when both LVs are closed; otherwise LVM defers it until an activation when both are closed. The origin may serve I/O after merging begins, with affected writes deferred as required. This is not a guarantee of interruption-free rollback, and newer origin data can be discarded.

A thin snapshot shares data and metadata capacity with other thin LVs instead of owning a separately sized COW store. Data exhaustion may queue writes or return errors according to policy; metadata exhaustion is another failure mode. Such failures can affect multiple volumes and filesystems, but do not imply instant destruction of every volume. Monitor both pool percentages, policy and extension capacity.

When it breaks

A block snapshot is not automatically an application-consistent backup. Filesystem and database buffers, logging and data spread across volumes require coordinated handling and recovery. During copying, check snapshot validity and propagate read failures; verify the resulting contents and a restore. A successful command exit or mount alone does not establish completeness, and this review performed no LVM creation, exhaustion, extension or merge experiment.

Before a merge, identify open users of both origin and snapshot and plan the application outage or activation boundary. Rehearse on disposable volumes and keep an independent backup. Size for all distinct changes across the retention window, not just its busiest hour. Confirm the actual resulting volume and restored application state; do not infer success solely from declining allocation counters.

LVM keeps changed chunks — mechanism diagram.

Check it quickly

The unchanged lines below remain held. They contain environment-specific names and require authorized LVM access; lvextend changes allocation, so this is not a read-only diagnostic block. No device-mapper, kernel, volume or mount operation was executed:

lvs -a -o lv_name,vg_name,lv_attr,origin,data_percent,lv_size
lvs -a -o lv_name,data_percent,metadata_percent vg/thinpool
dmsetup status vg-snap
lvextend -L +2G vg/snap

Classic snapshot Data% and its validity state differ from a thin pool’s Data% and Meta%. dmsetup status output is target-specific: normal snapshot allocation need not fall, while snapshot-merge allocation can decrease toward its metadata remainder. The final line neither proves free VG capacity nor revives an invalid snapshot. A separately held complete exercise must bind targets and verify each claimed transition.

Sources

lvcreate(8), documents -s/--snapshot, COW versus thin snapshots and illustrative sizing commands, checked 2026-09-16.
lvs(8), defines the lv_attr state characters including invalid snapshot, checked 2026-09-16.
Device-mapper snapshot support, the exception store, invalidation and lvconvert --merge behaviour, checked 2026-09-16.
lvmthin(7), thin snapshots, pool exhaustion and automatic extension, checked 2026-09-16.
lvconvert(8), immediate versus deferred merge and open-volume conditions, checked 2026-10-18.
PostgreSQL filesystem backup, consistent snapshot scope, WAL and multi-volume recovery requirements, checked 2026-10-18.

ZFS snapshots give the filesystem a rewind button

Tue, 21 Mar 2028 00:00:00 +0000

A ZFS snapshot preserves a point-in-time dataset view through copy-on-write references instead of a full duplicate of its data. Existing blocks remain available while references need them. Creation still has metadata and synchronization work; neither zero allocation nor completion before a shell redraw is a measured guarantee. This review did not run ZFS or recover the earlier claimed fixture’s raw output.

That makes retained history useful for local recovery, but every snapshot of tank/data remains in the same pool. A failure that makes that pool unavailable can also make its snapshots unavailable. This is a shared failure boundary, not a claim that every controller fault atomically destroys all blocks. Independent backups or replication need their own retention and verified recovery.

A name for one consistent tree

Snapshots atomically capture the dataset’s filesystem state; recursive -r snapshots include descendants at the same instant. Without recursion, child datasets are omitted rather than automatically captured later. Filesystem consistency is not an application checkpoint: database buffers, logs and files outside the selected datasets still require the application’s supported backup or crash-recovery procedure. Coordinate all required datasets before treating the set as recoverable.

Names such as tank/data@daily-2026-09-16 can help retention, alongside creation times, properties and backup records. Naming alone does not prove eligibility for deletion. zfs list -t snapshot -o name,used,refer,creation -s creation inspects snapshots and their accounting; dependencies and holds must also be checked before a pruning decision.

Where the space is, in zfs list -o space

zfs list -o space tank/data selects NAME, AVAIL, USED, USEDSNAP, USEDDS, USEDREFRESERV and USEDCHILD; it does not include REFER. USED decomposes into the four used-by categories, not REFER plus USEDSNAP. REFER is all data accessible through the dataset and can include shared blocks. Snapshot USED measures uniquely referenced space; deleting another snapshot can change it, so individual values do not simply sum to all recoverable space.

The earlier thirty-snapshot, 64 MiB dataset and 2 MiB daily-churn figures lack a recovered ZFS trace. The 60 MiB versus 1920 MiB comparison is illustrative arithmetic, not verified allocation. Metadata, compression, block size, sharing and the exact retention timeline affect actual cost. A recent snapshot may have little unique data while the whole retained set still prevents substantial reclamation.

Holds, diff, and comparing versions

A user hold prevents destruction until released. zfs hold keep tank/data@daily-2026-09-16 sets one; zfs holds tank/data@daily-2026-09-16 inspects it, and zfs release keep tank/data@daily-2026-09-16 releases that tag. Holds can protect an in-progress transfer, but clone-origin dependencies are separate and need not appear as named hold tags. Release only after understanding the dependent operation.

zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 reports changes between the retained versions: created, removed, modified and renamed paths. Filesystem snapshots are mounted on demand beneath .zfs/snapshot/<name>; snapdir=visible exposes that directory in listings. Snapshot access and a destructive dataset rollback are different recovery choices, and neither verifies application correctness by itself.

When it breaks

A successful send/receive into independently protected storage can survive loss of the source pool. The shown incremental transfer requires an existing destination whose latest snapshot matches the source base; a bare incremental stream is not a complete standalone backup. A second pool on the same machine can still share power, controller or administrator risks. Verify received data and a usable restore before claiming protection.

Growing USEDSNAP warrants capacity and retention review, but eighty-percent occupancy is not a universal write-failure threshold. Quotas, reservations and actual pool availability matter. A clone depends on its origin snapshot; deleting that origin or rolling back past newer dependent versions needs deliberate dependency handling. Rollback can discard newer data, and destroying clones is not the only possible recovery strategy.

ZFS history has dependencies — mechanism diagram.

Check it quickly

This unexecuted standalone Bash recipe requires exclusively controlled disposable datasets, existing source snapshots, and a receiver previously seeded from the base. The destination must be unchanged since that base, mounted at the bound path without intervening mounts or symlinks; the hold tag must be unused. Before taking the target snapshot, prepare regular-file probe.txt in the source and keep a trusted external copy at expected. Listing is recursive; transfer covers only tank/data, not descendants.

(
 set -euo pipefail
 src='tank/data'
 dst='backup/data'
 base='daily-2026-09-15'
 next='daily-2026-09-16'
 tag='example-transfer'
 mount='/mnt/zfs-lab/received'
 expected='/mnt/zfs-lab/expected-v2.txt'

 zfs list -r -t snapshot -o name,used,refer,creation -s creation "$src" "$dst"
 zfs list -o name,avail,used,usedsnap,usedds,usedrefreserv,usedchild,refer "$src"
 zfs holds "$src@$base" "$src@$next"
 zfs diff "$src@$base" "$src@$next"

 latest=$(zfs list -H -r -t snapshot -o name -s createtxg "$dst" |
 awk -F@ -v dataset="$dst" '$1 == dataset { last=$0 } END { print last }')
 test "$latest" = "$dst@$base"
 source_guid=$(zfs get -Hp -o value guid "$src@$base")
 target_guid=$(zfs get -Hp -o value guid "$dst@$base")
 test -n "$source_guid"
 test "$source_guid" = "$target_guid"
 target_mount=$(zfs get -H -o value mountpoint "$dst")
 target_mounted=$(zfs get -H -o value mounted "$dst")
 test "$target_mount" = "$mount"
 test "$target_mounted" = yes
 test -f "$expected"
 test ! -L "$expected"

 zfs hold "$tag" "$src@$base" "$src@$next"
 zfs send -i "$src@$base" "$src@$next" | zfs receive "$dst"
 source_guid=$(zfs get -Hp -o value guid "$src@$next")
 target_guid=$(zfs get -Hp -o value guid "$dst@$next")
 test -n "$source_guid"
 test "$source_guid" = "$target_guid"
 test -f "$mount/.zfs/snapshot/$next/probe.txt"
 test ! -L "$mount/.zfs/snapshot/$next/probe.txt"
 cmp -- "$expected" "$mount/.zfs/snapshot/$next/probe.txt"
)

The latest receiver snapshot and base GUID must match; equal names alone are insufficient. Failed checks stop the subshell, and pipefail exposes either transfer failure. Received GUID and fixture-byte comparisons still do not establish a valid application restore: verify the complete manifest, metadata and application recovery separately. Any holds created remain after failure or success; after validation and dependency review, release only this exercise’s tag with zfs release example-transfer tank/data@daily-2026-09-15 tank/data@daily-2026-09-16. No force rollback or automatic cleanup is included.

Sources

zfs-snapshot(8), snapshot creation semantics and recursive snapshots, checked 2026-09-16.
zfs-list(8), the space column set and separate REFER property, checked 2026-09-16.
zfs-hold(8), holds, zfs holds, and the EBUSY returned by destroy, checked 2026-09-16.
zfs-send(8), incremental send streams and their base-snapshot requirements, checked 2026-09-16.
zfsprops(7), used-by decomposition, shared references, quotas and reservations, checked 2026-10-18.
zfs-clone(8), clone dependence on its origin snapshot, checked 2026-10-18.
zfs-rollback(8), discarded newer data and dependent clone handling, checked 2026-10-18.
zfs-receive(8), matching destination base for incremental receive, checked 2026-10-18.
PostgreSQL filesystem backup, consistent snapshot scope, WAL and multi-volume recovery requirements, checked 2026-10-18.
ZFS concepts, clone dependency on its origin snapshot and shared storage boundaries, checked 2026-10-18.
zfs-get(8), exact property reads used for GUID and mountpoint checks, checked 2026-10-19.

High-cardinality labels increase stored series before anyone queries them

Mon, 10 Jan 2028 00:00:00 +0000

A Prometheus series is identified by a metric name and its complete label set. Adding customer or request identity to a counter can create many series even when every dashboard immediately sums those identities away. Query aggregation changes the returned result; it does not remove the raw series that were ingested.

Query aggregation reduces returned rows. Accumulating the required route totals at the producer reduces emitted identities. Numbers illustrate the article’s fixed-total fixture; the Prometheus integration was not rerun.

Count observed combinations, not isolated values

One new label value is not automatically one new series across the entire database. It creates a new identity wherever the metric name and other labels form a distinct combination. Multiplying possible value counts gives a Cartesian upper bound for a given metric and target scope; it equals the observed count only when every combination is present. Dependencies between dimensions can make the bound much larger than reality. Actual series count also depends on target labels and metric families.

A route label based on a small set of route templates can be bounded. A full URL containing identifiers and query strings often is not. Customer identifiers, request IDs, arbitrary error messages and timestamps also need deliberate scrutiny. A histogram with multiple bucket series amplifies the impact of each label combination further. Budget from the actual exposition and expected workload rather than one dimension in isolation.

Querying fewer rows does not store fewer rows

An expression summing requests by route can return three results after reading twelve customer-specific series. Those twelve input series still exist. If route totals are the required metric contract, instrumentation can accumulate a route-level counter directly and export three series. That reduces the identities emitted at the source instead of relying on every consumer to hide the extra dimension.

Removing a label during ingestion is not equivalent to this accumulation. Distinct samples can acquire the same identity, and relabeling will not decide how to sum them. Prefer a deliberate instrumentation change or an explicitly defined recording query, understanding that recording adds derived series while retaining raw ones under the storage policy. Preserve detailed correlation in logs or traces when needed, with their own access, retention and cost limits.

Diagnose growth with the right inventory

The TSDB status API exposes head statistics, including series counts by metric name. Those values help identify large families but are not a complete cost model. Sample interval, label length, churn, chunk handling, retention and storage behavior also matter. Do not translate a small fixture’s series reduction into an identical percentage reduction in production memory or disk.

Instant query counts and head-series statistics can differ when some head series no longer have recent selectable samples. Historical blocks introduce another scope again. Record the measurement time and population when comparing reports. A release that changes label values may create churn while older identities remain in storage, so a graph returning fewer current results does not prove that all earlier cost has vanished.

A per-scrape sample limit is a guardrail, not selective aggregation. If the limit is exceeded after metric relabeling, Prometheus treats the scrape as failed. That can remove useful visibility along with the excess data. Set budgets using representative exposition and alert on scrape failure; do not assume the collector quietly keeps an affordable subset.

When it breaks

A newly added unbounded label can increase ingestion and memory pressure until scrapes or queries suffer. Start by identifying the metric family and instrumentation change, then stop unnecessary new identities at their source or through a carefully reviewed sample filter. Immediately deleting historical data is not a universal recovery requirement, and changing retention does not remove every resource cost instantly.

A subtler failure is a successful aggregation that makes a dashboard look small while the raw metric continues growing. Review both exported identities and query output. Give new dimensions an expected value range, useful consumer and owner. For counters, preserve reset handling when creating production rate queries; a static sum used to compare fixture totals is not a replacement for rate-before-aggregation semantics.

Check it quickly

Save this as cardinality.py and run python3 cardinality.py. It requires Docker and Prometheus 3.5.1, downloading the image if needed. A local text endpoint exports three routes with four synthetic customer identities each, plus independently accumulated route totals. The real server scrapes those samples and exposes both query and TSDB statistics.

import http.client
import io
import json
import subprocess
import time
import uuid
from urllib.parse import quote

name = "xbcatm-monitoring-" + uuid.uuid4().hex[:12]


class ResponseSocket:
 def __init__(self, data):
 self.data = data

 def makefile(self, mode):
 return io.BytesIO(self.data)


def request(method, path, body="", content_type="application/json"):
 body = body.encode()
 headers = (f"{method} {path} HTTP/1.1\r\nHost: 127.0.0.1:{port}\r\n"
 f"Connection: close\r\nContent-Type: {content_type}\r\n"
 f"Content-Length: {len(body)}\r\n\r\n").encode()
 result = subprocess.run(
 ["docker", "exec", "-i", name, "/bin/nc", "-w", "3", "127.0.0.1", str(port)],
 input=headers + body, capture_output=True, timeout=5,
 )
 if result.returncode:
 raise RuntimeError(result.stderr.decode())
 response = http.client.HTTPResponse(ResponseSocket(result.stdout))
 response.begin()
 return response.status, response.read().decode()


def get_json(path):
 status, body = request("GET", path)
 assert status == 200, (status, body)
 return json.loads(body)


def eventually(check):
 for attempt in range(150):
 try:
 value = check()
 if value:
 return value
 except (RuntimeError, AssertionError, http.client.HTTPException):
 pass
 time.sleep(0.1)
 raise AssertionError("Expected local server state did not appear")


def query(expression):
 response = get_json("/api/v1/query?query=" + quote(expression, safe=""))
 assert response["status"] == "success"
 return response["data"]["result"]


def value(expression):
 result = query(expression)
 assert len(result) == 1, (expression, result)
 return float(result[0]["value"][1])

port = 9090
# Requires Docker and the Prometheus 3.5.1 image.
script = r"""set -eu
mkdir -p /tmp/www /tmp/targets
cat > /tmp/prom.yml <<'PROM_CONFIG'
global:
 scrape_interval: 1s
 scrape_timeout: 500ms
scrape_configs:
 - job_name: cardinality
 metrics_path: /metrics.txt
 static_configs:
 - targets: ['127.0.0.1:8080']

PROM_CONFIG
cat > /tmp/www/metrics.txt <<'METRIC_DATA'
# TYPE raw_requests_total counter
# TYPE bounded_requests_total counter
raw_requests_total{route="/orders",customer_id="synthetic-1"} 1
raw_requests_total{route="/orders",customer_id="synthetic-2"} 2
raw_requests_total{route="/orders",customer_id="synthetic-3"} 3
raw_requests_total{route="/orders",customer_id="synthetic-4"} 4
bounded_requests_total{route="/orders"} 10
raw_requests_total{route="/cart",customer_id="synthetic-1"} 1
raw_requests_total{route="/cart",customer_id="synthetic-2"} 2
raw_requests_total{route="/cart",customer_id="synthetic-3"} 3
raw_requests_total{route="/cart",customer_id="synthetic-4"} 4
bounded_requests_total{route="/cart"} 10
raw_requests_total{route="/search",customer_id="synthetic-1"} 1
raw_requests_total{route="/search",customer_id="synthetic-2"} 2
raw_requests_total{route="/search",customer_id="synthetic-3"} 3
raw_requests_total{route="/search",customer_id="synthetic-4"} 4
bounded_requests_total{route="/search"} 10

METRIC_DATA
/bin/httpd -f -p 127.0.0.1:8080 -h /tmp/www > /tmp/httpd.log 2>&1 &
exec /bin/prometheus --config.file=/tmp/prom.yml --storage.tsdb.path=/tmp/data --web.listen-address=127.0.0.1:9090
"""
try:
 subprocess.run(
 ["docker", "run", "-d", "--rm", "--name", name, "--network", "none",
 "--entrypoint", "/bin/sh", "prom/prometheus:v3.5.1", "-c", script],
 check=True, capture_output=True, text=True, timeout=20,
 )
 eventually(lambda: len(query('raw_requests_total')) == 12)
 assert value('count(raw_requests_total)') == 12
 assert value('count(bounded_requests_total)') == 3
 assert value('sum(raw_requests_total)') == value('sum(bounded_requests_total)') == 30
 raw_by_route = {x["metric"]["route"]: float(x["value"][1])
 for x in query('sum by (route) (raw_requests_total)')}
 bounded_by_route = {x["metric"]["route"]: float(x["value"][1])
 for x in query('bounded_requests_total')}
 assert raw_by_route == bounded_by_route
 statistics = get_json('/api/v1/status/tsdb')["data"]
 counts = {x["name"]: x["value"] for x in statistics["seriesCountByMetricName"]}
 assert counts["raw_requests_total"] == 12 and counts["bounded_requests_total"] == 3
 print(json.dumps({"raw_series": 12, "bounded_series": 3, "snapshot_total": 30,
 "per_route": raw_by_route, "tsdb_counts_confirmed": True}, indent=2))
finally:
 subprocess.run(["docker", "rm", "-f", name],
 stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

The assertions confirm twelve raw series, three bounded series, and a total of thirty in both representations. Each route totals ten. After query aggregation, the TSDB still reports twelve raw series, demonstrating that a smaller result has not erased its inputs. The isolated container uses no external network, host mounts or published ports and is removed on exit. This validates identities and arithmetic, not a production capacity benchmark.

The operational fixture is unchanged here and was not rerun in this review. Its expected outputs and earlier observations remain distinct from current execution evidence.

Sources

Prometheus: data model, series identity is the metric name plus its label set, checked 2026-10-15.
Prometheus: metric and label naming, bounded dimensions and high-cardinality label guidance, checked 2026-10-15.
Prometheus: storage, head data, blocks and retention costs, checked 2026-10-15.
Prometheus: HTTP API, head-series statistics by metric name, checked 2026-10-15.
Prometheus: configuration, per-scrape sample limits and relabeling collision boundaries, checked 2026-10-15.

A checkpoint flushes dirty buffers to disk

Thu, 06 Jan 2028 00:00:00 +0000

A checkpoint establishes a starting point for PostgreSQL crash recovery. It synchronizes the data-file changes required for that checkpoint and records the corresponding recovery information. WAL must reach durable storage before dependent data pages are written. This ordering allows committed work to survive without forcing every modified table page to disk at each commit, while recovery can replay later changes when necessary.

When it breaks

A checkpoint is not a transaction commit. Data pages can contain versions written by transactions that remain uncommitted; visibility and transaction status still determine which rows readers can see. Checkpoint completion does not make those writes visible or turn a raw copy of changing database files into a valid base backup. Concurrent activity can also dirty pages again, so completion does not mean the buffer pool stays completely clean.

WAL retention has other constraints. max_wal_size is a soft target associated with automatic checkpoint scheduling, not a hard disk-usage limit. Archive failure and replication-slot retention can keep WAL beyond it. min_wal_size concerns recycling a reserve of WAL files, not a second threshold that forces a checkpoint. Misreading those settings can hide a growing archive backlog behind apparently reasonable checkpoint intervals.

Maintenance progress and transaction visibility are separate; final 11 is asserted, while checkpoint comparisons are observations. The two-session runtime remains held.

Check it quickly

Use two fresh psql -X -v ON_ERROR_STOP=1 sessions, A and B, on one quiet, disposable PostgreSQL 18 instance. Use an administrative role for the explicit checkpoint and control-file information. Keep the normal fsync and synchronous-commit settings enabled. In B, create a counter and save the current checkpoint location:

SHOW fsync;
SHOW synchronous_commit;
CREATE SCHEMA checkpoint_demo;
CREATE TABLE checkpoint_demo.items (id integer PRIMARY KEY,n integer);
INSERT INTO checkpoint_demo.items VALUES (1,10);
CREATE TABLE checkpoint_demo.baseline AS
SELECT checkpoint_lsn FROM pg_control_checkpoint();

Both displayed settings should be on. The initial committed counter is ten. In A, change it inside a transaction that remains open:

BEGIN;
UPDATE checkpoint_demo.items SET n=99 WHERE id=1 RETURNING n;

A receives ninety-nine from its own update. Do not commit it. In B, request a checkpoint and inspect what an ordinary reader can see:

CHECKPOINT;
SELECT c.checkpoint_lsn>b.checkpoint_lsn AS checkpoint_advanced,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS visible_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;

The checkpoint location advances, but B still reads ten. The checkpoint has completed while A’s transaction remains undecided. This separates maintenance progress from business commit status. In A, verify its own version is still visible, then discard it:

SELECT n FROM checkpoint_demo.items WHERE id=1;
ROLLBACK;

A reads ninety-nine before rollback. B can now confirm the original ten and perform a normal committed update, with checkpoint locations captured immediately around that operation:

SELECT n FROM checkpoint_demo.items WHERE id=1;
UPDATE checkpoint_demo.baseline
SET checkpoint_lsn=(SELECT checkpoint_lsn FROM pg_control_checkpoint());
UPDATE checkpoint_demo.items SET n=11 WHERE id=1;
SELECT c.checkpoint_lsn=b.checkpoint_lsn AS no_new_checkpoint,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS committed_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;
DO $$ BEGIN
 IF (SELECT n FROM checkpoint_demo.items WHERE id=1) IS DISTINCT FROM 11 THEN
 RAISE EXCEPTION 'checkpoint/transaction boundary result mismatch';
 END IF;
END $$;
DROP SCHEMA checkpoint_demo CASCADE;

The results are ten, followed by a true unchanged-checkpoint comparison and committed value eleven in the tested short schedule. The commit succeeded without requesting another checkpoint. An independently scheduled checkpoint can change that comparison in a busy instance; it does not change the meaning of commit. The assertion checks the final row value, and the fixture is removed afterward.

The original drill reports transaction visibility and checkpoint boundaries; this review did not rerun its two-session schedule. It does not measure recovery duration or simulate a storage device losing acknowledged writes. The durability contract still depends on enabled durability settings and storage that honors synchronization requests. Use separate crash-recovery rehearsals to validate operational recovery time against the workload you actually retain.

Tune against recovery and foreground work

Longer checkpoint intervals can reduce repeated flushing and, with full-page writes enabled, avoid some repeated full-page-image logging. They can also leave more work to replay after a crash. Frequent checkpoints can increase write traffic and latency. Fast local storage alone is not evidence that a larger interval meets a particular recovery objective.

checkpoint_completion_target spreads ordinary checkpoint work across a target fraction of the interval; its usual 0.9 value is a pacing target, not a guarantee against every latency spike. Measure checkpoint duration, requested versus timed checkpoints, WAL growth, and foreground latency together. Compare counter deltas over the same interval, and check stats_reset before attributing a smaller cumulative count to an improvement. In PostgreSQL 18, checkpoint counters and write/sync times are in pg_stat_checkpointer; the background-writer view describes a different component. Investigate repeated WAL-driven requests and retention causes before changing limits, and compare recovery tests before crediting a tuning change as successful.

Sources

PostgreSQL 18 WAL introduction, write-ahead ordering and commit durability without immediate data-file flushing, checked 2026-10-15.
PostgreSQL 18 CHECKPOINT, explicit checkpoint behavior and required privileges, checked 2026-10-15.
PostgreSQL 18 WAL configuration, checkpoint scheduling, pacing, and WAL size semantics, checked 2026-10-15.
PostgreSQL 18 cumulative statistics, the dedicated checkpointer statistics view, checked 2026-10-15.

Partitioning splits one table into many pieces that look like one

Thu, 23 Dec 2027 00:00:00 +0000

Declarative partitioning lets PostgreSQL expose one logical table while storing its rows in separate partitions. The parent routes writes and provides a common query target; the physical partitions hold the data. Its strongest benefits often concern lifecycle management and selective access, but the choice also affects keys, query shape, and operational locking.

A logical parent with physical children

A partitioned parent has no row storage of its own. Each attached partition holds rows permitted by its bounds and can have its own storage parameters, indexes, and maintenance activity. A partitioned index similarly represents a collection of indexes on the physical partitions. Splitting a table does not copy every row into both a parent store and a child store.

Range, list, and hash partitioning divide data according to different rules. Choose the key from real access and retention requirements: monthly event data may fit range partitioning, while other workloads need a different distribution. Declarative partitioning does not by itself distribute those partitions across independent database servers. Local partitions still share the resources and transactional environment of their database.

Keeping the parent name stable can simplify application access, but it does not prove that application code needs no changes. Queries must expose useful partition-key restrictions to benefit from pruning. Keys and foreign-key references may need redesign, and operations that previously addressed a globally unique identifier must retain their intended identity semantics.

The key affects more than routing

A unique or primary-key constraint on a partitioned table must include all partition-key columns, and the partition key must not contain expressions for these constraints. PostgreSQL’s individual partition indexes cannot independently prove arbitrary uniqueness across the other partitions. A composite key on day and id therefore does not promise that id alone is unique across all days.

That distinction matters during a migration from a single table with a global id key. Merely adding the date to the primary key can weaken the original identity contract. Review callers, references, and duplicate-prevention requirements before changing it. The partition key is not just a physical tuning option that can be changed without examining the public data model.

Updating a partition key can move a row to another partition. The destination must exist and accept the row, and indexes and constraints still apply. Such updates are real data changes, not free metadata edits. If retention has already removed the destination range, a late correction may fail even though the logical parent table still exists.

When it breaks

DETACH removes a table from the partition hierarchy while retaining that table and its rows. Queries through the parent stop seeing it, but the detached relation remains available for separate inspection or export. DROP removes the partition’s data as well; detaching is not deletion, and neither operation automatically creates a verified archive or backup.

Partition maintenance takes locks. A plain detach needs a strong lock on the parent, so it can wait behind long-running work and affect concurrent access. PostgreSQL provides a concurrent detach form with different locking and additional restrictions, including that it cannot run inside an explicit transaction block or when the parent has a DEFAULT partition. An interrupted concurrent detach can require FINALIZE before maintenance proceeds. Choose the operation using its actual contract rather than assuming that “metadata operation” means “no blocking.”

Too many partitions can also increase planning and memory costs. There is no universal row-count threshold that makes partitioning worthwhile. Measure representative reads and maintenance operations, create future partitions before writes need them, and define how late-arriving data interacts with retention. A small well-indexed table may remain simpler than a large collection of tiny partitions.

Routing, composite identity, row movement and detach membership are distinct. The source uses ordinary transactional detach; it does not establish concurrent locks or a verified archive.

Check it quickly

Save this as partition-lifecycle.sql and run psql -X -v ON_ERROR_STOP=1 -f partition-lifecycle.sql in a disposable PostgreSQL 18 database. The experiment uses temporary partitions and ordinary transactional detach; final rollback removes the entire fixture.

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE events (day date,id integer,PRIMARY KEY(day,id)) PARTITION BY RANGE(day);
CREATE TEMP TABLE events_sep PARTITION OF events FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
CREATE TEMP TABLE events_oct PARTITION OF events FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');
INSERT INTO events VALUES ('2026-09-15',1),('2026-09-30',2),('2026-10-01',3);
SELECT id,day,tableoid::regclass AS physical_table FROM events ORDER BY id;
DO $$ BEGIN
 CREATE UNIQUE INDEX events_id_only ON events(id);
 RAISE EXCEPTION 'global id uniqueness accepted without partition key';
EXCEPTION WHEN feature_not_supported THEN RAISE NOTICE 'unique key must include partition key';
END $$;
SAVEPOINT id_scope;
INSERT INTO events VALUES ('2026-10-03',1);
SELECT id,day FROM events WHERE id=1 ORDER BY day;
ROLLBACK TO id_scope;
RELEASE id_scope;
UPDATE events SET day='2026-10-02' WHERE id=2;
SELECT id,day,tableoid::regclass AS physical_table FROM events ORDER BY id;
ALTER TABLE events DETACH PARTITION events_sep;
SELECT (SELECT count(*) FROM events) AS attached_rows,(SELECT count(*) FROM events_sep) AS detached_rows;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM events) IS DISTINCT FROM ARRAY[2,3] OR
 (SELECT array_agg(id ORDER BY id) FROM events_sep) IS DISTINCT FROM ARRAY[1] THEN
 RAISE EXCEPTION 'detach changed stored rows';
 END IF;
END $$;
ROLLBACK;

Retained logs show that the PostgreSQL 18.6 standalone SQL adaptation routed ids one and two to September and id three to October. This source review did not repeat that run. Client transport and concurrent detach were not tested. It rejected a parent unique index on id alone. Within a savepoint, a second id one on another day was accepted under the composite primary key; rolling back that savepoint restores the original fixture.

Updating id two’s day moved it to October, as tableoid showed. Detaching September then left two rows visible through the parent and one row in the detached table. Assertions verify the exact identifiers on both sides, proving that detach changed membership without discarding stored data. This validates the lifecycle and key semantics, not production lock duration or a complete archival procedure.

Sources

PostgreSQL table partitioning, physical storage, keys, routing, and partition management, checked 2026-10-15.
PostgreSQL ALTER TABLE, attach and detach behavior and locking restrictions, checked 2026-10-15.

Redis append-only log trades speed for durability

Wed, 17 Nov 2027 00:00:00 +0000

An append-only file records Redis mutations for recovery, but choosing AOF is not the same as promising that no acknowledged write can ever disappear. Durability depends on the fsync policy, effective configuration, storage behavior, and which failure you mean. Start with a recovery objective rather than the reassuring word “log.”

Execution, logging, and acknowledgment

Redis executes commands against its in-memory dataset and then propagates their effects to AOF. This is not a rule that each command must reach disk before memory changes. With appendfsync always, Redis synchronizes appended data before sending replies; commands processed together may share a write and fsync. A lost connection still leaves the client uncertain about an operation whose reply never arrived.

The file is a recovery representation, not a permanent audit trail of every original request. Redis can transform commands for persistence, and rewriting retains the current dataset rather than its entire history. A deleted value is not guaranteed to remain recoverable from a rewritten log.

Choose the synchronization contract

appendfsync everysec schedules synchronization approximately once per second. Its usual tradeoff is roughly one second of exposed writes, not a universal loss bound under arbitrary storage stalls. appendfsync no leaves flushing to the operating system; it means Redis does not request fsync, not that data never reaches disk. Neither policy makes every successful reply evidence of durable storage.

appendfsync always offers a stronger local acknowledgment contract at a latency and throughput cost, but it cannot protect against losing the disk, a faulty storage stack, or deleting the wrong data. Also inspect no-appendfsync-on-rewrite: enabling it suspends normal fsync during background persistence work, weakening durability even when the main policy says always.

Rewriting creates a recoverable file set

Since Redis 7, AOF uses a manifest plus a base file and incremental files. With aof-use-rdb-preamble enabled, the base uses RDB format; later mutations live in incremental AOF files. That base belongs to AOF and is not the independently scheduled dump.rdb snapshot.

BGREWRITEAOF starts or schedules background work; its successful reply does not certify completion. Inspect INFO persistence for the completed rewrite and its status. Copying one conveniently named file, or racing a rewrite while copying the directory, can produce an unusable backup. Preserve a consistent manifest and its referenced active files.

When it breaks

Disk errors, exhausted space, and rewrite failures require monitoring, not merely an appendonly yes setting. Check aof_last_write_status and aof_last_bgrewrite_status alongside disk capacity, rewrite state, and application errors. Background work still consumes I/O and copy-on-write memory; “background” does not mean zero latency impact.

Truncated tails and corruption in the middle have different recovery semantics. Preserve the original artifact before inspection or repair: a repair can discard subsequent commands. AOF also replays application mistakes, so maintain independently retained backups. Do not turn a process-restart demonstration into a claim about power-loss safety, replication acknowledgment, or exactly-once retries.

Recover AOF from its consistent manifest and active base/incremental files. Fsync policy governs acknowledgment, while the source’s SIGKILL/restart check keeps the OS alive and makes no power-loss guarantee.

Check it quickly

Use a POSIX machine with a C compiler, make, curl, tar, and Python 3.10 or newer. This exercise ran on macOS with Redis 8.10.1, redis-py 8.1.0, and Python 3.14.4. The setup builds Redis core with libc and installs the client in a temporary virtual environment.

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

Run the Python block with "$redis_lab/venv/bin/python" in the same shell. It creates a private Unix-socket server, without TCP, scheduled snapshots, or automatic AOF rewrites. AOF uses always and keeps fsync enabled during rewriting. Only the subprocess it creates is killed. Persistence files survive that process restart inside the temporary directory, which is removed after the checks.

from contextlib import contextmanager
import os
from pathlib import Path
import signal
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client, process
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


with TemporaryDirectory(prefix="redis-aof-", dir="/tmp") as directory:
 with instance(directory, aof=True) as (client, process):
 client.set("counter", 0)
 for expected in range(1, 5):
 assert client.incr("counter") == expected
 assert client.hset("profile", mapping={"name": "Ada", "level": "2"}) == 2
 client.set("deleted", "not retained")
 assert client.delete("deleted") == 1
 rewrites = client.info("persistence")["aof_rewrites"]
 assert client.bgrewriteaof()
 deadline = time.monotonic() + 5
 while True:
 state = client.info("persistence")
 if (state["aof_rewrites"] > rewrites
 and not state["aof_rewrite_in_progress"]
 and not state["aof_rewrite_scheduled"]):
 assert state["aof_last_bgrewrite_status"] == "ok"
 break
 assert time.monotonic() < deadline, "AOF rewrite did not finish"
 time.sleep(0.02)
 assert client.incr("counter") == 5
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 assert not (Path(directory) / "dump.rdb").exists()
 print("rewrite completed; a later INCR returned 5; no standalone RDB")
 crash(process)

 aof_dir = Path(directory) / "appendonlydir"
 entries = []
 for line in (aof_dir / "appendonly.aof.manifest").read_text().splitlines():
 parts = line.split()
 entries.append(dict(zip(parts[::2], parts[1::2], strict=True)))
 active = [entry for entry in entries if entry["type"] in {"b", "i"}]
 assert {entry["type"] for entry in active} == {"b", "i"}
 for entry in active:
 assert (aof_dir / entry["file"]).is_file()
 base = next(aof_dir / entry["file"] for entry in active if entry["type"] == "b")
 assert base.read_bytes().startswith(b"REDIS")
 print("manifest references an RDB-format AOF base and an incremental AOF")

 with instance(directory, aof=True) as (client, process):
 assert client.get("counter") == b"5"
 assert client.hgetall("profile") == {b"name": b"Ada", b"level": b"2"}
 assert client.get("deleted") is None
 assert client.dbsize() == 2
 print("after SIGKILL and restart: counter=5, hash restored, deletion retained")

The test waits for an observed successful rewrite, then adds one more increment. After SIGKILL, the manifest references an RDB-format AOF base and incremental data, while no standalone dump.rdb exists. Restarting restores counter five, both hash fields, and the absence of the deleted key. Checking values and types is stronger than counting keys alone.

The manifest inspection is scoped to this fixture’s simple filenames; it is not a general backup parser. SIGKILL skips graceful shutdown but leaves the operating system running, including its filesystem cache. The result proves this local AOF recovery path, not a measured loss window for everysec or no, nor survival of hardware failure.

Sources

Redis persistence, synchronization, multipart AOF, recovery, and backup boundaries, checked 2026-09-08.
Redis BGREWRITEAOF, scheduled work versus completed rewriting, checked 2026-09-08.
Redis INFO, persistence status fields, checked 2026-09-08.
Redis 8.10.1 configuration, fsync policies, rewrite overrides, and AOF file layout, checked 2026-09-08.
Redis 8.10.1 build instructions, core-only build and allocator selection, checked 2026-09-08.

Btrfs snapshots are copy-on-write, not copies

Sun, 14 Nov 2027 00:00:00 +0000

A Btrfs snapshot is a new subvolume with the source’s initial contents, sharing existing file extents rather than duplicating every data block. Creation copies root metadata and may flush dirty source data, so it is not guaranteed to finish in milliseconds. More than two subvolumes or reflinks can reference the same extent; there is no fixed two-reference limit.

Snapshots make local recovery points economical, but their cost includes metadata and blocks retained by later divergence. They share the filesystem’s storage pool with the source, which may span several devices. Keeping many snapshots can retain deleted or overwritten data. A snapshot within that same filesystem is not an independent backup, even when it is read-only.

Shared extents, not copied blocks

Snapshots are subvolumes with their own roots. The example btrfs subvolume snapshot -r "$src" "$snap" requests a read-only snapshot; ordinary snapshots are writable. Read-only status prevents routine changes through that subvolume, not administrator deletion or underlying corruption. Snapshotting is not recursive: nested subvolumes appear as empty stubs, so their contents require separate handling.

When a shared extent changes, copy-on-write preserves the older contents for remaining references. Allocation depends on extent layout, compression, metadata and later snapshots, not simply application bytes written. The earlier APFS clone figures are not Btrfs measurements and have no recovered trace here. They cannot establish zero-cost creation or zero allocation on a repeated Btrfs overwrite.

Where the space actually goes

btrfs filesystem du reports file-extent Total, Exclusive and Set shared values using FIEMAP. Each argument defines its own recursively scanned file set; Set shared counts shared extents referenced by that set, accounting for overlaps, rather than only sharing with other arguments. compsize reports compression-oriented Disk Usage, Uncompressed and Referenced columns, not the same split. Qgroup accounting additionally requires enabled, consistent quotas.

Deleting the source does not release extents still referenced by snapshots or reflinks. Those extents become exclusive only if no other references remain. Subvolume deletion removes the directory first and cleans extents asynchronously; space need not return immediately. df gives filesystem-level capacity, not an attribution of every retained byte to one snapshot.

A restore point is not a replica

A local snapshot can preserve a useful filesystem view without providing application-consistent recovery. A database may need coordinated backup procedures, its logs and recovery after restoration; unsent application buffers are outside the snapshot. Source and snapshot also share underlying failure risks. Local rollback is neither a fixed-time guarantee nor a substitute for testing that the application can restart correctly.

btrfs send generates a stream for btrfs receive on another filesystem. Incremental -p operation relies on a suitable unchanged parent present at both ends; all participating snapshots must be read-only. Separate storage helps only against failures it does not share. Retention, successful receipt and content-verified restoration still matter; more frequent snapshots do not guarantee a fixed reduction in transferred bytes.

When it breaks

When deleting a large directory frees little space, inspect snapshot and reflink references before deleting more data. btrfs filesystem du -s and qgroups provide different accounting views; one Exclusive value need not explain the whole discrepancy. Only remove recovery points after checking retention and send dependencies. Several snapshots can collectively retain blocks that none owns exclusively by itself.

Copy-on-write needs allocation headroom for data and metadata. Review both with btrfs filesystem usage; unallocated device space and free space inside allocated block groups are different quantities. Neither a universal five-percent reserve nor a fixed order of exhaustion follows from these counters. An allocation failure alone also does not establish that the filesystem became read-only.

Btrfs shared extents — mechanism diagram.

Check it quickly

This limited inspection remains unexecuted. It requires authorized disposable source /mnt/btrfs-lab/data, an existing snapshots parent on the same Btrfs filesystem, tools and permissions. Keep all paths symlink-free and exclusively controlled throughout. An existing destination directory changes where Btrfs creates the snapshot; the guard rejects existing paths, including dangling symlinks. It is not a race-proof lock; stop if exclusive control is unavailable.

(
 set -eu
 src='/mnt/btrfs-lab/data'
 snap='/mnt/btrfs-lab/snapshots/data-2026-09-16'
 if [ -e "$snap" ] || [ -L "$snap" ]; then
 printf '%s\n' 'Refusing an existing snapshot destination.' >&2
 exit 1
 fi
 btrfs subvolume snapshot -r "$src" "$snap"
 btrfs filesystem du -s "$src" "$snap"
 compsize "$snap"
 btrfs filesystem usage "$src"
)

Snapshot inspection now uses the bound destination; reruns refuse it rather than removing it. File-extent counters do not measure total snapshot metadata. Exclusive equalling Total means currently unshared extents, not absence of snapshot history. This is not a divergence or restore test: separately record known fixture bytes, verify both views initially, change only the source, then verify old snapshot bytes and new source bytes. Those storage checks and application recovery remain held.

Sources

btrfs subvolume documentation, subvolume and snapshot semantics including read-only snapshots, checked 2026-09-16.
btrfs filesystem documentation, defines the du Exclusive and Set shared columns used above, checked 2026-09-16.
btrfs qgroup documentation, exclusive and referenced byte accounting per qgroup, checked 2026-09-16.
btrfs send documentation, send-stream generation and read-only incremental-base requirements, checked 2026-09-16.
compsize upstream manual, compression and referenced-size accounting differs from filesystem du, checked 2026-10-18.
PostgreSQL filesystem backup, consistent snapshot scope, WAL and multi-volume recovery requirements, checked 2026-10-18.

An LRU cache evicts the least recently used entry

Fri, 12 Nov 2027 00:00:00 +0000

LRU chooses a victim by recency, not by popularity, age, or business importance. When a bounded cache needs space, an exact least-recently-used policy removes the entry whose last qualifying access occurred longest ago. That rule can exploit temporal locality, but it neither guarantees useful hits nor keeps cached data fresh.

Follow the access order

Imagine a three-entry cache, listed from oldest to newest. Loading A, B, and C produces A–B–C. Reading A moves it to the newest position, producing B–C–A. Loading D then evicts B, leaving C–A–D. A plain insertion-ordered dictionary does not automatically move an entry when it is read.

An implementation must define which operations count as touches. A common exact design combines a lookup table with a doubly linked recency order, supporting efficient lookup, promotion, and removal. Maintaining that order also consumes metadata and turns cache hits into state updates. Concurrent implementations must coordinate those changes.

Exact and sampled policies differ

Redis uses approximate LRU: it samples candidates and maintains a pool of good eviction candidates instead of keeping an exact order of every key. The configurable sample count trades additional CPU work for a closer approximation. It does not promise the exact victim sequence of the small model below or universally constant eviction latency.

Candidate eligibility matters too. Redis allkeys-lru can evict any key, while volatile-lru considers keys with expiration metadata. A TTL is not protection against eviction before its deadline. If no eligible expiring keys exist, a volatile policy behaves like noeviction for memory-pressure decisions.

Capacity is not freshness

A limit of three entries is not a limit of three kilobytes. Values, keys, and bookkeeping have different sizes; a count-bounded cache can still retain large objects. Python’s lru_cache retains references to arguments and results until eviction or clearing. Choose a capacity unit that matches the resource you need to control.

Recency also says nothing about whether a source value changed. Frequently reading an obsolete cached answer can keep it resident indefinitely. Expiration, explicit invalidation, and versioned keys address freshness separately. An eviction rule is neither a consistency protocol nor a backup policy.

When it breaks

A scan through one-time entries can displace a useful working set. Cycling through four distinct keys with capacity three can miss on every access, even though those keys are repeatedly requested. Historical popularity does not reserve space under LRU. LFU, admission filtering, or a different capacity may help particular workloads, but no policy follows automatically from “read-heavy.”

Measure hits, misses, evictions, retained bytes, and miss cost over representative intervals. A high hit ratio can hide expensive misses; an eviction counter alone does not reveal whether victims were useful. Reconstruct the access trace before changing policies.

A cache hit must also be safe to reuse. Avoid memoizing side effects or results that require a fresh mutable object on each call. Python’s lru_cache keeps its internal state coherent across threads, but simultaneous misses may still execute the wrapped function more than once. Thread safety is not duplicate-work suppression.

Touch A, then evict B. Source-based mechanism illustration. Model values and source-reported observations are not a new runtime test.

Check it quickly

Save the block as lru_check.py and run python3 lru_check.py with Python 3.10 or newer. It ran with Python 3.14.4. Only the standard library is used: an OrderedDict models exact recency, and the real functools decorator separately verifies memoization. No Redis server, network requests, or filesystem writes are involved.

from collections import OrderedDict
from functools import lru_cache


def access(cache, key, capacity):
 assert capacity > 0
 hit = key in cache
 evicted = None
 if hit:
 cache.move_to_end(key)
 else:
 cache[key] = key.lower()
 if len(cache) > capacity:
 evicted, _ = cache.popitem(last=False)
 return hit, evicted, tuple(cache)


cache = OrderedDict()
observed = [access(cache, key, 3) for key in "ABCAD"]
assert observed == [
 (False, None, ("A",)),
 (False, None, ("A", "B")),
 (False, None, ("A", "B", "C")),
 (True, None, ("B", "C", "A")),
 (False, "B", ("C", "A", "D")),
]
print("ABCAD: touching A makes B the victim; final oldest -> newest:", tuple(cache))

for key in "XYZ":
 access(cache, key, 3)
assert tuple(cache) == ("X", "Y", "Z")
assert access(cache, "A", 3)[0] is False
print("a one-time XYZ scan displaces the old working set")

cache.clear()
hits = sum(access(cache, key, 3)[0] for key in "ABCD" * 3)
assert hits == 0
print("capacity 3, repeated ABCD: 0 hits in 12 accesses")

origin = {"A": 1, "B": 2, "C": 3}
loads = []


@lru_cache(maxsize=2)
def read(key):
 loads.append(key)
 return origin[key]


assert [read(key) for key in "ABACB"] == [1, 2, 1, 3, 2]
assert loads == ["A", "B", "C", "B"]
assert tuple(read.cache_info()) == (1, 4, 2, 2)
print("functools trace:", read.cache_info(), "origin reads:", loads)
origin["B"] = 20
assert read("B") == 2
read.cache_clear()
assert read("B") == 20
assert tuple(read.cache_info()) == (0, 1, 2, 1)
print("a recent cached B stays stale until explicit invalidation")

The first assertion checks every intermediate order, not just the final size: touching A makes B the victim. A subsequent XYZ scan displaces the former working set. The repeated ABCD trace then produces zero hits in twelve accesses with capacity three.

The decorated function reads an in-memory origin mapping. Its ABACB trace records one hit, four misses, and two retained entries; the recorded origin reads identify which calls actually recomputed. Changing the origin’s B from two to twenty leaves the cached result at two until cache_clear runs. Clearing also resets the statistics.

These are deterministic correctness checks, not latency or memory benchmarks. They do not exercise Redis sampling, TTL processing, concurrent misses, byte-based capacity, or a production access distribution. Use the measured trace to understand the policy, then validate the actual cache implementation under its own workload.

Sources

Python functools, LRU memoization, cache statistics, references, invalidation, and concurrent-call limits, checked 2026-09-08.
Python collections, OrderedDict reordering and endpoint removal, checked 2026-09-08.
Redis key eviction, approximate LRU, sampling, and candidate eligibility, checked 2026-09-08.

LSM trees trade foreground writes for later merging

Tue, 02 Nov 2027 00:00:00 +0000

An LSM tree moves work from scattered updates toward buffered writes and later merging. That is a design trade, not a promise that every disk operation becomes sequential or that random writes always beat a B-tree. The useful question is whether foreground writes, background compaction, reads, and retained versions fit the same resource budget.

Buffering changes when work happens

RocksDB normally inserts writes into a memtable and can record them in a write-ahead log. WAL enablement and synchronization are separate durability choices; merely using an LSM layout does not promise that every acknowledged write survives power loss. A full memtable becomes an immutable sorted table. Flushes create files in level zero, while application writes continue through other available buffers.

With leveled compaction, level-zero files may overlap in key range. Deeper levels normally form one sorted run per level, divided among multiple nonoverlapping SST files. This is not one file per level. File boundaries help a lookup select candidates; compaction merges overlapping ranges into replacement files. Dynamic level sizing can also leave intermediate levels empty, so a fixed picture of every level being populated is misleading.

Reads still pay for versions

A key may have older values in several runs. A lookup must choose the visible version, and a deletion marker must stop an older value from reappearing. Bloom filters can reject candidate files that definitely lack the key; a positive answer still requires further checking. They can help successful overall lookups by skipping unrelated files before reaching the file containing the answer. They are not exclusively useful for absent keys.

Compaction rewrites data to reduce this search and space burden. Leveled and universal policies commonly trade write, read, and space amplification differently, but workload, compression, caching, and configuration determine the result. Compare like accounting: SST bytes written, WAL bytes, device writes, and logical application bytes are different quantities. A ratio without its numerator and denominator cannot size storage bandwidth reliably.

When it breaks

When flush or compaction work cannot keep up, immutable buffers and level-zero files can accumulate, reads can become more expensive, and the engine may slow or stop foreground writes. A nonzero historical stall counter alone does not diagnose today’s bottleneck. Inspect recent stall time, pending work, file counts, storage latency, and application throughput together. Raising a threshold may defer pressure while increasing the eventual recovery cost.

Deletes do not instantly reclaim every older value. A tombstone cannot safely disappear while a lower run can still expose the value it hides, or a retained snapshot requires relevant history. Reclaiming space depends on the compaction coverage and version-retention rules. Dividing physical bytes by zero live bytes also produces no finite space-amplification ratio; report absolute retained bytes for an entirely deleted dataset.

Merge versions; keep deletion safe. Source-based mechanism illustration. Model values and source-reported observations are not a new runtime test.

Check it quickly

Save this as lsm_model.py and run Python 3. The standard-library program is an explicit in-memory model of three flushed runs and complete-history compaction. It does not execute RocksDB, create SST files, perform I/O, simulate its scheduler, or measure latency. None of the printed counts should be described as production benchmark results.

from pprint import pprint

# A semantic model: sorted in-memory runs, not RocksDB or a disk benchmark.
runs = [] # newest run first
writes = 0
sequence = 0

def flush(operations):
 global writes, sequence
 memtable = {}
 for key, value in operations:
 sequence += 1
 memtable[key] = (sequence, value)
 run = dict(sorted(memtable.items()))
 runs.insert(0, run)
 writes += len(run)

def get(key, tables):
 for run in tables:
 if key in run:
 return run[key][1] # None is a tombstone: stop searching.
 return None

flush([("a", "one"), ("b", "old")])
flush([("a", "two"), ("c", "three")])
flush([("b", None)])
assert [get(k, runs) for k in "abc"] == ["two", None, "three"]
assert writes == 5 and sequence == 5
# Dropping a tombstone from only the newest run resurrects old b.
unsafe = [{k: v for k, v in runs[0].items() if v[1] is not None}] + runs[1:]
assert get("b", unsafe) == "old"
# Merge ALL history, with no retained snapshots, before dropping tombstones.
latest = {}
for run in reversed(runs):
 latest.update(run)
merged = {k: v for k, v in sorted(latest.items()) if v[1] is not None}
writes += len(merged)
assert [get(k, [merged]) for k in "abc"] == ["two", None, "three"]
assert (len(merged), writes, sequence) == (2, 7, 5)
pprint({"live_keys": list(merged), "logical_operations": sequence,
 "table_records_written": writes, "record_write_ratio": writes / sequence,
 "unsafe_partial_merge_resurrects": get("b", unsafe)})

The first flush stores a and b; the second replaces a and adds c; the third deletes b. Reading across all runs returns the newer a, no b, and c. Deliberately dropping only the newest tombstone resurrects the older b, demonstrating why a locally empty-looking deletion record cannot simply be discarded.

The safe model merge examines every run and assumes no snapshots. It retains two values and writes two more table records, giving seven record writes for five logical operations. This is a record-count ratio of 1.4, not byte-based write amplification: variable value sizes, the WAL, compression, metadata, and intermediate real compactions are absent.

For an actual engine, reproduce representative inserts, updates, deletes, and reads in an isolated database, record options and hardware, then inspect its measured counters. An SQLite timing comparison cannot establish RocksDB behavior, and a backlog bandwidth difference cannot directly predict disk-fill time without a model of retention, reclamation, throttling, and available capacity.

Sources

RocksDB overview, memtables, optional WAL, persistence and compaction, checked 2026-10-15.
RocksDB leveled compaction, sorted runs, files, level sizing and compaction pressure, checked 2026-10-15.
RocksDB Bloom filters, candidate filtering and false positives, checked 2026-10-15.
RocksDB snapshots, version retention during compaction, checked 2026-10-15.

A sparse file separates logical length from allocated blocks

Mon, 11 Oct 2027 00:00:00 +0000

A sparse regular file can have a large logical length while allocating storage for only part of its address range. Reads from holes within that length return zero bytes. File length, byte content, and filesystem allocation are therefore different measurements. Understanding their relationship matters when budgeting virtual disks, copying backups, or deciding whether a zero-filled region actually reserves space for future writes.

Measure length, bytes and allocation separately, then verify the actual copy or reservation contract.

When it breaks

Seeking beyond the end of a file changes the descriptor’s offset, not the file’s length. A later write or an explicit extension can create the intervening zero-reading range. Calling seek alone and reporting that a large sparse file now exists is incorrect. Likewise, a large logical size does not mean the filesystem has reserved enough blocks to fill that file later.

A copy that reads every byte and writes it normally can turn holes into allocated zero-filled ranges. The resulting checksum can match perfectly while its allocation is much larger. Transfer and restore workflows that budget only the source’s current allocated space can therefore run out of capacity despite preserving the logical content correctly.

Hole punching is an intentional data operation. Punching an allocated range makes the corresponding bytes read as zeros while preserving length when requested with KEEP_SIZE. It is not a harmless command to tidy away arbitrary file regions. Preallocation solves a different problem: it reserves filesystem allocation, even though an unwritten allocated range can also read as zeros.

Check it quickly

Save the script as sparse.py and run python3 sparse.py using Python 3.11 or later on a disposable Linux system with an ext4 temporary directory. The recorded run used Linux 6.12.76 and Python 3.11.2. It creates three temporary files and uses about 32 MiB of fully allocated data plus the small sparse allocation:

from pathlib import Path
from tempfile import TemporaryDirectory
import ctypes,hashlib,os

size=16*1024*1024;first=4*1024*1024;second=12*1024*1024
libc=ctypes.CDLL(None,use_errno=True);libc.fallocate.argtypes=[ctypes.c_int,ctypes.c_int,ctypes.c_longlong,ctypes.c_longlong];libc.fallocate.restype=ctypes.c_int
def digest(path):
 with path.open('rb') as handle:return hashlib.file_digest(handle,'sha256').hexdigest()
with TemporaryDirectory(prefix='xbcatm-sparse-') as directory:
 root=Path(directory);path=root/'sparse';fd=os.open(path,os.O_RDWR|os.O_CREAT|os.O_EXCL,0o600)
 try:
 os.lseek(fd,size,os.SEEK_SET);assert os.fstat(fd).st_size==0
 os.ftruncate(fd,size);assert os.fstat(fd).st_size==size and os.fstat(fd).st_blocks==0
 assert os.pread(fd,16,0)==b'\0'*16
 os.pwrite(fd,b'A',first);os.pwrite(fd,b'B',second);os.fsync(fd)
 allocated=os.fstat(fd).st_blocks*512;assert allocated<size
 data_start=os.lseek(fd,0,os.SEEK_DATA);hole_start=os.lseek(fd,data_start,os.SEEK_HOLE)
 assert data_start==first and first<hole_start<=second
 print('seek alone leaves size zero; truncate creates zero-reading holes; sparse size',size,'allocated',allocated)
 print('first SEEK_DATA',data_start,'following SEEK_HOLE',hole_start)
 dense=root/'dense'
 with path.open('rb') as source,dense.open('wb') as target:
 while chunk:=source.read(65536):target.write(chunk)
 target.flush();os.fsync(target.fileno())
 assert digest(path)==digest(dense)
 assert dense.stat().st_blocks*512>=size
 print('explicitly writing all copied bytes preserves content but allocates the zero-filled ranges')
 result=libc.fallocate(fd,0x01|0x02,first,4096) # KEEP_SIZE | PUNCH_HOLE
 assert result==0,os.strerror(ctypes.get_errno())
 os.fsync(fd)
 assert os.fstat(fd).st_size==size and os.pread(fd,1,first)==b'\0'
 assert os.pread(fd,1,second)==b'B' and os.fstat(fd).st_blocks*512<allocated
 print('punching the aligned data range releases its blocks and makes it read zero without changing file length')
 reserved=root/'reserved'
 with reserved.open('w+b') as handle:
 os.posix_fallocate(handle.fileno(),0,size);os.fsync(handle.fileno())
 info=os.fstat(handle.fileno());assert info.st_size==size and info.st_blocks*512>=size
 assert handle.read(16)==b'\0'*16
 print('preallocation reserves blocks even while the newly allocated range reads as zeros')
 finally:os.close(fd)

The fixture first seeks to sixteen MiB in an empty file and verifies that its size remains zero. Truncating to that length then creates a file with sixteen MiB of logical content and no allocated data blocks in this ext4 case. Reading its beginning returns zeros, establishing the difference between moving an offset and extending the file.

Writing one byte at four MiB and another at twelve MiB allocates two small regions. After synchronization, the recorded file length is 16777216 bytes and its reported allocation is 8192 bytes. Linux’s st_blocks count is converted using 512-byte units; treating it as a count of the filesystem’s larger block size would miscalculate the result.

The first SEEK_DATA result is 4194304, and the following SEEK_HOLE result is 4198400 in the recorded run. These describe the ext4 region around the first written byte, not only that byte’s nonzero position. A data extent may contain zeros too, so extent reporting is not a search for nonzero content.

The script explicitly copies all logical bytes through ordinary writes into a second file. Its digest matches the sparse source, but its allocated space covers the full logical length. This controlled dense copy demonstrates the expansion risk without claiming that every modern copy tool or filesystem necessarily materializes holes in the same way.

Next, an aligned punch removes the first allocated data region. The original A byte now reads as zero, the distant B byte remains, length stays unchanged, and allocated blocks decrease. Finally, preallocating the third file reserves space across sixteen MiB while its initial bytes read as zeros. Zero content alone cannot distinguish a hole from reserved allocation.

Budget and preserve the intended representation

Check both logical size and allocated blocks after the actual archive, transfer, and restore path. A sparse-aware option may preserve holes, while compression, reflinks, and filesystem-specific copying can produce other storage relationships. Per-file allocation also should not automatically be interpreted as exclusive physical-device usage when the filesystem shares or compresses extents.

Use the target filesystem’s documented preallocation contract when future allocation must be reserved. A merely truncated virtual image can grow its storage consumption later and fail when the shared pool is full. Capacity planning needs the expected populated size and competing allocations, not just an attractive small allocation measured at creation time.

Treat SEEK_DATA and SEEK_HOLE as filesystem-provided extent information. Implementations are allowed to report holes conservatively, including representing a broader range as data. Verify support and behavior before depending on exact offsets. When punching or copying ranges, preserve the application’s intended bytes first; space savings are useful only when the resulting data and allocation match the operation’s actual purpose.

Sources

lseek(2), seek position, SEEK_DATA/SEEK_HOLE, and filesystem reporting limits, checked 2026-09-12.
truncate(2), extending logical length with zero-reading regions, checked 2026-09-12.
fallocate(2), preallocation and hole punching without changing logical size, checked 2026-09-12.
Linux 6.12 fallocate UAPI, KEEP_SIZE and PUNCH_HOLE flags used by the fixture, checked 2026-09-12.

A PVC gives a Pod durable storage beyond the container

Fri, 13 Aug 2027 00:00:00 +0000

A PersistentVolumeClaim separates storage lifetime from a recreated Pod; it does not guarantee data recovery. A PersistentVolume describes storage, a claim requests it, and controllers arrange binding or provisioning. Recovery still depends on backing storage, usable topology and backups.

Claims and volumes have separate lifetimes. Finalizers can postpone deletion, while reclaim policy controls the released storage. Review both before maintenance: mistakes can cause persistent Terminating states, unintended data loss or retained storage bills.

Protection delays deletion; it does not establish controller health. Retain requires an ownership, backup and provider-procedure decision. Retained diagnostics remain blocked and were not rerun.

The claim, the volume, and the binding

Ordinary matching checks capacity, access modes, storage class, volumeMode, selectors and existing ownership. An unmatched claim can remain Pending; inspect its events and StorageClass rather than assuming a single cause. Binding is not proof of usable topology: explicitly naming a PV can bind despite conflicting node affinity. Scheduling and mounting still have to succeed.

accessModes has no default. ReadWriteOnce permits read-write mounting on one node, potentially by several Pods there; it is not single-Pod exclusivity. ReadWriteOncePod provides that constraint for supported CSI volumes. Access modes alone do not enforce write protection after mounting. Immediate starts binding or provisioning without waiting for a consumer, risking unusable placement for topology-constrained storage. Supported WaitForFirstConsumer provisioning coordinates storage with a consuming Pod’s scheduling constraints before placement completes.

The deletion order and the finalizer

A usual retirement sequence is Pod, claim, then volume. Deleting an in-use claim records deletionTimestamp, but kubernetes.io/pvc-protection can postpone removal. In Kubernetes v1.34.0, the ordinary PVC-reference check counts Pods assigned to a node; an unscheduled Pod reference alone does not hold protection. This is a controller reference check, not a live mount probe. A stuck Terminating claim therefore needs inspection of scheduled consumers, controller progress and other finalizers.

The same protection exists in the other direction. A PersistentVolume carries kubernetes.io/pv-protection, so deleting a volume that is bound to a claim is postponed until it is no longer bound. That ordering delays an accidental deletion; a deletionTimestamp cannot simply be cancelled. This explains why a volume can seem to ignore a delete for as long as its claim exists.

Reclaim policy: Delete or Retain

When the claim is finally gone the volume is released, and the reclaim policy takes over. With a supporting storage plugin, Delete reclaims the PV and backing asset asynchronously; removal is not an atomic or immediate guarantee. Retain keeps the PV object, marks it Released, and deliberately does not make it available for a new claim, because the previous claimant’s data is still on it — reclamation becomes a manual sequence: verify ownership and backups, then deliberately reclaim, reuse or delete storage according to the provider’s procedure.

Dynamically provisioned volumes inherit the policy from their StorageClass, whose default is Delete. Whether that default fits a database depends on retention and recovery requirements. It is easy to overlook: nothing in the PVC or pod spec mentions the policy, so the decision lives in a cluster-scoped object nobody reviewing the workload ever sees.

When it breaks

The classic failure is the claim that will not die. Someone deletes a PVC, sees Terminating, and waits — while a pod somewhere still mounts it, usually a StatefulSet that was never scaled down or a pod stuck on an unreachable node. Nothing errors, nothing times out, and the PVC blocks the storage behind it. Find the pod rather than deleting the finalizer by hand; bypassing protection can permit premature storage deletion while a workload still uses it.

The second failure is the Retain orphan. The claim is gone, the pods are gone, the namespace may be gone, and a Released PV plus its storage asset remain for deliberate reclamation. Retention may be intentional; without inventory alerts it is easy to miss and the volume does not appear in any workload’s list. The inverse mistake is just as quiet: a class whose default Delete policy was never overridden, discovered only when someone tries to recover data that the reclaim already removed.

Check it quickly

Look at both sides of the binding, and at what holds the claim:

kubectl get pvc -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,STATUS:.status.phase,VOLUME:.spec.volumeName,CLASS:.spec.storageClassName
kubectl get pv -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,POLICY:.spec.persistentVolumeReclaimPolicy,CLAIM:.spec.claimRef.name
kubectl get pvc data -o jsonpath='{.metadata.finalizers}{"\n"}'
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.volumes[]?.persistentVolumeClaim.claimName=="data") | "\(.metadata.namespace)/\(.metadata.name)"'

These retained diagnostics were not rerun here. Protection indicates cleanup is pending; it does not prove the controller is healthy or a Pod still exists. The fourth command finds all claims named data across namespaces, so match the target namespace before treating a Pod as a consumer. Released plus Retain calls for an ownership and recovery decision, not automatic deletion; the old claimRef may remain.

Sources

Persistent Volumes, binding, access modes, reclaim policies, Released state and the pvc/pv protection finalizers, checked 2026-10-15.
Storage Classes, dynamic provisioning, reclaimPolicy, and volumeBindingMode, checked 2026-10-15.
Persistent Volumes (v1.34), v1.34 prebinding, access-mode limits and supported reclaim behavior, checked 2026-10-18.
PVC protection implementation, v1.34.0 podUsesPVC node-assignment and explicit-reference checks, checked 2026-10-18.

NFS shares a remote directory over the network

Wed, 23 Jun 2027 00:00:00 +0000

An NFS export combines a server-side filesystem path with client and access policy. On Linux, exportfs maintains /var/lib/nfs/etab from /etc/exports, eligible files under /etc/exports.d, or command-line updates. rpc.mountd is a daemon, not a third configuration file. Its MOUNT service matters to older protocol workflows; NFSv4 does not require that separate service for mounting.

Configuration text can differ from effective exports, but that is one possible cause of refusal, not a diagnosis from appearance alone. Check the intended server, protocol, export policy, identity and filesystem permissions. Also separate server durability from client caching: seeing a write succeed in an application is not by itself proof that the server has committed it to stable storage.

The file and the table

An /etc/exports entry associates a directory with clients and options. /srv/data 10.0.0.0/24(rw,sync,no_subtree_check,root_squash) illustrates one network; further client groups can have their own options. Hostnames, network ranges and netgroups have documented matching rules. exportfs -ra reconciles configured exports, but other exportfs actions or service management can also apply changes; it is not the sole activation mechanism.

showmount -e asks the server’s MNT service for advertised exports. Completeness depends on the implementation, and NFSv4-only servers may not expose that service. It is neither a complete effective-policy dump nor a proof that a client can access a share. The old four-versus-three-entry and NOENT story has no recovered raw test here; a missing export does not promise one universal error code.

What the options actually decide

The default export is read-only unless rw enables writes; filesystem permissions and other controls still apply. sync constrains server replies according to stable-storage requirements, while async permits replies before changes are committed and risks acknowledged data after a crash. Neither option removes client caching or makes every application write a synchronous durable commit. nfs-utils changed its default from async to sync after release 1.0.0.

root_squash maps request uid/gid zero to anonymous IDs; no_root_squash disables that protection. all_squash maps all IDs, and anonuid/anongid select the anonymous values. These do not authenticate a client or make an arbitrary public share safe. subtree_check has security as well as rename-reliability consequences; its default changed to no_subtree_check in nfs-utils 1.1.0. Evaluate the actual exported hierarchy and trust boundary.

Mounting, and the id mapping trap

The illustrative mount -t nfs -o vers=4.2 server:/srv/data /mnt/data requires a server supporting that protocol and an applicable export path. NFSv4 paths are relative to its exported namespace; fsid=0 identifies the export root, not a requirement to expose the host’s entire root filesystem. Hard mounts retry timed-out requests indefinitely; soft mounts can return EIO and risk data corruption. Neither choice proves a particular process state.

With AUTH_SYS, numeric request IDs participate in permission checks; lacking a server-side account name does not automatically squash a nonzero ID. NFSv4 owner-name mapping and stronger authentication introduce additional identity boundaries. Compare id, ls -ln, squash policy and mapping configuration. An owner displayed as 65534 or nobody can reflect deliberate squashing or mapping failure, so it is a symptom rather than a unique diagnosis.

When it breaks

If exports are stale, reconcile the intended configuration including /etc/exports.d and command-line overrides, then inspect the result. exportfs -ra changes server policy and may affect existing access; review it before use. A configuration mismatch is distinct from name resolution, reachability, protocol support or permission failures. Do not apply a policy refresh simply because one client operation failed.

An unavailable server can leave operations waiting and cause serious application disruption. It does not follow that every process touching a hard mount is permanently unkillable. The old thirty-five-second showmount failure is uncorroborated here and does not establish the mounted kernel client’s timeout. intr is ignored after Linux 2.6.25; changing to soft requires weighing data-integrity risk, not merely shortening a wait.

NFS access crosses policy — mechanism diagram.

Check it quickly

The original commands remain held. They mix server checks, a localhost MNT query, a policy mutation and client observations without identifying separate hosts. No NFS service, RPC request, export refresh or mount was exercised:

exportfs -v
showmount -e localhost
exportfs -ra && exportfs -v
mount | grep 'type nfs'
id; ls -ln /mnt/data | head

Compare policy, not printed option order. This offline proposal supports one /srv/data IPv4-network export, using nfs-utils defaults since 1.1.0. It expands omitted defaults, rejects conflicting/unknown options and compares exact paths plus canonical networks. Hostnames, netgroups, wildcards, multiple security flavors and additional records are unsupported, never silently equivalent.

import ipaddress
import re

# A single-export, numeric IPv4-network fixture; not a general exports parser.
def export_policy(text):
 match = re.fullmatch(
 r"(/srv/data)[ \t\n]+([0-9./]+)\(([^()\s]+)\)\n", text)
 if match is None or "/" not in match[2]:
 raise ValueError("incomplete or unsupported export record")
 client = ipaddress.IPv4Network(match[2], strict=True)
 mask = match[2].split("/")[1]
 if mask not in (str(client.prefixlen), str(client.netmask)):
 raise ValueError("noncanonical prefix or unsupported hostmask")
 groups = [
 ("ro", "rw"), ("sync", "async"), ("wdelay", "no_wdelay"),
 ("hide", "nohide"), ("no_subtree_check", "subtree_check"),
 ("secure", "insecure"), ("root_squash", "no_root_squash"),
 ("no_all_squash", "all_squash")]
 defaults = {group[0]: group[0] for group in groups}
 defaults.update(sec="sys", anonuid=65534, anongid=65534)
 owner = {token: group[0] for group in groups for token in group}
 seen = set()
 for token in match[3].split(","):
 if token in owner:
 name, value = owner[token], token
 elif token == "sec=sys":
 name, value = "sec", "sys"
 elif re.fullmatch(r"anon(?:uid|gid)=[0-9]+", token):
 name, raw = token.split("=")
 value = int(raw)
 if not 0 <= value < 2**32 - 1:
 raise ValueError("unsupported anonymous ID")
 else:
 raise ValueError(f"unsupported option: {token}")
 if name in seen:
 raise ValueError(f"duplicate or conflicting option: {name}")
 seen.add(name)
 defaults[name] = value
 return match[1], str(client), defaults

def compare_exports(configured, effective, *, complete, returncode, stderr):
 if (complete is not True or type(returncode) is not int or returncode != 0
 or type(stderr) is not str or stderr != ""):
 raise ValueError("failed, partial or unverified capture")
 if export_policy(configured) != export_policy(effective):
 raise ValueError("export path, client network or policy differs")

# Fabricated complete inputs exercise comparison only; no NFS command runs.
configured = "/srv/data 10.0.0.0/24(rw,sync,no_subtree_check,root_squash)\n"
effective = ("/srv/data\n\t10.0.0.0/255.255.255.0"
 "(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,"
 "root_squash,no_all_squash)\n")
compare_exports(configured, effective, complete=True, returncode=0, stderr="")
print("synthetic policy comparison passed; live NFS remains untested")

Expect only a synthetic comparison message. For live evidence, require complete successful captures from the same identified server, including all configuration inputs and intended overrides; never manufacture completeness from filtered output. Unsupported configurations require separate review. No capture, RPC, mount or access test ran. Localhost discovery and ownership listings prove no access; the complete authorized server/client exercise and any policy change remain held.

Sources

exports(5), export syntax, squash options, sync/async and the subtree_check defaults, checked 2026-09-16.
exportfs(8), the master export table in /var/lib/nfs/etab and how exportfs maintains it, checked 2026-09-16.
nfs(5), mount options including hard/soft, timeo and the obsolescence of intr, checked 2026-09-16.
showmount(8), querying the server’s export list from a client, checked 2026-09-16.

Two ways Redis keeps data safe

Tue, 15 Jun 2027 00:00:00 +0000

RDB and AOF preserve different representations of Redis state. Choosing between them starts with two questions: how much recent data may be lost, and how long recovery may take? A persistence setting alone answers neither. You need a recoverable artifact, an understood acknowledgment policy, and a restore procedure tested against actual values.

The historical source exercise restores different exact values from RDB-only and enabled AOF. AOF uses its own file set; no new execution or power-loss proof is claimed.

A snapshot captures a point, not an interval guarantee

An RDB file is a compact point-in-time dataset. BGSAVE forks a child that writes a temporary file and replaces the previous snapshot when complete. The parent continues serving requests, but forking, copy-on-write memory, and disk work still have costs. SAVE instead writes synchronously and blocks other clients; reserve it here for the tiny isolated exercise.

A rule such as save 60 1000 requires both elapsed time and a change threshold. It does not promise a new snapshot every sixty seconds regardless of activity, nor successful completion on schedule. Recovery exposure follows the age of a usable snapshot, including missed or failed saves. Monitor successful saves and their results, not just the configured interval.

AOF changes the recovery representation

AOF records mutations and synchronizes them according to appendfsync. everysec normally exposes roughly the most recent second, not a strict loss bound; no delegates flushing to the operating system. always normally synchronizes before replies, at additional cost. With no-appendfsync-on-rewrite yes, Redis skips main-process AOF fsync during BGSAVE or BGREWRITEAOF, weakening both always and everysec. The pinned configuration defaults this exception to no. These policies do not protect against losing the storage device or guarantee that a promoted replica contains every locally persisted write.

Modern AOF uses a manifest, a base, and incremental files. Its base can be RDB-formatted, so “AOF always replays a huge textual history” is misleading. Rewriting removes unnecessary historical operations. File size, startup time, rewrite overhead, and latency must be measured for your dataset rather than inferred from the format’s name.

Running both is not an automatic merge

With ordinary startup settings and AOF enabled, Redis loads AOF rather than independently loading dump.rdb and replaying a separate log on top. The RDB-formatted base inside AOF is part of that file set. An independently retained RDB remains useful for backup and deliberate recovery, but it does not magically fill holes in incomplete AOF artifacts.

Do not switch an existing RDB deployment by merely editing appendonly and restarting. Follow Redis’s documented live conversion procedure, wait for successful initial AOF creation, and persist the configuration. The two cases below start with separate empty directories; they are not a migration recipe for an existing database.

When it breaks

A successful BGSAVE request is not a successful completed snapshot. Failed storage writes, unavailable fork resources, or inadequate disk space can leave the usable recovery point old. Inspect INFO persistence, error logs, and resource headroom. Background persistence can also worsen tail latency even while Redis remains responsive.

Neither file format is an independent backup if its only copy shares the server’s failure domain. Retain consistent copies outside that machine and test their restore. AOF can faithfully persist an accidental deletion; snapshots can already contain the same mistake. Retention history and application validation matter as much as a boot that accepts connections.

Check it quickly

Use a POSIX environment with a C compiler, make, curl, tar, and Python 3.10 or newer. The original exercise reports macOS with Redis 8.10.1, redis-py 8.1.0, and Python 3.14.4; this review did not rerun it. Build only Redis core with libc and install the client in the temporary virtual environment.

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

Run the Python block using "$redis_lab/venv/bin/python" in the same shell. Each case creates its own Unix-socket server, with no TCP listener or scheduled snapshots. Both explicitly save a tiny snapshot; only the second enables AOF with always and no fsync suppression during rewriting. SIGKILL targets only the created subprocess. Its files stay available for restart, then the temporary directory is removed.

from contextlib import contextmanager
import os
from pathlib import Path
import signal
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client, process
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


for aof in (False, True):
 with TemporaryDirectory(prefix="redis-restore-", dir="/tmp") as directory:
 with instance(directory, aof) as (client, process):
 assert client.set("version", "snapshot")
 assert client.incr("counter") == 1
 assert client.save()
 snapshot = (Path(directory) / "dump.rdb").read_bytes()
 assert snapshot.startswith(b"REDIS")
 assert client.set("version", "after-snapshot")
 assert client.set("later", "present")
 assert client.incr("counter") == 2
 if aof:
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 crash(process)

 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 with instance(directory, aof) as (client, process):
 expected = ([b"after-snapshot", b"present", b"2"] if aof
 else [b"snapshot", None, b"1"])
 assert client.mget("version", "later", "counter") == expected
 assert client.dbsize() == (3 if aof else 2)
 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 print("RDB + AOF" if aof else "RDB only", expected)
print("an unchanged standalone RDB does not override enabled AOF recovery")

RDB-only recovers version snapshot, no later key, and counter one. The AOF case recovers version after-snapshot, the later key, and counter two. In both cases, the standalone RDB bytes remain unchanged across the crash and checked restart. The counter is deliberately incremented without an initial SET: replaying both increments over the snapshot would incorrectly produce three.

These assertions compare recovered state, not just whether Redis starts. SIGKILL bypasses graceful shutdown but does not crash the operating system or discard its cache. The experiment establishes snapshot boundaries and ordinary AOF startup selection, not power-loss survival, backup transport integrity, replica failover behavior, or production recovery time. Define those separate acceptance tests before making a stronger promise.

Sources

Redis persistence, snapshots, AOF startup selection, live conversion, and backups, checked 2026-09-08.
Redis SAVE, synchronous snapshot behavior and blocking cost, checked 2026-09-08.
Redis BGSAVE, background saving and request acceptance, checked 2026-09-08.
Redis INFO, persistence progress and result fields, checked 2026-09-08.
Redis 8.10.1 configuration, snapshot triggers and AOF policy, checked 2026-09-08.
Redis 8.10.1 build instructions, core-only build and allocator selection, checked 2026-09-08.

UNLOGGED table contents trade crash recovery for less WAL

Mon, 24 May 2027 00:00:00 +0000

An unlogged PostgreSQL table keeps normal SQL transaction behavior while giving up crash recovery for its contents. It is useful for reproducible staging data, but a committed row is not guaranteed to survive a server crash. The distinction is between clean operation and recovery after an unclean shutdown, not between ordinary queries and every restart.

What bypasses WAL

The table’s data changes and those of its indexes are not written to the write-ahead log. Catalog changes still need WAL, and the database may produce WAL for other work in the same transaction. Calling an unlogged workload “zero WAL” therefore overstates the feature. Its pages also occupy storage and require normal buffer management; UNLOGGED does not mean an in-memory table.

Transactions, snapshots, constraints, and rollback still apply while the server runs. A rejected statement or a disconnected application does not automatically erase previously committed rows. A crashed backend can, however, cause the server to restart other processes and perform recovery. Avoid classifying incidents solely as “application” or “infrastructure”: determine whether PostgreSQL actually entered crash recovery.

Restart and replication boundaries

A clean shutdown preserves unlogged contents for the next start. PostgreSQL’s fast shutdown rolls back active transactions and shuts down cleanly; its immediate shutdown interrupts processes without that cleanup. The latter requires recovery, during which unlogged relations are reset. Their definitions survive, but previously committed rows do not. Normal maintenance must not be described as inevitably deleting them, nor should one successful clean restart be offered as evidence of crash safety.

Physical standbys do not receive the unlogged contents. While recovery is active, querying such a relation raises an error; it does not successfully return an empty result. After promotion, the relation can be read but has no replicated rows to recover. A failover runbook must repopulate it before consumers rely on it. Sharing a schema definition across nodes is different from replicating the table’s data.

A logged table cannot have a foreign key referencing an unlogged table. PostgreSQL rejects that definition because durable references cannot safely depend on rows that may disappear during recovery. The experiment checks this restriction instead of suggesting that ordinary durable child rows survive with silently broken references.

When it breaks

An ingestion pipeline may acknowledge a file once its rows reach an unlogged staging table, then delete the only source copy. A crash makes the acknowledgment irreversible data loss. Keep the source until the durable destination commits, and make the rebuild process identify exactly which input version it needs. Deduplication and checkpoints must belong to the durable part of that contract.

A reporting service can also fail when routed to a standby or started immediately after promotion. Empty-table detection alone misses the standby error, while blindly retrying cannot manufacture missing contents. Handle rebuilding as an explicit service state with admission checks. Test rebuild duration, upstream availability, and validation of the completed dataset; a script that merely creates an empty table is not recovery.

UNLOGGED restart boundaries — mechanism diagram.

Check it quickly

Save the Bash block as unlogged.sh. It uses PostgreSQL 18 command-line tools as a non-root user. The image must already be available locally; its major-version tag is mutable. This invocation publishes no ports and mounts no host data. No database or container command was run in this review:

docker run --rm --network none --user postgres --entrypoint bash -i \
 postgres:18-alpine < unlogged.sh

#!/usr/bin/env bash
set -euo pipefail
pg_lab=$(mktemp -d /tmp/unlogged-lab.XXXXXX)
cleanup() {
 for cluster in standby primary; do
 if [ -f "$pg_lab/$cluster/postmaster.pid" ]; then
 pg_ctl -D "$pg_lab/$cluster" -m immediate -w stop >/dev/null
 fi
 done
 rm -rf -- "$pg_lab"
}
trap cleanup EXIT
primary() { psql -X -h "$pg_lab" -p 55432 -d postgres -v ON_ERROR_STOP=1 "$@"; }
standby() { psql -X -h "$pg_lab" -p 55433 -d postgres -v ON_ERROR_STOP=1 "$@"; }
start_primary() {
 pg_ctl -D "$pg_lab/primary" -l "$pg_lab/primary.log" \
 -o "-k $pg_lab -p 55432 -c listen_addresses=''" -w start >/dev/null
}
initdb -D "$pg_lab/primary" --no-locale --encoding=UTF8 --auth=trust >/dev/null
start_primary
primary <<'SQL'
CREATE TABLE durable (id integer PRIMARY KEY);
CREATE UNLOGGED TABLE scratch (id integer PRIMARY KEY);
INSERT INTO durable VALUES (1);
INSERT INTO scratch VALUES (1);
BEGIN;
INSERT INTO scratch VALUES (2);
ROLLBACK;
DO $$
BEGIN
 EXECUTE 'CREATE TABLE durable_ref (id integer REFERENCES scratch(id))';
 RAISE EXCEPTION 'a logged table unexpectedly referenced an unlogged table';
EXCEPTION WHEN invalid_table_definition THEN
 RAISE NOTICE 'logged-to-unlogged foreign key rejected';
END $$;
SQL
counts='SELECT (SELECT count(*) FROM durable), (SELECT count(*) FROM scratch)'
test "$(primary -Atc "$counts")" = '1|1'
pg_ctl -D "$pg_lab/primary" -m fast -w stop >/dev/null
start_primary
test "$(primary -Atc "$counts")" = '1|1'
printf 'clean restart: 1|1\n'
pg_basebackup -h "$pg_lab" -p 55432 -D "$pg_lab/standby" -R -X stream -c fast
pg_ctl -D "$pg_lab/standby" -l "$pg_lab/standby.log" \
 -o "-k $pg_lab -p 55433 -c listen_addresses=''" -w start >/dev/null
test "$(standby -Atc 'SELECT pg_is_in_recovery()')" = t
test "$(standby -Atc 'SELECT count(*) FROM durable')" = 1
if standby -Atc 'SELECT count(*) FROM scratch' 2>"$pg_lab/read-error"; then
 echo 'unlogged read unexpectedly succeeded on standby' >&2
 exit 1
fi
grep -F 'cannot access temporary or unlogged relations during recovery' "$pg_lab/read-error"
pg_ctl -D "$pg_lab/standby" -w promote >/dev/null
test "$(standby -Atc "$counts")" = '1|0'
printf 'promoted standby: 1|0\n'
pg_ctl -D "$pg_lab/primary" -m immediate -w stop >/dev/null
start_primary
test "$(primary -Atc "$counts")" = '1|0'
printf 'crash recovery: 1|0\n'
primary -Atc 'SHOW server_version'
echo 'PASS: rollback, foreign key restriction, clean restart, standby, promotion, crash'

The primary and standby use separate Unix sockets inside one temporary directory. The trap attempts to stop these experimental clusters and remove their files; failure or interruption can leave resources behind. The deliberate immediate shutdown affects the disposable primary, never an existing database. The historical article reports PostgreSQL 18.6 results, without a recovered raw log here: rollback and clean restart leave counts 1|1; the recovery-mode standby rejects the scratch-table query. Promotion and primary crash recovery each produce 1|0. The exact error text is checked with the cluster’s C locale.

These reported observations illustrate lifecycle and constraint behavior, not a throughput improvement or a power-loss guarantee for every filesystem. Benchmark the real workload separately, including rebuild cost. Keep WAL and durability settings enabled for the durable destination; disabling them would invalidate the comparison.

Sources

PostgreSQL CREATE TABLE, unlogged contents and associated indexes, checked 2026-09-10.
PostgreSQL WAL introduction, recovery and durability roles, checked 2026-09-10.
PostgreSQL pg_ctl, clean and immediate shutdown modes, checked 2026-09-10.
PostgreSQL 18 table commands source, foreign-key persistence restrictions in the version-18 branch, checked 2026-10-18.
PostgreSQL 18 planner catalog source, unlogged relation access prohibition during recovery, checked 2026-10-18.

Bucket versioning and lifecycles manage cost

Sat, 08 May 2027 00:00:00 +0000

S3 Versioning retains multiple versions under one key, making many accidental overwrites and ordinary deletes recoverable while the required version still exists. It does not protect against every deletion or provide an independent backup by itself. Retention, permissions, encryption-key availability, and restoration procedures determine whether the saved history can actually recover the application.

Distinguish versioning states

In a versioning-enabled bucket, a PUT creates a new version ID and preserves earlier data versions. Each version stores the whole object, not merely its changed bytes. Repeatedly overwriting a large object therefore has a different storage profile from a block-level incremental snapshot, even when the visible key count stays constant.

An object that predates enablement keeps its null version ID. New versioned writes do not overwrite that null version. Once enabled, a bucket cannot return to the never-versioned state, although versioning can be suspended. Under suspension, subsequent writes use the null-version slot and can replace an existing null version. Specify which state applies before describing overwrite safety.

Null is a real version identifier, not a guarantee of permanent retention. A null version that becomes noncurrent can be subject to noncurrent expiration. It can also be explicitly targeted for deletion when authorized. A listing containing null therefore does not prove that old data is exempt from lifecycle cleanup.

A delete marker changes visibility

An ordinary DELETE without a version ID in an enabled bucket creates a delete marker. When that marker is current, a versionless GET normally returns 404; explicitly requesting a delete-marker version returns 405. Earlier data remains available by its data-version ID, subject to access, storage-class, and encryption requirements.

Delete markers have no object payload but are not free zero-byte storage entries: S3 charges for the key-name bytes they store. Removing the specific current marker exposes the preceding version, which could itself be another marker. Alternatively, copying an explicit earlier data version creates a new current data version while preserving history. A marker cannot be copied as if it were object data.

Deleting a particular data version is a different, permanent operation. Versioning alone cannot restore that deleted version. MFA Delete, when configured, adds authentication for permanent version deletion and changes to versioning state; it is not automatically active whenever versioning is enabled. AWS does not support using MFA Delete with lifecycle configurations.

Lifecycle expresses a retention tradeoff

Current-version Expiration and NoncurrentVersionExpiration do different jobs. In an enabled bucket, expiring current data generally creates a marker and makes that data noncurrent. Noncurrent expiration permanently removes eligible older data versions. Eligibility uses time since becoming noncurrent, and optional retained-version counts add another condition. It is not simply the object’s original upload age.

Lifecycle execution is asynchronous. A thirty-day rule is not proof that exactly thirty versions remain at every instant. Rule filters, write frequency, retained-count settings, replication status, and Object Lock can affect what qualifies. Transitions to colder storage retain data with different storage, retrieval, and minimum-duration costs; calculate those costs against the actual object sizes and recovery needs.

When it breaks

Growing noncurrent bytes can raise costs while ordinary listings appear stable. Inspect version inventory and lifecycle scope rather than expecting a fixed version-to-key ratio to diagnose every case. A bucket does not need to be physically “full” for this to become expensive, and lifecycle is not a hard spending cap or the only possible retention control.

Overaggressive expiration creates the opposite problem: the required recovery version is permanently removed. Validate retention against the longest plausible detection delay and restore requirements. HEAD can inspect metadata but does not download and validate object contents; a successful metadata request alone is not a completed restoration test.

Version visibility — mechanism diagram.

Check it quickly

Run this Python 3 model with assertions enabled. Retained historical executions cover these exact model bytes; this source review did not rerun them. It models an enabled bucket’s version stack entirely in memory, including a preexisting null data version. No AWS account, credentials, or remote object is used. Marker storage billing, real timestamps, permissions, lifecycle scheduling, and concurrent writes are deliberately outside the model.

versions = [("null", b"old"), ("v1", b"new")]
marker = ("d1", None)
versions.append(marker)
def get_current():
 payload = versions[-1][1]
 return (404, None) if payload is None else (200, payload)
assert get_current() == (404, None)
assert sum(len(data) for _, data in versions if data is not None) == 6
versions.remove(marker)
assert get_current() == (200, b"new")
print("remove current marker: previous data visible")
versions.append(("d2", None))
# Copy an explicit data version to create a new current version.
old = next(data for identifier, data in versions if identifier == "null")
versions.append(("v2", old))
assert get_current() == (200, b"old")
assert any(identifier == "d2" for identifier, _ in versions)
print("copy explicit data version: new current version; history retained")
# Noncurrent null versions are not inherently protected from deletion.
versions[:] = [entry for entry in versions if entry[0] != "null"]
assert get_current() == (200, b"old")
print("remove old null version: current copy remains")

The three outputs distinguish exposing a previous version, copying explicit historical data, and removing a noncurrent null version. Stored payload bytes remain through marker creation; this does not count the marker’s billable key bytes. For real recovery, inspect the exact key across paginated data-version and delete-marker listings, select an explicit data version, retrieve it, and validate its contents before changing production state.

Sources

AWS S3 versioning, how versioning and the null version work, checked 2026-09-16.
AWS S3 delete markers, what a delete marker does and how to undo it, checked 2026-09-16.
AWS S3 lifecycle management, current and noncurrent expiration and transition rules, checked 2026-09-16.
AWS expiring objects, eligibility, permanent noncurrent deletion and asynchronous execution, checked 2026-10-15.
AWS MFA Delete, optional protection and lifecycle constraints, checked 2026-10-15.
AWS restoring previous versions, explicit-version copying and restoration, checked 2026-10-15.

Redis bitmaps flip bits instead of storing numbers

Thu, 29 Apr 2027 00:00:00 +0000

A Redis bitmap is a string interpreted as individual bits, not a separate key type. It is useful for dense yes/no membership such as daily activity. Ten million contiguous flags need 1,250,000 payload bytes, but that estimate excludes keys, object metadata, allocation overhead, and any mapping from business identifiers to bit positions.

Define the offset contract

SETBIT writes zero or one at a zero-based offset and returns the previous bit. Setting an already-set bit again does not increase membership. Offset zero is the most significant bit of the first byte; offset eight starts the second byte. Reading the same key with GET returns its underlying bytes, which need not be valid text.

GETBIT returns zero for a missing key or an offset beyond the current string without expanding it. Zero therefore does not distinguish an explicitly inactive user from an unrecorded one. Decide whether those states may share a representation. SETBIT and GETBIT require a string value and reject a hash rather than converting its fields into bits; BITOP instead writes a new string at its destination.

Memory follows the highest written offset, not the number of ones. Writing offset n requires at least floor(n / 8) + 1 payload bytes, even when the requested value is zero. Clearing that bit later does not shorten the string. Sparse external identifiers can therefore create a huge allocation for almost no membership. Validate the offset range and use a stable, suitably dense mapping. SETBIT requires offsets below 2^32, giving a maximum 512 MiB string. That protocol ceiling is not a sensible per-request allocation budget; enforce a much smaller application limit where appropriate.

Count and combine deliberately

BITCOUNT scans all bytes by default. Its optional start and end arguments are inclusive byte positions unless BIT is specified; that modifier is available from Redis 7.0. Changing units changes the selected interval, not the representation stored at the key. The command returns a population count, not the highest occupied identifier.

BITOP OR combines membership, while AND computes intersection. Shorter inputs and missing keys behave as zero-padded inputs up to the longest input length. The destination is overwritten with a new string; an existing destination expiration is removed. Derived results need their own deliberate lifetime policy, and recomputing them does not preserve a previously attached deadline.

When it breaks

BITCOUNT, BITPOS, and BITOP can scan substantial data. Optimized bit operations do not make full-bitmap work constant-time, and extending a string must allocate the intervening space. Evaluate offset span, query frequency, result lifetimes, and peak allocation together. A tiny number of active users says little about the resource cost of a sparse bitmap.

BITPOS returns an absolute bit offset even when searching a subrange. Searching for zero without an explicit end can return the first position beyond an all-one string, treating the right side as zero-padded. With both bounds specified, no matching bit in that interval returns -1. That difference matters when the bitmap represents a fixed-capacity resource pool.

Finding a zero is not reserving it. Two callers can read the same free position before either changes it. A separate BITPOS and SETBIT sequence is not one atomic claim, and ignoring SETBIT’s old-value result can double-assign a slot. Likewise, OR-ing two day keys is only meaningful when both use the same identifier mapping.

Membership count and allocated span are different quantities. The source’s distant zero consumes one MiB of payload. BIT range units require Redis 7.0+; BITOP results need a deliberate lifetime.

Check it quickly

The original exercise reports macOS, Python 3.14.4, Redis 8.10.1, and redis-py 8.1.0; this review did not rerun it. Use POSIX, a C compiler, make, curl, tar, and Python 3.10+. Setup builds Redis core with libc and installs the client in a temporary virtual environment.

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

Run the Python block with "$redis_lab/venv/bin/python" in the same shell. It uses its own Redis Unix socket under /tmp, disables TCP and persistence, and removes only its runtime directory after stopping its process. Downloading dependencies requires network access. The largest bitmap in this experiment has one MiB of payload; it does not allocate the enormous example offsets discussed above.

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


with instance() as client:
 assert client.getbit("missing", 100) == 0
 assert client.exists("missing") == 0
 assert client.setbit("active", 0, 1) == 0
 assert client.setbit("active", 2, 1) == 0
 assert client.setbit("active", 2, 1) == 1
 assert client.type("active") == b"string"
 assert client.get("active") == b"\xa0"
 assert client.bitcount("active") == 2
 print("offset zero is the high bit; repeated SETBIT returns old 1 without adding membership")

 highest = 8 * 1024 * 1024 - 1
 assert client.setbit("sparse", highest, 0) == 0
 assert client.strlen("sparse") == 1024 * 1024
 assert client.bitcount("sparse") == 0
 assert client.setbit("sparse", highest, 1) == 0
 assert client.setbit("sparse", highest, 0) == 1
 assert client.strlen("sparse") == 1024 * 1024
 print("writing a distant zero allocates 1048576 payload bytes; clearing does not shrink")

 client.set("range", b"\x80\x01")
 assert client.bitcount("range", 0, 1) == 2
 assert client.bitcount("range", 0, 1, mode="BIT") == 1
 assert client.bitpos("range", 1, 1, 1) == 15
 client.set("full", b"\xff")
 assert client.bitpos("full", 0) == 8
 assert client.bitpos("full", 0, 0, 0) == -1
 print("ranges default to bytes; BIT changes units; BITPOS returns absolute bit offsets")

 client.set("other", b"\x50\x01")
 client.set("union", b"obsolete", px=60000)
 assert client.bitop("OR", "union", "active", "other") == 2
 assert client.get("union") == b"\xf0\x01"
 assert client.bitcount("union") == 5
 assert client.ttl("union") == -1
 assert client.bitop("AND", "intersection", "active", "other") == 2
 assert client.get("intersection") == b"\x00\x00"
 print("BITOP zero-pads shorter inputs; OR has 5 flags; destination TTL is removed")

 client.hset("hash", "field", b"value")
 try:
 client.setbit("hash", 0, 1)
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("a hash is not converted into a bitmap")
 assert client.hget("hash", "field") == b"value"
 print("bitmap commands reject a hash without converting or replacing it")

Bits zero and two produce byte 0xa0 and count two. Writing a distant zero still creates 1,048,576 payload bytes; toggling and clearing it leaves that length unchanged. Byte-range counting and bit-range counting return two and one respectively, while the bounded BITPOS result remains an absolute offset.

An all-one byte yields position eight for an unbounded zero search but -1 for a bounded search. OR produces five flags across two bytes and removes the destination TTL; AND produces two zero bytes. Wrong-type access leaves the hash intact. These results verify representation and command semantics, not total process memory, concurrent allocation correctness, or production throughput.

Sources

Redis SETBIT, previous-bit replies and string growth, checked 2026-09-08.
Redis GETBIT, missing-key and out-of-range reads, checked 2026-09-08.
Redis BITCOUNT, population counts and byte/bit ranges, checked 2026-09-08.
Redis BITPOS, absolute offsets and bounded zero searches, checked 2026-09-08.
Redis BITOP, output strings, zero-padding, and operation cost, checked 2026-09-08.
Redis 8.10.1 build instructions, core-only compilation and allocator selection, checked 2026-09-08.

Object and block storage expose different update contracts

Wed, 17 Mar 2027 00:00:00 +0000

Block storage exposes addressable blocks through a device interface. Object storage exposes named objects through an API. Neither label alone specifies durability, consistency, sharing, or price. Start with the application’s required operations, then check the particular service’s contract. A filesystem, database, or compatibility layer can add behavior, but it cannot make every underlying interface interchangeable.

Compare the actual operations

A block volume can be formatted with a filesystem or used directly by software that manages its own layout. The service does not necessarily supply a filesystem. Small overwrites are possible without replacing the whole volume, but safe shared access still needs coordination. Attaching one volume to multiple machines does not turn an ordinary single-host filesystem into a clustered filesystem. Database recovery also depends on write ordering and durability guarantees above the block interface.

An object is addressed within a bucket or another service-defined namespace. Ordinary S3 general-purpose bucket writes replace an entire object; reads can request byte ranges, so “object storage always reads everything” is wrong. Multipart upload assembles a completed object from uploaded parts; it is not a general filesystem’s random-write contract. Specialized products can offer additional append or update operations. Check the selected bucket type and API rather than treating one simple model as a universal rule.

Object storage commonly suits media, exports, and backup artifacts accessed by many clients. Block storage commonly suits database files and virtual-machine disks. These are workload patterns, not exclusive categories: databases can be designed around object storage, and shared filesystems can sit above block devices. Measure request sizes, concurrency, recovery behavior, and total request and transfer charges before choosing.

When it breaks

Do not assume object storage is eventually consistent. Amazon S3 documents strong read-after-write consistency for object PUTs and DELETEs and corresponding reads and listings. A client retaining an old downloaded value can still be stale, but that is not evidence that a fresh service read returns an obsolete value. CDN caches, cross-region replication, and multi-object application updates introduce separate boundaries that need their own guarantees.

Successful S3 PUT does not expose a partially uploaded object. A failed or ambiguous request requires checking the actual result, not inventing a truncated replacement. Atomic replacement of one object also does not prevent lost updates: two clients can read the same version and replace it independently. Conditional requests compare a validator before accepting an update. The model’s integer generation is synthetic; S3 If-Match uses an ETag, not that counter or a version ID. Use the service’s documented conditions; an ETag is not universally a content checksum or a transaction spanning several keys.

Lifecycle deletion and version retention need deliberate recovery tests. Enabling versioning is not the same as maintaining an independent backup, and retaining a local version number is not the same as preserving old payloads. Small-object workloads can be dominated by request overhead even when stored bytes are inexpensive. A mount adapter that accepts a database filename also needs the database’s locking, ordering, and failure semantics before it is a suitable home.

Two update contracts — mechanism diagram.

Check it quickly

Save this as storage_semantics.py and run python3 storage_semantics.py with Python 3.9 or newer. It is a standalone in-memory API model using synthetic bytes. No service, filesystem durability, network latency, or billing behavior is exercised.

"""In-memory API model, not an implementation of a storage service."""
class BlockVolume:
 def __init__(self, data):
 self.data = bytearray(data)
 def write(self, offset, chunk):
 if offset < 0 or offset + len(chunk) > len(self.data):
 raise ValueError("write outside fixed volume")
 self.data[offset:offset + len(chunk)] = chunk

class ObjectStore:
 def __init__(self):
 self.current = {}
 def put(self, key, data, expected=None):
 old = self.current.get(key)
 version = old[1] if old else 0
 if expected is not None and expected != version:
 raise ValueError("version conflict")
 self.current[key] = (bytes(data), version + 1)
 return version + 1
 def get(self, key):
 return self.current[key]

block = BlockVolume(b"ABCDEF")
block.write(2, b"XX")
assert block.data == b"ABXXEF"
try:
 block.write(5, b"too long")
except ValueError:
 pass
else:
 raise AssertionError("out-of-range write accepted")
assert block.data == b"ABXXEF"
store = ObjectStore()
assert store.put("report", b"ABCDEF", expected=0) == 1
cached = store.get("report")
assert store.put("report", b"XYZ", expected=1) == 2
assert store.get("report") == (b"XYZ", 2)
assert cached == (b"ABCDEF", 1)
try:
 store.put("report", b"stale overwrite", expected=cached[1])
except ValueError:
 pass
else:
 raise AssertionError("stale conditional update accepted")
assert store.get("report") == (b"XYZ", 2)
assert store.get("report")[0][1:3] == b"YZ"
print("PASS: bounded overwrite; complete replacement; cached copy differs; stale condition rejected")

The block starts with six bytes. Writing two bytes preserves its neighbors, while an out-of-range write is rejected without changing the volume. The object starts at version one and is completely replaced by the three-byte value at version two. A fresh get immediately returns that replacement. The separately retained tuple still contains version one because the application kept a copy.

The conditional update using that old version fails, and the final assertion confirms that the current object remains unchanged. Slicing the retrieved bytes illustrates a selected range only; it is not a network Range-request test. The PASS line proves these explicit model rules. It does not prove a provider’s implementation, concurrency control, historical-version retention, crash atomicity, or recoverability. Before deployment, repeat the relevant operations against the chosen service with its real SDK and failure handling.

Sources

Amazon S3 data model, object operations and strong consistency, checked 2026-10-15.
S3 PutObject, complete-object writes and conditional requests, checked 2026-10-15.
Amazon EBS, block volumes and application-managed filesystems, checked 2026-10-15.

Disk schedulers order I/O to move the head efficiently

Tue, 09 Mar 2027 00:00:00 +0000

blk-mq provides CPU- or node-local software staging queues and hardware dispatch queues. Scheduling and merging can occur before dispatch, while driver and device behavior also affect service. Software submission order does not guarantee completion order. A scheduler can influence how competing requests enter the device without controlling every later decision in the storage stack.

On rotating media, request locality can reduce head movement. Flash lacks a mechanical seek penalty, but merging, concurrency, queueing and arbitration still affect performance. Efficient ordering and fair service answer different questions, and neither determines a universal scheduler ranking. Choose from the schedulers actually available for the device and kernel, then measure the relevant workload.

The head is the budget

At 7200 RPM, half a revolution is about 4.17 ms, an idealized average rotational wait. Transfer and seek costs depend on the device and workload. The original text reported 2000 requests, 67,907,411 versus 99,977 tracks, and 91 versus 231 IOPS, but supplied neither the generating fixture nor retained measurements. Those figures remain unverified source claims and must not be presented as measured Linux scheduler results.

Sorting an invented set of track positions can illustrate less head travel, but it cannot establish an IOPS gain without a validated device model or measurement. The previously reported seek percentages and approximately 40 ms NVMe total have the same missing-evidence limitation. A drawing of a shorter path is therefore qualitative, not a latency prediction.

What each scheduler is for

none adds no scheduler reordering; it does not promise a global first-come completion order. mq-deadline combines sector ordering with expiry checks between bounded batches. These policies guide dispatch rather than guarantee an end-to-end completion deadline. kyber throttles requests toward read and synchronous-write latency targets; a target is not proof every request meets it.

bfq provides weight-based service and low-latency heuristics, with configuration-dependent bandwidth or time sharing. Idling can help service guarantees but can reduce throughput on internally queued devices. Kernel support and actual settings matter. Read the active scheduler from the bracketed name in /sys/block//queue/scheduler; changing it is an operational action requiring an authorized device and reversible test plan.

Fairness is a different question from order

A 90/10 issue mix does not establish a guaranteed service share or wait position. The reported 0.099, 1901 and 0.5 values have no retained fixture here. Equal weights in a simplified continuously backlogged model may illustrate sharing, but real outcomes depend on demand, request sizes, priorities and scheduler settings. Compare service received and application latency separately from request arrival counts.

For either media type, test latency, throughput and isolation under representative contention. cgroup io.max delays I/O when configured BPS or IOPS limits are reached and permits temporary bursts; it is not conditional on choosing BFQ. Weight control depends on the active implementation and configuration; BFQ has io.bfq.weight, while io.weight can use the I/O cost controller. A ceiling and a relative share are different controls.

When it breaks

A rotational device using none is a reason to inspect the workload, not proof of a bug. High utilization, low IOPS and high await can have several causes. await includes queueing and service, while near-100% utilization can indicate saturation for a serial device and is less informative for parallel hardware. Confirm topology, request pattern and competing work before attributing delays to seeking.

A bulk job can worsen interactive tail latency even when averages look acceptable. Scheduler policies or cgroup limits may help, but no single name establishes application-level protection. Compare percentiles and useful throughput before and after a controlled change. Idling, queue depth and device-internal scheduling interact; the rotational flag alone does not select a universally correct setting.

Queue ordering, weighted service and io.max ceilings are distinct; the original numerical claims remain unverified.

Check it quickly

Start with this unexecuted read-only inspection of one explicitly selected whole device. Set DEVICE only after reviewing its topology and scope. It rejects path-like names, checks required readable attributes, and reports absent optional tunables. This first block does not change policy.

(
 : "${DEVICE:?Set DEVICE to the reviewed whole-device name}"
 case "$DEVICE" in
 ''|[!A-Za-z]*|*[!A-Za-z0-9_-]*|ALL) printf 'Invalid device name\n' >&2; exit 2 ;;
 esac
 queue="/sys/block/$DEVICE/queue"
 [ -d "$queue" ] || { printf 'No such whole-device queue\n' >&2; exit 1; }
 for field in rotational scheduler; do
 [ -r "$queue/$field" ] || { printf 'Missing: %s\n' "$field" >&2; exit 1; }
 value=$(cat "$queue/$field") || exit 1
 printf '%s=%s\n' "$field" "$value"
 done
 for field in read_expire fifo_batch; do
 if [ -r "$queue/iosched/$field" ]; then
 value=$(cat "$queue/iosched/$field") || exit 1
 printf '%s=%s\n' "$field" "$value"
 else
 printf '%s: unavailable for the active scheduler\n' "$field"
 fi
 done
 LC_ALL=C iostat -x -y -t "$DEVICE" 2 5
)

The bracketed name is current; absent iosched fields can be normal. -y excludes since-boot statistics. Preserve errors and confirm the selected device row.

Save this helper as scheduler_exercise.py. Only on an explicitly authorized, exclusively controlled disposable test device, set EXPECTED_CURRENT and REQUESTED from the observed choices, and ACK_DEVICE to DISPOSABLE: followed by DEVICE. Python 3.9+, writable scheduler access and sysstat are prerequisites. This temporarily changes policy:

"""Unexecuted proposal: temporary policy change on an exclusively controlled test device."""
import json
import re
import signal
import subprocess
import sys
from pathlib import Path


def device_name(value):
 if not re.fullmatch(r"[A-Za-z][A-Za-z0-9_-]*", value) or value == "ALL":
 raise ValueError("use one named whole device, not a path, option, number or ALL")
 return value


def scheduler_state(path):
 tokens = path.read_text().split()
 active = [s[1:-1] for s in tokens if re.fullmatch(r"\[[A-Za-z0-9_-]+\]", s)]
 if len(active) != 1 or not tokens:
 raise ValueError("scheduler state must have exactly one bracketed choice")
 if any(not re.fullmatch(r"(?:[A-Za-z0-9_-]+|\[[A-Za-z0-9_-]+\])", s) for s in tokens):
 raise ValueError("unexpected scheduler state")
 available = [s.strip("[]") for s in tokens]
 if len(set(available)) != len(available):
 raise ValueError("duplicate scheduler choices")
 return active[0], available


def exercise(path, device, expected, requested, run=subprocess.run, emit=print):
 original, available = scheduler_state(path)
 if original != expected or requested not in available or requested == original:
 raise ValueError("current/requested scheduler does not match the reviewed plan")
 emit(json.dumps({"device": device, "original": original, "requested": requested}), flush=True)
 primary_error = restore_error = None
 attempted = False
 try:
 if scheduler_state(path) != (original, available):
 raise ValueError("scheduler state changed before the test")
 attempted = True # even a failed write may have changed state
 path.write_text(requested + "\n")
 if scheduler_state(path)[0] != requested:
 raise RuntimeError("requested scheduler was not activated")
 result = run(["iostat", "-x", "-y", "-t", device, "2", "5"], check=False)
 if result.returncode != 0:
 raise RuntimeError(f"iostat exited with status {result.returncode}")
 except BaseException as error:
 primary_error = f"{type(error).__name__}: {error}"
 finally:
 if attempted:
 try:
 if original not in scheduler_state(path)[1]:
 raise RuntimeError("original scheduler is no longer available")
 path.write_text(original + "\n")
 if scheduler_state(path)[0] != original:
 raise RuntimeError("original scheduler was not restored")
 except BaseException as error:
 restore_error = f"{type(error).__name__}: {error}"
 emit(json.dumps({"primary_error": primary_error, "restore_error": restore_error,
 "restored": attempted and restore_error is None}), flush=True)
 # Report both errors; restoration failure never hides the primary failure.
 return (1 if primary_error else 0) + (2 if restore_error else 0)


def main(args):
 if len(args) != 4:
 raise ValueError("usage: scheduler_exercise.py DEVICE EXPECTED_CURRENT REQUESTED DISPOSABLE:DEVICE")
 device, expected, requested, acknowledgement = args
 device = device_name(device)
 if acknowledgement != "DISPOSABLE:" + device:
 raise ValueError("explicit disposable-device acknowledgement required")
 path = Path("/sys/block") / device / "queue/scheduler"
 return exercise(path, device, expected, requested)


if __name__ == "__main__":
 def interrupted(number, frame):
 raise InterruptedError(f"received signal {number}; attempting restoration")
 signal.signal(signal.SIGINT, interrupted)
 signal.signal(signal.SIGTERM, interrupted)
 try:
 sys.exit(main(sys.argv[1:]))
 except (OSError, ValueError) as error:
 sys.exit(f"Scheduler test refused: {error}")

python3 scheduler_exercise.py "${DEVICE:?}" "${EXPECTED_CURRENT:?}" \
 "${REQUESTED:?}" "${ACK_DEVICE:?}"

The helper records the original, verifies activation, captures intervals, then separately restores and verifies the original. Exit statuses are 0 for success, 1 for primary failure, 2 for restoration failure, and 3 for both; the JSON retains both errors. Do not ignore a restore error. SIGINT/SIGTERM request cleanup, but SIGKILL, repeated interruption or host failure can prevent it. Retain the original for manual recovery. This is a reversible policy exercise, not performance or fairness evidence; numerical claims and actual execution remain held.

Sources

Switching Scheduler, the scheduler names, sysfs paths and how to change them, checked 2026-09-16.
Multi-Queue Block IO Queueing Mechanism (blk-mq), software staging queues versus hardware dispatch queues, checked 2026-09-16.
BFQ (Budget Fair Queueing), proportional-share behaviour, cgroup support and the idling trade-off, checked 2026-09-16.
Kyber I/O scheduler tunables, the read and write latency targets Kyber throttles against, checked 2026-09-16.
Linux deadline tunables, correction reference, checked 2026-10-18.
Linux cgroup v2 I/O controls, correction reference, checked 2026-10-18.
iostat manual, correction reference, checked 2026-10-18.
sysstat upstream iostat manual, -y omits the since-boot report and -t timestamps interval reports, checked 2026-10-19.
Python signals, bounded identity or controlled-operation contract, checked 2026-10-19.
sysstat iostat option parser, bounded identity or controlled-operation contract, checked 2026-10-19.

A stale replication slot holds WAL back

Mon, 19 Oct 2026 00:00:00 +0000

A PostgreSQL replication slot records retention requirements for a consumer. Once the slot has reserved a WAL position, losing the consumer’s connection does not automatically release that position. The primary may keep generating log while the slot’s requirement remains unchanged. The operational risk is retained storage and an increasingly expensive catch-up or rebuild decision. Slot usability depends on retained WAL availability and the configured invalidation rules.

When it breaks

Not every newly created physical slot immediately holds WAL. Without immediate reservation, restart_lsn can remain null until the slot is first used. An inactive flag alone therefore does not quantify retention. Inspect the slot type, reserved position, availability status, and consumer ownership together. For logical slots, confirmed_flush_lsn describes acknowledged consumer progress; it is not a replacement for understanding the older restart_lsn retention requirement.

Dropping a slot removes that slot’s claim, not necessarily the files at that instant. Checkpoint cleanup and other retention requirements still matter. Other slots, archive backlog, or a WAL reserve can keep files present, and recycling may rename them without returning all allocated bytes to the filesystem. Adding every slot’s lag also overcounts overlapping WAL ranges shared by several consumers.

Retention limits exchange one risk for another. max_slot_wal_keep_size is enforced around checkpoints, not as an instantaneous hard disk quota. A sufficiently lagging slot can lose required WAL and become unusable. That protects against indefinite retention at the cost of abandoning that consumer’s existing catch-up path. Age alone is not authority to discard a live replication dependency.

Release of a slot claim, removal of an old filename and loss of catch-up ability are different outcomes. The exact PostgreSQL workflow remains runtime-held.

Check it quickly

Run this script as a non-root account with PostgreSQL 18 server and client binaries in a Linux shell environment. The original article reports PostgreSQL 18.6; this source review did not repeat the slot experiment or recover its original runtime transcript. The private temporary cluster has no TCP listener and contains only test slots. Small logged inserts and forced segment switches make retention visible quickly; this is not a benchmark of business WAL volume.

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-slots.XXXXXX)
mkdir "$lab/socket"
cluster=$lab/data
cleanup() {
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
}
trap cleanup EXIT
initdb -D "$cluster" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$cluster/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
max_replication_slots = 4
max_slot_wal_keep_size = -1
min_wal_size = '32MB'
max_wal_size = '64MB'
checkpoint_timeout = '1h'
CONF
pg_ctl -D "$cluster" -l "$lab/server.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT * FROM pg_create_physical_replication_slot('unused_slot');
SELECT active,restart_lsn IS NULL FROM pg_replication_slots WHERE slot_name='unused_slot';
DO $$ BEGIN
 IF (SELECT restart_lsn IS NULL FROM pg_replication_slots WHERE slot_name='unused_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'unexpected immediate reservation';
 END IF;
END $$;
SELECT pg_drop_replication_slot('unused_slot');
CREATE TABLE churn (value text);
SELECT * FROM pg_create_physical_replication_slot('held_slot',true);
SQL
segment=$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_walfile_name(restart_lsn) FROM pg_replication_slots WHERE slot_name='held_slot'")
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
DO $$ BEGIN
 FOR n IN 1..8 LOOP
 INSERT INTO churn SELECT md5(g::text) FROM generate_series(1,5000) g;
 PERFORM pg_switch_wal();
 END LOOP;
END $$;
CHECKPOINT;
SELECT active,wal_status,pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)>64*1024*1024
FROM pg_replication_slots WHERE slot_name='held_slot';
DO $$ BEGIN
 IF (SELECT NOT active AND wal_status='extended'
 AND pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)>64*1024*1024
 FROM pg_replication_slots WHERE slot_name='held_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'inactive slot did not retain the expected WAL range';
 END IF;
END $$;
SQL
test -f "$cluster/pg_wal/$segment"
echo inactive_slot_retains_old_segment
psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_drop_replication_slot('held_slot')" >/dev/null
test -f "$cluster/pg_wal/$segment"
echo drop_did_not_immediately_remove_segment
psql -X -v ON_ERROR_STOP=1 -qAt -c CHECKPOINT
test ! -f "$cluster/pg_wal/$segment"
echo checkpoint_released_old_segment_name
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
ALTER SYSTEM SET max_slot_wal_keep_size='32MB';
SELECT pg_reload_conf();
SQL
attempt=0
while test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT current_setting('max_slot_wal_keep_size')='32MB'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || exit 1
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT * FROM pg_create_physical_replication_slot('limited_slot',true);
DO $$ BEGIN
 FOR n IN 1..8 LOOP
 INSERT INTO churn SELECT md5(g::text) FROM generate_series(1,5000) g;
 PERFORM pg_switch_wal();
 END LOOP;
END $$;
CHECKPOINT;
SELECT wal_status,invalidation_reason FROM pg_replication_slots WHERE slot_name='limited_slot';
DO $$ BEGIN
 IF (SELECT wal_status='lost' AND invalidation_reason='wal_removed'
 FROM pg_replication_slots WHERE slot_name='limited_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'slot limit did not invalidate the test slot';
 END IF;
END $$;
SELECT pg_drop_replication_slot('limited_slot');
SQL
printf 'lab_directory %s\n' "$lab"

The first physical slot is created without immediate reservation. Its f|t output means inactive with a null restart position. The script asserts that condition and removes this unused fixture. The next slot explicitly reserves WAL and never connects a consumer. After writes, segment switches, and a checkpoint, the observed state is f|extended|t: inactive, retaining beyond the configured maximum WAL target, and more than sixty-four mebibytes behind by LSN distance.

The script checks the original required segment still exists, drops that one test slot, and checks the file remains immediately afterward. A subsequent checkpoint removes the old segment name. Those observations distinguish releasing a claim from immediate filesystem cleanup. They do not claim the complete WAL directory becomes empty or that recycled storage necessarily disappears.

The final phase sets a thirty-two-mebibyte slot retention limit, confirms the reload took effect, and reserves a new slot. More logged work and segment switches push it beyond the limit. After checkpointing, the required result is lost|wal_removed; an assertion checks both availability state and invalidation reason. This is an observed loss of the slot’s recovery path, not successful catch-up by a replica.

Only fixture slots are dropped. The temporary server stops on exit, and the printed directory retains its logs and data for review. No real consumer is disconnected or rebuilt.

Decide from ownership and recoverability

Monitor restart_lsn, wal_status, safe_wal_size, inactivity, actual retained bytes, and free space. A null safety margin can mean unlimited retention or an already lost slot, so interpret it with the other fields. PostgreSQL 18 also exposes an invalidation reason, which distinguishes removed WAL from other causes instead of guessing from elapsed silence.

Before retiring a slot, identify its owner and whether that consumer is expected to resume. Decide explicitly when rebuilding is preferable to retaining more history. If a required segment is already gone, increasing the limit does not recreate it. Verify the replacement consumer’s consistent starting point and ongoing progress before considering the incident resolved. A smaller disk graph alone does not prove replication service has recovered.

Sources

PostgreSQL 18 replication slots view, reserved positions, availability states, safety margins, and invalidation reasons, checked 2026-09-12.
PostgreSQL 18 replication configuration, checkpoint-enforced slot retention limits, checked 2026-09-12.
PostgreSQL 18 administrative functions, physical slot creation, immediate reservation, and dropping slots, checked 2026-09-10.

S3 storage classes trade cost for access

Wed, 30 Sep 2026 00:00:00 +0000

A storage class changes retrieval behavior, resilience, and billing, not just the monthly price of bytes. Start with the time allowed to recover data and whether another copy can be recreated. Standard-IA offers immediate access with retrieval charges; Glacier Flexible Retrieval and Deep Archive require restoration before ordinary reads. One Zone-IA also has a different failure boundary: its data is not resilient to physical loss of its Availability Zone.

Separate the charges before comparing totals

Use the current price sheet for the bucket’s Region and the exact class, retrieval tier, and request type. Storage is charged by billable capacity and duration; retrieval can be charged by bytes, requests, or both. Per-object transitions and archive metadata scale with object count. It is incorrect to describe all these costs as driven only by object count, or to infer total savings from one storage rate.

Do not treat standard retrieval from Flexible Retrieval and Deep Archive as universally free. The price sheet checked on 2026-10-18 lists Flexible Retrieval bulk retrievals and requests as free; Intelligent-Tiering has separate free standard and bulk retrieval rules. Those exceptions do not establish the same price for another class or tier. A restored archive also retains the archived object while its temporary readable copy incurs Standard storage charges for the chosen lifetime.

Minimum durations matter even when an object disappears sooner: Standard-IA and One Zone-IA use thirty days, Glacier Instant and Flexible Retrieval ninety, and Deep Archive 180. Early deletion, replacement, or transition can incur the remaining minimum charge. Standard-IA, One Zone-IA, and Glacier Instant Retrieval have a 128 KB billable-size floor. Flexible Retrieval and Deep Archive add forty KB of metadata per object, split between Standard and archive rates.

Match lifecycle rules to the workload

An object’s age is not its time since last access. A thirty-day transition can affect a year-old report still read weekly. Evaluate object size, bytes retrieved, request frequency, retention, and acceptable restoration delay together. Prefixes and tags can distinguish workloads, but only if their classification stays accurate.

The September 2024 default prevents lifecycle transitions of objects smaller than 128 KB. Older unmodified configurations can retain the previous behavior, and explicit size filters can override defaults. Therefore, a small object remaining in Standard does not alone prove a broken rule. Inspect the configuration’s effective filters and history before attributing the outcome.

When it breaks

A lower storage subtotal can conceal higher retrieval and request charges. Conversely, a frequently read restored copy need not trigger a fresh archive restoration for every read while that copy remains available. Model the actual restore-and-read workflow, including temporary-copy storage, instead of multiplying archive restore charges by every GET.

A restore duration is also an operational dependency. Flexible Retrieval standard requests typically take three to five hours; Deep Archive standard requests typically finish within twelve hours, with bulk typically within forty-eight. These are documented expectations, not an unconditional deadline guarantee. Exercise restoration and verify completion before promising that a recovery-time objective is met.

S3 access before cost — mechanism diagram.

Check it quickly

Run this standalone Python 3 script with assertions enabled. The earlier article reports Python 3.12.14 execution; no matching raw run record was recovered here, and this review did not rerun it. Its deliberately invented prices demonstrate sensitivity, not a current AWS quote or a complete bill. It compares one GiB retained for twelve modeled months and assumes every read retrieves the entire object.

from decimal import Decimal as D

# Invented rates, not an AWS quote; one GiB held for twelve modeled months.
warm_storage = D("0.02")
cold_storage = D("0.01")
retrieval_per_gib = D("0.01")
transition_per_object = D("0.001")


def annual_cost(full_reads):
 warm = 12 * warm_storage
 cold = 12 * cold_storage + full_reads * retrieval_per_gib + transition_per_object
 return warm, cold


assert annual_cost(0) == (D("0.24"), D("0.121"))
assert annual_cost(52) == (D("0.24"), D("0.641"))
assert annual_cost(11)[1] < annual_cost(11)[0]
assert annual_cost(12)[1] > annual_cost(12)[0]
small_bytes, minimum_bytes = 10 * 1024, 128 * 1024
assert D(max(small_bytes, minimum_bytes)) / small_bytes == D("12.8")
assert max(10, 180) == 180 # Illustrative minimum-duration billing boundary.
for reads in (0, 11, 12, 52):
 print(reads, "full reads:", tuple(map(str, annual_cost(reads))))
print("10 KiB under a 128 KiB floor: 12.8x billable size")
print("Excluded: GET requests, transfer, restored copies, tax, and negotiated rates")

Zero reads favor the colder model at 0.121 versus 0.24; fifty-two full reads reverse the choice to 0.641 versus 0.24. With these inputs, eleven reads remain cheaper and twelve do not. The size calculation shows why small-object floors need explicit treatment. Neither result establishes a universal class-selection threshold.

For an authorized bucket, the following unchanged AWS CLI diagnostics require configured read access and replacement of B and K. They were not executed during this review:

aws s3api list-objects-v2 --bucket B --query 'Contents[].StorageClass' --output text | tr '\t' '\n' | sort | uniq -c
aws s3api get-bucket-lifecycle-configuration --bucket B --query 'Rules[].[ID,Status,Transitions[0].Days,Transitions[0].StorageClass]' --output table
aws s3api head-object --bucket B --key K --query 'StorageClass'

For a successful nonempty listing, the first command counts current objects by class, not bytes or noncurrent versions. Handle empty listings and CLI errors separately; pipeline success alone does not validate the AWS call. The second shows only each rule’s first transition, omitting filters and later or noncurrent transitions; inspect the full response before deciding. HeadObject omits StorageClass for Standard, so a null projection is not itself a failure. None of these observations measures access frequency or proves that a pending transition or restore completed. Combine inventory, complete policy, access evidence, and billing before changing lifecycle behavior.

Sources

AWS S3 pricing, billing dimensions, restore copies, and free-tier distinctions, checked 2026-10-15.
AWS storage class guide, access, resilience, minimum duration, and billable size, checked 2026-10-15.
AWS lifecycle transitions, small-object defaults and existing configurations, checked 2026-10-15.
AWS archive retrieval options, typical restore durations, checked 2026-10-15.
AWS CLI HeadObject, Standard omits StorageClass, checked 2026-10-15.
AWS CLI ListObjectsV2, listing scope and object fields, checked 2026-10-15.
AWS CLI lifecycle configuration, filters and transition arrays, checked 2026-10-15.

Storage · XB Field Notes

LVM snapshots capture a block device in time

An exception store, not a copy

Exhaustion is invalidation

Merging, and why thin changes the failure

When it breaks

Check it quickly

Sources

ZFS snapshots give the filesystem a rewind button

A name for one consistent tree

Where the space is, in zfs list -o space

Holds, diff, and comparing versions

When it breaks

Check it quickly

Sources

High-cardinality labels increase stored series before anyone queries them

Count observed combinations, not isolated values

Querying fewer rows does not store fewer rows

Diagnose growth with the right inventory

When it breaks

Check it quickly

Sources

A checkpoint flushes dirty buffers to disk

When it breaks

Check it quickly

Tune against recovery and foreground work

Sources

Partitioning splits one table into many pieces that look like one

A logical parent with physical children

The key affects more than routing

When it breaks

Check it quickly

Sources

Redis append-only log trades speed for durability

Execution, logging, and acknowledgment

Choose the synchronization contract

Rewriting creates a recoverable file set

When it breaks

Check it quickly

Sources

Btrfs snapshots are copy-on-write, not copies

Shared extents, not copied blocks

Where the space actually goes

A restore point is not a replica

When it breaks

Check it quickly

Sources

An LRU cache evicts the least recently used entry

Follow the access order

Exact and sampled policies differ

Capacity is not freshness

When it breaks

Check it quickly

Further reading

Sources

LSM trees trade foreground writes for later merging

Buffering changes when work happens

Reads still pay for versions

When it breaks

Check it quickly

Sources

A sparse file separates logical length from allocated blocks

When it breaks

Check it quickly

Budget and preserve the intended representation

Sources

A PVC gives a Pod durable storage beyond the container

The claim, the volume, and the binding

The deletion order and the finalizer

Reclaim policy: Delete or Retain

When it breaks

Check it quickly

Sources

NFS shares a remote directory over the network

The file and the table

What the options actually decide

Mounting, and the id mapping trap

When it breaks

Check it quickly

Sources