Document weed admin -adminLock.fairnessWindow

Admin-UI.md

@@ -46,6 +46,7 @@ weed admin [options]
 | `-debug.port` | 6060 | HTTP port for the pprof debug server |
 | `-cpuprofile` | "" | CPU profile output file, written on shutdown |
 | `-memprofile` | "" | Memory profile output file, written on shutdown |
+| `-adminLock.fairnessWindow` | 1m | Once scheduled jobs have held the cluster admin lock this long, new jobs wait until every holder releases it, so `weed shell` clients get a turn. `0` lets jobs keep joining the hold; shell clients then get the lock when the scheduler next drains (see [[Plugin Worker Scheduling]]) |
 
 ## Network Binding
 

Plugin-Worker-Scheduling.md

@@ -125,6 +125,15 @@ takes the cluster admin lock, so anything in it is serialised behind vacuum and
 balancing; `iceberg`, `lifecycle` and `lance` do not, because they act on table
 data rather than on volumes.
 
+The `default` lane takes the lock around each detection and each job, and
+overlapping holds share one lease. Once that lease is older than
+`weed admin -adminLock.fairnessWindow` (one minute by default), new jobs wait
+until every running job releases it, so a waiting `weed shell` gets a turn. With
+long jobs (EC vacuum or repair running for an hour) this dispatches in waves: a
+freed worker slot stays idle until the slowest job of the wave ends. Setting the
+window to `0` lets new jobs keep joining the hold; shell clients then get the
+lock when the lane drains, at the latest between job types.
+
 Lane assignment lives in the admin server, not in the worker: a new job type from
 an external worker lands in `default` until it is mapped, which silently serialises
 it behind cluster maintenance.