fix: blob thin clusters, raid rebuild copies and ejection epoch, cbt history windows, nvmf reservations, bdev_nvme passthrough (0044–0052)

[rducom]

This PR carries nine patches of the series, 0044 to 0052, and one change to the cbt module (bdev_cbt_rotate). Each patch comes as two commits: its tests alone, red on the series below it, then the fix. It is stacked on #27, whose image pipeline builds and runs the upstream unit suites the series touches.

Patch	Area	What it changes
0044	blob	a thin cluster is cleared before use
0045	raid	a seeded rebuild copies its ranges, and only under the windows they need
0046	raid	a seeded rebuild reads its ranges from a frozen CBT epoch, in-process
0047	raid1	a rebuild copies its window in parts, all in flight together
0048	raid1	a rebuild writes an all-zero part as write-zeroes
0049	blob	write-zeroes leaves an unallocated thin cluster unallocated
0050	nvmf	a reservation held by all registrants outlives its acquirer
0051	bdev_nvme	an I/O passthrough needs a connected qpair
0052	raid1, cbt	a raid1 ejection opens its epoch on the raid's cbt

scripts/patches.sh check passes on a clean checkout at the pinned commit (51 patches), and regen from the series leaves every patch byte-identical to this branch.

0044: a thin cluster is cleared before use

Problem

A cluster that a write allocates in a blob backed by zeroes (a thin blob with no parent, or a clone over a range its snapshot never allocated) is inserted as the device left it. The write fills its own range, and the rest of the cluster returns whatever was stored there before.

The free path counts on unmap to leave zeroes (see spdk_free_cluster_unmap_complete: "so if the cluster is reclaimed in the future, it won't leak old data"). A SATA SSD does not guarantee that, and a bdev without unmap support never provides it. So:

• Remanence across blobs. The unwritten part of a new cluster returns another blob's data. A filesystem on top does not expose it, since it reads unwritten extents as zeroes, but anything that reads the raw device does.

• Mirror legs differ in bytes nobody wrote. Each device keeps its own residue, and a raid1 verify over such lvols (bdev_raid_verify_ranges, or any block compare of the legs) reports a content divergence. mkfs.xfs alone leaves such bytes:

  • the 2 KiB after the headers of each allocation group;
  • most of the last cluster, since it zeroes only the device's last 128 KiB (and WRITE_ZEROES on an unallocated cluster allocates it too);
  • the rest of the cluster at the end of its log.

  On a lab cluster, a fresh 5 GiB three-leg mirror was reported divergent in 1198 blocks of 4 KiB right after mkfs.xfs, with no application data, one leg in the minority everywhere.

Fix

• When the new cluster is not copied from a parent, bs_allocate_and_copy_cluster clears it with write_zeroes before inserting it.
• A write (or write_zeroes) that covers the whole cluster skips the clear: it overwrites everything, and a rebuild or a copy, which write whole clusters, does not write twice.
• A clear that fails returns the cluster to the pool.
• The inflate path, whose clusters over zero ranges were also handed out uninitialized, goes through the same branch, so an inflated cluster reads zeroes too.

Cost: one extra cluster write (1 MiB by default) on the first partial write into a cluster, once per cluster lifetime.

Not covered: thick blobs get their clusters at creation and still count on the free path.

Tests

blob_ut:

• blob_thin_prov_new_cluster_reads_zeroes: every free cluster is filled with 0xAA, then a one-io_unit write goes into a new cluster. The rest of the cluster reads zeroes.
• blob_thin_prov_full_cluster_write_is_not_cleared_first: a whole-cluster write costs the payload and the metadata page(s), and no clear.
• blob_thin_prov_rw, blob_thin_prov_write_count_io and blob_thin_prov_rle now count the cleared cluster in their write accounting.

In the image pipeline:

• Tests only (e539f7e): red on amd64 and arm64, FAILED: 1 of 18 suites: lib/blob/blob.c. Four tests fail in each of the 5 suites of blob_ut: blob_thin_prov_new_cluster_reads_zeroes and the three accounting tests. blob_thin_prov_full_cluster_write_is_not_cleared_first also passes before the fix: it guards the fix's cost.
• With the fix (e94d862): green, all 18 suites pass on amd64 and arm64.

A first version of this PR ran blob_ut in a separate job that built SPDK a second time. That job was dropped in favour of #27.

