DF-5108 lockrange hammer — guest results (6 vCPU, DragonFly 6.5-DEVELOPMENT
X86_64_GENERIC, vinum RAID-5 volume rv = 3 × 100 MB sds on vn-backed drives,
stripesize 64s = 32 KB, volume up, rangelocks active via bre5)

run 1: 400 threads, 300 s, 300-stripe pool, 32 KB pwrite
  hammering /dev/vinum/vol/rv: 400 threads, 300 s, 300 stripes, 32768-byte writes
  thread 170: 9749 ops, 0 errors
  thread 14: 12930 ops, 0 errors
  done
  (~4.5 M ops total; no panic, no wedge, guest up)

run 2: 800 threads, 300 s, 270-stripe pool, 32 KB pwrite
  hammering /dev/vinum/vol/rv: 800 threads, 300 s, 270 stripes, 32768-byte writes
  thread 20: 7755 ops, 0 errors
  thread 179: 7600 ops, 0 errors
  done
  (800 thread-exit lines, 0 errors; ~6 M ops; no panic, guest up)

run 5: 300 threads, 300 s, 258-stripe pool, 128 KB pwrite (deeper in-flight)
  hammering /dev/vinum/vol/rv: 300 threads, 300 s, 258 stripes, 131072-byte writes
  thread 210: 3158 ops, 0 errors
  thread 153: 2590 ops, 0 errors
  done
  (300 thread-exit lines, 0 errors; ~870 K ops; no panic, guest up)

(runs 3 and 4 lost their background processes to ssh session teardown —
no data; not counted.)

Aggregate: ~11 M RAID-5 write ops across 3 completed runs, 0 I/O errors,
0 panics, no "vlock" wedge. dmesg clean of fatal/trap throughout.

Interpretation: aggregate throughput (≈40 K ops/s × 2-4 ms service time)
implies ≈80-160 concurrently-held rangelock slots — the 256-slot table
never reached exactly-full at a wake boundary, which is the precondition
for the pos-overflow commit (vinumlock.c:181-190). The defect is
established by code path (missing recheck after :167 tsleep, == vs >=
at :139/:220); reproduction needs deeper/slower I/O concurrency than
this guest sustains. Verdict: not_reproduced (race-gated).