0045 and 0046: a seeded rebuild copies its delta, and only its delta

A seeded rebuild (a member that missed some writes, with the dirty ranges known) copied every window a range touched in full, and still locked and skipped every clean window. Measured on a three-node lab cluster under a random-write load: 5 GiB re-copied for 395 MiB of dirty chunks (4794 ranges), in 110 s. Copying only the ranges, one window per range part, still took 100 s. The cost was the window cycle (quiesce, copy, channel update, unquiesce), not the bytes.

0045. A seeded process now jumps over what its ranges leave clean, with no window at all: only a copy needs a window's quiesce, and the seeded target already receives every write on either side of the process offset. A window copies every range part it holds under its one lock. The verify phase and the copied-bytes accounting are unchanged.

0046. A JSON-RPC request carries about 200 ranges, so a caller had to fold a larger delta to fit it, and folding a scattered delta recopies every clean block in between (4485 dirty ranges folded to 128 recopied 3.2 GiB of clean blocks: as slow as a full rebuild). bdev_raid_start_seeded_rebuild_from_epoch seeds the same rebuild with the dirty ranges of a frozen CBT epoch, read in-process through vbdev_cbt_query_epoch_ranges. A delta larger than the caller's cap is refused (-E2BIG) rather than truncated, and the caller rebuilds in full. Both RPCs share their checks and their audit.

Tests. bdev_raid_ut: two seed ranges inside one window copy 12 blocks under one lock (the window was copied whole); a range across three windows copies 9 blocks under three locks; a range at the end of the raid takes one lock (the clean windows before it were each locked); 64 one-block ranges from a faked epoch copy their 64 blocks, and a delta the query refuses starts nothing. Every raid suite stays green.

0047 and 0048: a full rebuild keeps the link busy, and only with data

0047. A rebuild window was copied as one request: read whole from one member, then written whole. Read and write never overlapped, and the first member served every read. Measured on a 3-node bench, a full rebuild of a 5 GiB three-leg mirror under a verified write load ran at 36 MiB/s for 141 s, every byte read across the link from a remote member while the local one sat idle. raid_bdev_process_request_max_part now offers a window in RAID_BDEV_PROCESS_MAX_QD parts of whole write units, and raid1 copies one part per request: each part's write starts as its own read completes, and the reads spread over the members in sync. raid5f, bound to its stripe, does not call it.

0048. A part the source read back as nothing but zeroes goes to the target as write-zeroes: the same blocks, read back the same, and no payload on the wire. On the same bench, about 3 of the 5 GiB of a full rebuild were zeroes, all of them through the nexus node's egress. Not when the target cannot take write-zeroes, nor when the blocks carry metadata. The check reads the part already in memory and stops at the first nonzero word.

Tests. raid1_ut: a 64-block window is copied by four requests in flight together, the reads tiling the window and spread evenly over the members (before: one request, and on three members the second served no read); four parts read back as data and zeroes go out as data and write-zeroes, or all as data when the target cannot take write-zeroes. bdev_raid_ut: the parts are whole write units and fit the queue depth.

0049: write-zeroes leaves an unallocated thin cluster unallocated

On a blob backed by zeroes, an unallocated cluster already reads zeroes, so write-zeroes over it now completes at once: no cluster allocated, nothing written. Before, it allocated the cluster (cleared, since 0044) and zeroed it. Since 0048 sends every never-written part of a rebuild as write-zeroes, a thin volume rebuilt in full took its whole size on the target, and its zeroes still went to the target's disk (94 MiB/s of writes through a 5 GiB rebuild with about 3 GiB never written). An allocated cluster is still zeroed, and a clone, which reads its unallocated clusters from its parent, still allocates and zeroes.

Tests. blob_ut: write-zeroes over half of an unallocated cluster of a thin blob allocates nothing, writes nothing and reads back zeroes; over an allocated cluster holding data it zeroes what it covers; on a clone it allocates the cluster and zeroes it.

0050: a reservation held by all registrants outlives its acquirer

Every registrant holds a Write Exclusive or Exclusive Access – All Registrants reservation, so it stays when the registrant that acquired it leaves (preempted, or unregistering). It stayed under the key of the registrant that left: the persisted state named a reservation key no registrant held, and the restore refused it (-EINVAL), failing the add of the namespace. After a writer handover, the next restart of a target left the namespace out, unexported. The reservation now stands under the key of the registrant that holds it next. The restore takes a state persisted before this fix under the key of its first registrant; a single holder's key that no registrant holds is still refused.

Tests. subsystem_ut: an All Registrants reservation acquired by A, then A preempted by B, keeps a key B holds and restores; the same once B unregisters after C registered. The restore test refuses a missing key for a single holder only.

0051: an I/O passthrough needs a connected qpair

bdev_nvme_send_cmd with an I/O command took the controller channel's qpair (bdev_nvme_get_io_qpair) without a check and handed it to spdk_nvme_ctrlr_cmd_io_raw_with_md. bdev_nvme frees that qpair from a disconnect until the reconnect (bdev_nvme_disconnected_qpair_cb), so a reservation command (reservations are I/O commands) sent to a member whose path had just gone down dereferenced NULL and killed the process, every raid it carried with it. The command is now refused with -ENXIO and the channel given back; a command for which no channel can be had is refused with -ENOMEM.

Tests. bdev_nvme_ut now compiles nvme_rpc.c in, so the passthrough is driven against a real controller channel. With the channel's I/O qpair cleared, as a disconnect clears it, the command was still handed to the NVMe library (rc 0, channel kept). It is now refused with -ENXIO, the channel given back, and it goes through once connected again. 55/55 with the fix.

0052: a raid1 ejection opens its epoch on the raid's cbt

0019 opens a CBT epoch when a member leaves a raid1, so the member's return is a delta instead of a full rebuild. It asked each survivor's own bdev name for that epoch, but the cbt sits on the raid, not on its members: every call answered -ENODEV, no epoch ever opened, and a member lost without notice was always rebuilt in full.

The raid now asks once, with its own name and the member's UUID. vbdev_cbt_auto_epoch_open finds the cbt stacked on that bdev and opens the epoch there. The UUID is the identity a control plane can derive for the member: an NVMe-oF initiator bdev inherits the UUID of the namespace it attaches.

An epoch holds the writes a member misses from its departure on, so two guards keep the delta whole:

• The member left current. Its superblock slot is configured at the generation its peers carry, it is not a write-only joiner, and it is not a failed member that an earlier removal failed to take (a new removal_failed flag which, unlike remove_error, survives the retry). A member being rebuilt in full, or seated behind, owes more than the writes it misses from now on.
• The cbt carries no live epoch. Open, frozen and rebuilding ones all refuse. An open one bounds a round its caller started. A freeze empties the live bitmap, so after one, an epoch opened now may start short of writes the member missed just before it left.

Every member these guards turn away is rebuilt in full, as before.

Tests. bdev_raid_ut drives real ejections of a superblock raid (the suite's module stands in for raid1). A current member, removed or failed, opens one epoch, on the raid's name and under the member's UUID. Before the fix it opened 31, one per survivor name. Five ejections open none: a member being rebuilt in full, one behind its peers' generation, a write-only joiner, a raid without a superblock, and a failed member whose first removal failed (driven through a quiesce that fails once). Tests only: 2 of 25 red, 11 assertions. With the fix: 25/25, and every raid suite stays green. The cbt side has no suite in the image pipeline (the module's tests run against a standalone model).

cbt: the live bitmap in rotating windows (bdev_cbt_rotate)

With 0052 the epoch at ejection opens, but on a lab cluster its delta resolved to 81920 of 81920 chunks: the live bitmap holds every write since its last bdev_cbt_reset, and nothing can reset it at the ejection, since the writes the member just missed are in it. On a volume that goes days without an epoch, the "delta" is the whole device.

bdev_cbt_rotate, called periodically while no epoch is live, moves the live bitmap to a previous-window bitmap (dropping the window before) and starts it again empty. vbdev_cbt_auto_epoch_open ORs the previous window back before it opens, so its delta holds one to two windows of writes before the departure and everything after. Two rotations are at least CBT_ROTATE_MIN_INTERVAL_US (10 s) apart whoever asks, so a write the member missed a few milliseconds before its ejection is always in one of the two bitmaps. A rotation is refused with -EBUSY while an epoch is open, frozen or rebuilding, since that epoch reads the live bitmap whole, and with -EAGAIN when it comes too soon. A reset clears both bitmaps. The module README describes it.