crimson/seastore/rbm: fix leakage on conflicted OOL writes

Problem:
In-flight out-of-line (OOL) writes did not clear t.pending_ool on successful
completion. If the transaction was subsequently marked conflicted during
commit/prepare, it erroneously marked the completed write as conflicted.
This caused:
1. conflict_pending_free_bytes to leak upward.
2. Physical extents to remain allocated but untracked, leaking space.
Eventually, this led to allocator exhaustion and OSD deadlock.

Solution:
Clear t.pending_ool on OOL write completion and transaction reset. Implement
a backpressure condition variable for pending deferred frees so that write
operations wait when accumulated conflicted frees exceed a 5% threshold.

Change:
* Added clear_pending_ool() to Transaction and called it from the
  do_write() finally continuation in RandomBlockOolWriter::
  alloc_write_ool_extents, so it runs on every exit path (success,
  error, or conflict-driven unwind) and the conflicted check plus the
  clear are atomic with respect to reactor task interleaving.
* Cleared pending_ool in Transaction::reset() to prevent leaks across
  transaction reuse/retry.
* Tracked conflicted pending free bytes in RBMCleaner.
* Added wait_for_conflict_drain() to pause new OOL writes when deferred
  frees exceed 5% of data capacity.

The pending deferred frees are also a release source for the reservation
gate introduced by the preceding commit: account them in
try_reserve_projected_usage()'s release-source check, and wake blocked IO
when they drain so the gate is re-evaluated.

Signed-off-by: Shai Fultheim <shai.fultheim@gmail.com>

.github/workflows/check-license.yml

@@ -1,6 +1,16 @@
 ---
 name: "Check for Incompatible Licenses"
-on: [pull_request]
+on:
+  pull_request_target:
+    branches:
+      - main
+      - umbrella
+      - tentacle
+      - squid
+
+permissions:
+  contents: read
+  pull-requests: read
 
 jobs:
   pull_request:

.github/workflows/create-backport-trackers.yml

@@ -38,7 +38,7 @@ jobs:
     # Backport checks need to be run ONLY on the main branch on ceph/ceph (not forks)
     if: github.ref == 'refs/heads/main' && github.repository == 'ceph/ceph'
     steps:
-      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           sparse-checkout: | 
               src/script/backport-create-issue

.github/workflows/diff-ceph-config.yml

@@ -25,7 +25,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout main branch for pull_request_target
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           ref: 'refs/heads/main'
           path: ceph

.github/workflows/pr-checklist.yml

@@ -1,15 +1,22 @@
 ---
 name: "Pull Request Checklist"
 on:
-  pull_request:
+  pull_request_target:
+    branches:
+      - main
     types:
       - edited
       - opened
       - reopened
+
+# https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#defining-access-for-the-github_token-scopes
+permissions:
+  pull-requests: read
+
 jobs:
   pr_checklist:
     runs-on: ubuntu-latest
-    name: Verify
+    name: Verify Checklist
     steps:
       - name: Sleep for 30 seconds
         run: sleep 30s

.github/workflows/qa-symlink.yml

@@ -1,11 +1,15 @@
 ---
 name: "Check for missing .qa links"
 on:
-  pull_request:
+  pull_request_target:
+    branches:
+      - main
+      - umbrella
+      - tentacle
+      - squid
     types:
       - opened
       - synchronize
-      - edited
       - reopened
 permissions:
   contents: read
@@ -15,18 +19,21 @@ jobs:
     runs-on: ubuntu-latest
     if: github.repository == 'ceph/ceph'
     steps:
-      - name: Checkout main branch for pull_request_target
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+      - name: Checkout verify-qa script from main branch
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           ref: 'refs/heads/main'
           path: main
+          sparse-checkout: |
+            src/script/verify-qa
+          sparse-checkout-cone-mode: false
 
       - name: Checkout PR HEAD
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           ref: ${{ github.event.pull_request.head.sha }}
           path: pull_request
 
-      - name: verify .qa links
-        run: ../main/src/script/verify-qa
-        working-directory: pull_request/
+      - name: Run verification script
+        run: |
+          ./main/src/script/verify-qa ./pull_request

.github/workflows/redmine-upkeep.yml

@@ -41,7 +41,7 @@ jobs:
     steps:
       - name: Checkout main branch for pull_request_target
         if: github.event_name == 'pull_request_target'
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           ref: 'refs/heads/main'
           path: 'ceph'
@@ -49,7 +49,7 @@ jobs:
 
       - name: Checkout default branch for other events
         if: github.event_name != 'pull_request_target'
-        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           path: 'ceph'
           fetch-depth: 0

.github/workflows/releng-audit.yaml

@@ -17,15 +17,16 @@ concurrency:
 
 jobs:
   audit:
-    name: Backport Audit
+    name: Execution and Routing
     runs-on: ubuntu-latest
     permissions:
+      contents: read
       pull-requests: write
       issues: write
       statuses: write
     steps:
       - id: router
-        name: Evaluate Workflow Routing & Overrides
+        name: Evaluate Workflow Routing
         uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
         env:
           ORG_TOKEN: ${{ secrets.ORG_READ_PAT }}
@@ -35,39 +36,192 @@ jobs:
             const payload = context.payload;
             const actor = context.actor;
             const isBot = actor === 'github-actions[bot]' || actor === 'github-actions';
+            const runUrl = `https://github.com/${context.repo.owner}/${context.repo.repo}/actions/runs/${context.runId}`;
             
+            // Safely removes a label and logs execution, ignoring 404s if label is not attached
+            async function removeLabelSafely(labelName) {
+              try {
+                core.info(`[Router] Attempting to remove label '${labelName}'...`);
+                await github.rest.issues.removeLabel({
+                  owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: labelName
+                });
+                core.info(`[Router] Successfully removed label '${labelName}'.`);
+              } catch (e) {
+                if (e.status === 404) {
+                  core.info(`[Router] Label '${labelName}' was not present on PR (404 ignored).`);
+                } else {
+                  core.warning(`[Router] Failed to remove label '${labelName}': ${e.message}`);
+                }
+              }
+            }
+
+            // Verifies if the user has maintainer/admin collaborator permissions or is an active
+            // member of the ceph-release-manager team. Required for /audit override and test-branch.
             async function checkAuthorization(username) {
+              core.info(`[Router] Checking collaborator permission level for @${username}...`);
               let authorized = false;
               try {
                 const { data: permData } = await github.rest.repos.getCollaboratorPermissionLevel({
                   owner: context.repo.owner, repo: context.repo.repo, username: username
                 });
-                authorized = (permData.permission === 'admin' || permData.permission === 'maintain')
+                core.info(`[Router] Collaborator permission level for @${username}: ${permData.permission}`);
+                authorized = (permData.permission === 'admin' || permData.permission === 'maintain');
               } catch (e) { 
                 core.info(`[Router] Failed to fetch repo permissions: ${e.message}`); 
               }
 
               if (!authorized && context.repo.owner === 'ceph' && process.env.ORG_TOKEN) {
+                core.info(`[Router] @${username} does not have maintain/admin repo rights. Checking ceph-release-manager team membership...`);
                 try {
-                  const orgOctokit = getOctokit(process.env.ORG_TOKEN);
+                  const orgOctokit = github.getOctokit(process.env.ORG_TOKEN);
                   const { data: teamData } = await orgOctokit.rest.teams.getMembershipForUserInOrg({
                     org: 'ceph', team_slug: 'ceph-release-manager', username: username
                   });
+                  core.info(`[Router] Org team membership state for @${username}: ${teamData.state}`);
                   authorized = (teamData.state === 'active');
                 } catch (e) { 
                   core.info(`[Router] Failed to fetch org team membership: ${e.message}`); 
                 }
               }
+              core.info(`[Router] Authorization result for @${username}: ${authorized ? 'AUTHORIZED' : 'NOT AUTHORIZED'}`);
               return authorized;
             }
 
+            // Retrieves the HEAD SHA of the pull request. Falls back to an API lookup
+            // when triggered by issue_comment events where the PR object is omitted from payload.
+            async function getPrSha() {
+              let sha = context.payload.pull_request?.head?.sha;
+              if (!sha) {
+                core.info(`[Router] PR SHA not found in payload. Fetching from API for issue #${context.issue.number}...`);
+                try {
+                  const { data: pr } = await github.rest.pulls.get({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    pull_number: context.issue.number
+                  });
+                  sha = pr.head.sha;
+                  core.info(`[Router] Successfully retrieved SHA from API: ${sha}`);
+                } catch (e) {
+                  core.error(`[Router] Failed to fetch PR details from API: ${e.message}`);
+                }
+              } else {
+                core.info(`[Router] Retrieved PR SHA from payload: ${sha}`);
+              }
+              if (sha) core.setOutput('pr_sha', sha);
+              return sha;
+            }
+
+            // Pushes a pending commit status to the PR HEAD SHA to provide visual feedback
+            // and block branch protection while the audit executes. For standard audit runs,
+            // strips pass/fail state labels before starting.
+            async function triggerAuditRun(description, statusContext = 'Backport Audit') {
+              core.info(`[Router] Initiating audit run trigger for context '${statusContext}': ${description}`);
+              const isStandard = (statusContext === 'Backport Audit');
+              if (isStandard) {
+                core.info('[Router] Clearing any previous labels before starting standard audit run...');
+                await removeLabelSafely('releng-audit-fail');
+                await removeLabelSafely('releng-audit-override');
+                await removeLabelSafely('releng-audit-pass');
+                await removeLabelSafely('releng-audit-queue');
+              }
+              const sha = await getPrSha();
+              if (!sha) {
+                core.error('[Router] Cannot initiate audit: PR SHA could not be retrieved.');
+                core.setOutput('run_audit', 'false');
+                return;
+              }
+              core.setOutput('status_context', statusContext);
+
+              if (isStandard) {
+                try {
+                  core.info(`[Router] Setting commit status to 'pending' on SHA ${sha}...`);
+                  await github.rest.repos.createCommitStatus({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    sha: sha,
+                    state: 'pending',
+                    context: statusContext,
+                    description: description,
+                    target_url: `https://github.com/${context.repo.owner}/${context.repo.repo}/actions/runs/${context.runId}`
+                  });
+                  core.info(`[Router] Set pending commit status (${statusContext}) on SHA: ${sha}`);
+                } catch (e) {
+                  core.error(`[Router] Failed to set commit status: ${e.message}`);
+                }
+              } else {
+                core.info(`[Router] Non-standard audit run ('${statusContext}') — skipping pending commit status creation.`);
+              }
+              core.setOutput('run_audit', 'true');
+            }
+
+            // Pushes an immediate success commit status when an authorized override occurs,
+            // unblocking required branch protection rules without executing the audit script.
+            async function setOverrideStatus(actorName) {
+              core.info(`[Router] Setting override success commit status for @${actorName}...`);
+              try {
+                const sha = await getPrSha();
+                if (sha) {
+                  await github.rest.repos.createCommitStatus({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    sha: sha,
+                    state: 'success',
+                    context: 'Backport Audit',
+                    description: `Audit requirement overridden by @${actorName}`,
+                    target_url: `https://github.com/${context.repo.owner}/${context.repo.repo}/actions/runs/${context.runId}`
+                  });
+                  core.info(`[Router] Set success (override) commit status on SHA: ${sha}`);
+                } else {
+                  core.error('[Router] Cannot set override commit status: SHA is undefined or could not be retrieved.');
+                }
+              } catch (e) {
+                core.error(`[Router] Failed to set override commit status: ${e.message}`);
+              }
+            }
+
+            // Performs the complete override state transition atomically: applies the override label,
+            // strips pass/fail labels, updates commit status to success, and posts a confirmation comment.
+            async function executeOverride(actorName, addLabel = true, postComment = true) {
+              core.info(`[Router] Executing override lifecycle for @${actorName} (addLabel=${addLabel}, postComment=${postComment})...`);
+              if (addLabel) {
+                try {
+                  core.info('[Router] Applying releng-audit-override label...');
+                  await github.rest.issues.addLabels({
+                    owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, labels: ['releng-audit-override']
+                  });
+                  core.info('[Router] Successfully added releng-audit-override label.');
+                } catch (e) {
+                  core.error(`[Router] Failed to add override label: ${e.message}`);
+                }
+              }
+              core.info('[Router] Stripping pass/fail labels as part of override execution...');
+              await removeLabelSafely('releng-audit-fail');
+              await removeLabelSafely('releng-audit-pass');
+              await setOverrideStatus(actorName);
+              if (postComment) {
+                try {
+                  core.info('[Router] Posting override confirmation comment...');
+                  await github.rest.issues.createComment({
+                    owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number,
+                    body: `✅ **Audit Override Applied** by @${actorName}.\n\n[View workflow run](${runUrl})`
+                  });
+                  core.info('[Router] Successfully posted override confirmation comment.');
+                } catch (e) {
+                  core.error(`[Router] Failed to post override comment: ${e.message}`);
+                }
+              }
+            }
+
             core.info(`[Router] Evaluating event: ${eventName}, action: ${payload.action || 'N/A'}`);
 
             // ==========================================
-            // 1. HANDLE ISSUE COMMENTS (/audit commands)
+            // 1. HANDLE ISSUE COMMENTS (State Machine Drivers)
             // ==========================================
+            // Issue comments (/audit commands) act strictly as state machine drivers.
+            // For standard commands (/audit retest, /audit override), we only apply labels
+            // here. This routes execution cleanly through the 'labeled' event handler,
+            // ensuring a single source of truth for audit triggers and override state changes.
             if (eventName === 'issue_comment') {
-              core.info('[Router] Processing issue_comment event.');
               if (!payload.issue.pull_request) {
                 core.info('[Router] Comment is not on a pull request. Skipping.');
                 core.setOutput('run_audit', 'false');
@@ -77,180 +231,211 @@ jobs:
               const commentBody = payload.comment.body.trim();
               
               if (commentBody.startsWith('/audit retest')) {
-                core.info('[Router] Detected /audit retest command. Triggering audit.');
-                core.setOutput('run_audit', 'true');
-                return;
-              } 
-              
-              if (commentBody.startsWith('/audit override')) {
-                core.info(`[Router] Validating if user @${actor} is authorized to apply override.`);
-                const isAuthorized = await checkAuthorization(actor);
-                
-                if (isAuthorized) {
-                  core.info(`[Router] User @${actor} is authorized. Applying override and stripping fail label.`);
-                  await github.rest.issues.addLabels({
-                    owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, labels: ['releng-audit-override']
-                  });
-                  try {
-                    await github.rest.issues.removeLabel({
-                      owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-fail'
-                    });
-                  } catch (e) {}
+                // Directly trigger the audit run instead of bouncing through an ephemeral label
+                core.info('[Router] /audit retest detected. Triggering immediate audit execution...');
+                try {
                   await github.rest.issues.createComment({
                     owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number,
-                    body: `✅ **Audit Override Applied** by @${actor}.`
+                    body: `🔄 **Audit Retest Triggered** by @${actor}.\n\n[View workflow run](${runUrl})`
                   });
+                } catch (e) {
+                  core.error(`[Router] Failed to post retest comment: ${e.message}`);
+                }
+                await triggerAuditRun('Running backport audit...');
+              } else if (commentBody.startsWith('/audit override')) {
+                // Execute the full override lifecycle atomically within this run
+                core.info(`[Router] /audit override detected. Validating @${actor}...`);
+                if (await checkAuthorization(actor)) {
+                  core.info(`[Router] @${actor} is authorized. Executing override...`);
+                  await executeOverride(actor, true, true);
                 } else {
-                  core.info(`[Router] User @${actor} NOT authorized. Removing override label.`);
-                  core.setFailed(`User @${actor} is not authorized to override audits.`);
+                  core.error(`User @${actor} is not authorized to override audits.`);
                 }
                 core.setOutput('run_audit', 'false');
-                return;
+              } else if (commentBody.startsWith('/audit test-branch')) {
+                // Test branch mode: Execute PTL tool from an alternative branch for testing/debugging.
+                // To prevent side effects on PR mergeability, this mode does NOT touch state labels
+                // and will report a success commit status even if issues are found (findings are posted as PR comments).
+                core.info(`[Router] /audit test-branch detected. Validating @${actor}...`);
+                if (await checkAuthorization(actor)) {
+                  const parts = commentBody.split(/\s+/);
+                  const testBranch = parts[2] || 'testing/releng-audit';
+                  
+                  try {
+                    core.info(`[Router] Validating test branch '${testBranch}' exists...`);
+                    await github.rest.repos.getBranch({ owner: context.repo.owner, repo: context.repo.repo, branch: testBranch });
+                    core.info(`[Router] Test branch '${testBranch}' verified.`);
+                  } catch (e) {
+                    core.error(`Test branch '${testBranch}' does not exist: ${e.message}`);
+                    await github.rest.issues.createComment({
+                      owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number,
+                      body: `❌ **Audit Test Mode Failed**\n\nBranch \`${testBranch}\` was not found in \`${context.repo.owner}/${context.repo.repo}\`.\n\n[View workflow run](${runUrl})`
+                    });
+                    core.setOutput('run_audit', 'false');
+                    return;
+                  }
+
+                  try {
+                    core.info('[Router] Posting test mode activation comment...');
+                    await github.rest.issues.createComment({
+                      owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number,
+                      body: `🧪 **Audit Test Mode Activated** by @${actor}.\n\nExecuting audit using tooling checked out from branch \`${testBranch}\`. *This run will not affect required PR commit statuses or state labels.*\n\n[View workflow run](${runUrl})`
+                    });
+                    core.info('[Router] Successfully posted test mode activation comment.');
+                  } catch (e) {
+                    core.error(`[Router] Failed to post test mode comment: ${e.message}`);
+                  }
+
+                  core.setOutput('checkout_ref', testBranch);
+                  await triggerAuditRun(`Running audit using branch ${testBranch}...`, `Audit Test Mode (${testBranch})`);
+                } else {
+                  core.error(`User @${actor} is not authorized to invoke test branches.`);
+                  core.setOutput('run_audit', 'false');
+                }
+              } else {
+                core.info('[Router] Comment is not a recognized /audit command. Skipping.');
+                core.setOutput('run_audit', 'false');
               }
 
-              core.info('[Router] Comment is not an audit command. Skipping.');
-              core.setOutput('run_audit', 'false');
               return;
             }
 
             // ==========================================
-            // 2. HANDLE PR EVENTS
+            // 2. HANDLE PR EVENTS & LABELS
             // ==========================================
             const hasFailLabel = payload.pull_request?.labels.some(l => l.name === 'releng-audit-fail');
             const hasPassLabel = payload.pull_request?.labels.some(l => l.name === 'releng-audit-pass');
             const hasOverrideLabel = payload.pull_request?.labels.some(l => l.name === 'releng-audit-override');
+            const hasQueueLabel = payload.pull_request?.labels.some(l => l.name === 'releng-audit-queue');
 
-            core.info(`[Router] Current labels - Fail: ${hasFailLabel}, Pass: ${hasPassLabel}, Override: ${hasOverrideLabel}`);
+            core.info(`[Router] Current state labels -> Fail: ${hasFailLabel}, Pass: ${hasPassLabel}, Override: ${hasOverrideLabel}, Queue: ${hasQueueLabel}`);
+            core.setOutput('has_override', hasOverrideLabel ? 'true' : 'false');
 
-            // --- SYNCHRONIZE (New Commits) ---
-            if (eventName === 'pull_request_target' && payload.action === 'synchronize') {
-              core.info('[Router] Processing synchronize event (new commits).');
-              if (hasOverrideLabel) {
-                core.info('[Router] PR had override label. Removing it because of new commits.');
-                try {
-                  await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-override' });
-                  await github.rest.issues.createComment({
-                    owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number,
-                    body: '⚠️ **Audit Override Removed**\n\nNew commits were pushed to this PR, so the previous `releng-audit-override` has been removed.'
-                  });
-                } catch (e) {
-                  core.info(`[Router] Failed to remove override label: ${e.message}`);
-                }
+            // --- LABELED EVENTS ---
+            if (eventName === 'pull_request_target' && payload.action === 'labeled') {
+              const labelName = payload.label.name;
+              core.info(`[Router] Labeled event triggered for label '${labelName}' by @${actor}.`);
+
+              // The releng-audit-queue label acts as the primary trigger for manual retests
+              if (labelName === 'releng-audit-queue') {
+                core.info('[Router] Queue label detected. Stripping label and triggering audit...');
+                await removeLabelSafely('releng-audit-queue');
+                await triggerAuditRun('Running backport audit...');
+                return;
               }
 
-              if (hasFailLabel) {
-                core.info('[Router] PR is currently in a failed audit state. Halting automated checks until failure label is removed.');
-                core.setFailed("PR is currently in a failed audit state. Remove the releng-audit-fail label to re-run.");
+              // Handle authorized overrides applied via label or /audit override comment
+              if (labelName === 'releng-audit-override') {
+                core.info(`[Router] Evaluating override label application by @${actor}...`);
+                if (!isBot && !(await checkAuthorization(actor))) {
+                  core.error(`[Router] User @${actor} is not authorized to apply releng-audit-override. Removing label...`);
+                  await removeLabelSafely(labelName);
+                  core.error(`User @${actor} is not authorized to override audits.`);
+                } else {
+                  core.info(`[Router] Override authorized for @${actor}. Executing override state transition...`);
+                  // Execute override state transition without re-adding label (addLabel = false).
+                  // Only post a confirmation comment if applied by a human user in the UI (!isBot).
+                  await executeOverride(actor, false, !isBot);
+                }
                 core.setOutput('run_audit', 'false');
                 return;
               }
 
-              if (hasPassLabel) {
-                core.info('[Router] Removing pass label so PR reflects pending state.');
-                try { 
-                  await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-pass' }); 
-                } catch (e) {
-                  core.info(`[Router] Failed to remove pass label: ${e.message}`);
-                }
-              }
-
-              core.info('[Router] Triggering audit for new commits.');
-              core.setOutput('run_audit', 'true');
-              return;
-            }
-
-            // --- UNLABELED ---
-            if (eventName === 'pull_request_target' && payload.action === 'unlabeled') {
-              const removedLabel = payload.label.name;
-              core.info(`[Router] Processing unlabeled event for label: ${removedLabel}`);
-              if (['releng-audit-fail', 'releng-audit-pass', 'releng-audit-override'].includes(removedLabel)) {
-                if (isBot) {
-                  core.info(`[Router] Label ${removedLabel} removed by bot. Skipping audit trigger.`);
-                  core.setOutput('run_audit', 'false');
-                  return;
-                }
-                if (hasOverrideLabel && removedLabel === 'releng-audit-fail') {
-                  core.info(`[Router] PR has releng-audit-override but removed releng-audit-fail. Skipping audit.`);
-                  core.setOutput('run_audit', 'false');
-                  return;
-                }
-                
-                core.info(`[Router] User @${context.actor} removed ${removedLabel}. Stripping other state labels and triggering fresh audit.`);
-                try { await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-fail' }); } catch (e) {}
-                try { await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-pass' }); } catch (e) {}
-                core.setOutput('run_audit', 'true');
-                return;
-              }
-            }
-
-            // --- LABELED ---
-            if (eventName === 'pull_request_target' && payload.action === 'labeled') {
-              const labelName = payload.label.name;
-              core.info(`[Router] Processing labeled event for label: ${labelName} by actor: ${actor}`);
-              
-              // Block humans from applying machine labels
+              // Prevent unauthorized users from manually spoofing machine-owned state labels
               if (!isBot && (labelName === 'releng-audit-pass' || labelName === 'releng-audit-fail')) {
-                core.warning(`[Router] User @${actor} cannot manually apply ${labelName}.`);
-                try { await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-fail' }); } catch (e) {}
-                try { await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-pass' }); } catch (e) {}
-
-                if (hasOverrideLabel) {
-                  core.info(`[Router] override label applied, skipping audit.`);
-                  core.setOutput('run_audit', 'false');
+                core.warning(`[Router] User @${actor} cannot manually apply machine-owned label '${labelName}'. Removing...`);
+                await removeLabelSafely(labelName);
+                if (!hasOverrideLabel) {
+                  core.info('[Router] No override active. Triggering fresh audit run...');
+                  await triggerAuditRun('Running backport audit...');
                 } else {
-                  core.info(`[Router] forcing audit.`);
-                  core.setOutput('run_audit', 'true');
+                  core.info('[Router] Override is active. Skipping fresh audit run.');
                 }
                 return;
               }
 
-              // Enforce permissions for manual override label application
-              if (labelName === 'releng-audit-override') {
-                if (!isBot) {
-                  core.info(`[Router] Validating if user @${actor} is authorized to apply override.`);
-                  const isAuthorized = await checkAuthorization(actor);
-
-                  if (!isAuthorized) {
-                    core.info(`[Router] User @${actor} NOT authorized. Removing override label.`);
-                    await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: labelName });
-                    core.setFailed(`User @${actor} is not authorized to override audits.`);
-                  } else {
-                    core.info(`[Router] User @${actor} is authorized. Stripping fail/pass labels to visually unblock PR.`);
-                    try { await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-fail' }); } catch (e) {}
-                    try { await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-pass' }); } catch (e) {}
-                  }
-                } else {
-                  core.info(`[Router] Bot applied ${labelName}. Permitted.`);
-                }
-              }
-              
-              core.info(`[Router] Labeled event handled without triggering audit.`);
+              core.info(`[Router] Labeled event for '${labelName}' requires no action. Skipping.`);
               core.setOutput('run_audit', 'false');
               return;
             }
 
-            // --- OPENED / REOPENED ---
-            if (eventName === 'pull_request_target' && (payload.action === 'opened' || payload.action === 'reopened')) {
-              core.info(`[Router] PR ${payload.action}. Triggering audit.`);
-              
-              if (payload.action === 'reopened' && hasOverrideLabel) {
-                core.info('[Router] PR had override label. Removing it on reopen.');
+            // --- SYNCHRONIZE (New Commits) ---
+            // When new commits are pushed, existing overrides are revoked and audits re-evaluate.
+            // If the PR is already failed, execution halts to avoid comment spam until re-requested.
+            if (eventName === 'pull_request_target' && payload.action === 'synchronize') {
+              core.info('[Router] Processing synchronize event (new commits pushed)...');
+              if (hasOverrideLabel) {
+                core.info('[Router] PR had active override label. Revoking override due to new commits...');
+                await removeLabelSafely('releng-audit-override');
+                core.setOutput('has_override', 'false');
                 try {
-                  await github.rest.issues.removeLabel({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, name: 'releng-audit-override' });
+                  core.info('[Router] Posting override removal notification comment...');
                   await github.rest.issues.createComment({
                     owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number,
-                    body: '⚠️ **Audit Override Removed**\n\nThis PR was reopened, so the previous `releng-audit-override` has been removed.'
+                    body: `⚠️ **Audit Override Removed**\n\nNew commits were pushed to this PR, so the previous override has been removed.\n\n[View workflow run](${runUrl})`
                   });
+                  core.info('[Router] Override removal notification posted.');
                 } catch (e) {
-                  core.info(`[Router] Failed to remove override label: ${e.message}`);
+                  core.error(`[Router] Failed to post override removal comment: ${e.message}`);
                 }
               }
 
-              core.setOutput('run_audit', 'true');
+              if (hasFailLabel) {
+                core.warning("[Router] PR is currently in a failed audit state. Halting automated execution on synchronize.");
+                core.info("PR is currently in a failed audit state. Remove the releng-audit-fail label or comment /audit retest to re-run.");
+                const sha = await getPrSha();
+                if (sha) {
+                  core.info(`[Router] Setting commit status to 'failure' on new SHA ${sha}...`);
+                  await github.rest.repos.createCommitStatus({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    sha: sha,
+                    state: 'failure',
+                    context: 'Backport Audit',
+                    description: 'PR is in a failed audit state. Remove releng-audit-fail label or comment /audit retest to re-run.',
+                    target_url: runUrl
+                  });
+                }
+                core.setOutput('run_audit', 'false');
+                return;
+              }
+
+              await triggerAuditRun('Running backport audit...');
               return;
             }
 
-            core.info('[Router] Event did not match any trigger criteria. Skipping audit.');
+            // --- UNLABELED ---
+            // If a user manually strips a status label, trigger a fresh audit evaluation
+            if (eventName === 'pull_request_target' && payload.action === 'unlabeled') {
+              const removed = payload.label.name;
+              core.info(`[Router] Processing unlabeled event: label '${removed}' was removed by @${actor}.`);
+              if (['releng-audit-fail', 'releng-audit-pass', 'releng-audit-override'].includes(removed) && !isBot) {
+                if (hasOverrideLabel && removed === 'releng-audit-fail') {
+                  core.info('[Router] PR has active override label; ignoring manual removal of releng-audit-fail.');
+                  core.setOutput('run_audit', 'false');
+                  return;
+                }
+                core.info(`[Router] Status label '${removed}' removed by human. Triggering fresh audit evaluation...`);
+                await triggerAuditRun('Running backport audit...');
+                return;
+              } else {
+                core.info(`[Router] Unlabeled event for '${removed}' requires no action.`);
+              }
+            }
+
+            // --- OPENED / REOPENED ---
+            if (eventName === 'pull_request_target' && (payload.action === 'opened' || payload.action === 'reopened')) {
+              core.info(`[Router] Processing PR ${payload.action} event...`);
+              if (payload.action === 'reopened' && hasOverrideLabel) {
+                core.info('[Router] PR reopened with previous override label. Removing stale override...');
+                await removeLabelSafely('releng-audit-override');
+                core.setOutput('has_override', 'false');
+              }
+              await triggerAuditRun('Running backport audit...');
+              return;
+            }
+
+            core.info('[Router] Event did not match any active execution triggers. Skipping audit.');
             core.setOutput('run_audit', 'false');
 
       - name: Checkout Trusted Base Repository
@@ -258,7 +443,15 @@ jobs:
         uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           fetch-depth: 0
-          
+          ref: ${{ steps.router.outputs.checkout_ref || '' }}
+
+      - name: Fetch main for parity check
+        if: steps.router.outputs.run_audit == 'true'
+        # checkout only fetches the PR's base branch (e.g. squid/tentacle/umbrella).
+        # The parity check needs the main ref to walk the commit history graph and find the upstream
+        # merge commit for each cherry-pick, so fetch it explicitly as origin/main.
+        run: git fetch --no-tags origin +refs/heads/main:refs/remotes/origin/main
+
       - name: Setup Python
         if: steps.router.outputs.run_audit == 'true'
         uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
@@ -269,23 +462,81 @@ jobs:
         if: steps.router.outputs.run_audit == 'true'
         run: pip install GitPython python-redmine requests
 
-      - name: Run PTL Audit
+      - id: ptl_audit
+        name: Run PTL Audit
         if: steps.router.outputs.run_audit == 'true'
         env:
           PTL_TOOL_GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           PTL_TOOL_REDMINE_API_KEY: ${{ secrets.REDMINE_API_KEY_BACKPORT_BOT }}
           PTL_TOOL_BASE_PROJECT: ${{ github.repository_owner }}
           PTL_TOOL_BASE_REPO: ${{ github.event.repository.name }}
+          PTL_TOOL_PR_NUMBER: ${{ github.event.pull_request.number || github.event.issue.number }}
         run: |
-          PR_NUMBER="${{ github.event.pull_request.number || github.event.issue.number }}"
-          echo "Fetching latest labels for PR $PR_NUMBER to check for late-applied overrides..."
-          LABELS=$(curl -s -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
-            "https://api.github.com/repos/${{ github.repository }}/issues/$PR_NUMBER/labels" | jq -r '.[].name')
-          
-          if echo "$LABELS" | grep -q "releng-audit-override"; then
-            echo "PR has releng-audit-override. Skipping audit execution to prevent reapplying releng-audit-fail."
-            exit 0
-          fi
+          python src/script/ptl-tool.py --debug --ci-mode --audit
 
-          python src/script/ptl-tool.py --debug --ci-mode --audit $PR_NUMBER
+      - name: Report Audit Status & Update State Labels
+        if: always() && steps.router.outputs.run_audit == 'true' && steps.router.outputs.pr_sha != ''
+        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
+        with:
+          script: |
+            const statusContext = '${{ steps.router.outputs.status_context }}' || 'Backport Audit';
+            if (statusContext !== 'Backport Audit') {
+              core.info(`[Reporter] Non-standard audit run ('${statusContext}') — skipping state labels and commit status reporting.`);
+              return;
+            }
 
+            const outcome = '${{ steps.ptl_audit.outcome }}';
+            const eventName = context.eventName;
+            core.info(`[Reporter] Evaluating final audit outcome: '${outcome}' for standard audit run (event: ${eventName})...`);
+
+            let state = 'failure';
+            let description = 'Backport audit failed. See review comments or workflow logs.';
+
+            if (outcome === 'success') {
+              state = 'success';
+              description = 'Backport audit completed successfully.';
+              core.info('[Reporter] Audit completed successfully. Applying releng-audit-pass label...');
+              try {
+                await github.rest.issues.addLabels({
+                  owner: context.repo.owner, repo: context.repo.repo,
+                  issue_number: context.issue.number || context.payload.pull_request.number,
+                  labels: ['releng-audit-pass']
+                });
+                core.info('[Reporter] Successfully applied releng-audit-pass label.');
+              } catch (e) {
+                core.error(`[Reporter] Failed to add pass label: ${e.message}`);
+              }
+            } else if (outcome === 'cancelled') {
+              state = 'error';
+              description = 'Backport audit execution was cancelled.';
+              core.warning('[Reporter] Audit execution was cancelled.');
+            } else {
+              // outcome === 'failure'
+              core.info('[Reporter] Audit detected failures. Applying releng-audit-fail label...');
+              try {
+                await github.rest.issues.addLabels({
+                  owner: context.repo.owner, repo: context.repo.repo,
+                  issue_number: context.issue.number || context.payload.pull_request.number,
+                  labels: ['releng-audit-fail']
+                });
+                core.info('[Reporter] Successfully applied releng-audit-fail label.');
+              } catch (e) {
+                core.error(`[Reporter] Failed to add fail label: ${e.message}`);
+              }
+            }
+
+            try {
+              core.info(`[Reporter] Creating final commit status '${state}' for context '${statusContext}' on SHA '${{ steps.router.outputs.pr_sha }}'...`);
+              await github.rest.repos.createCommitStatus({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                sha: '${{ steps.router.outputs.pr_sha }}',
+                state: state,
+                context: statusContext,
+                description: description,
+                target_url: `https://github.com/${context.repo.owner}/${context.repo.repo}/actions/runs/${context.runId}`
+              });
+              core.info(`[Reporter] Set ${state} commit status (${statusContext}) on SHA: ${{ steps.router.outputs.pr_sha }}`);
+            } catch (e) {
+              core.error(`[Reporter] Failed to set final commit status: ${e.message}`);
+            }

.githubmap

@@ -8,6 +8,8 @@
 #
 #
 a2batic Kanika Murarka <kmurarka@redhat.com>
+aainscow Alex Ainscow <aainscow@uk.ibm.com>
+aaryanporwal Aaryan Porwal <aaryanporwal2233@gmail.com>
 aaSharma14 Aashish Sharma <aasharma@redhat.com>
 abhidesai6 Abhishek Desai <abhidesai6.ad@gmail.com>
 abhishek-kane Abhishek Kane <abhishek.kane@ibm.com> <abhishek.kane@gmail.com>
@@ -22,25 +24,36 @@ alimaredia Ali Maredia <amaredia@redhat.com>
 amathuria Aishwarya Mathuria <amathuri@redhat.com>
 amitkumar50 Amit Kumar <amitkuma@redhat.com>
 andrewschoen Andrew Schoen <aschoen@redhat.com>
+anoopcs9 Anoop C S <anoopcs@cryptolab.net>
+anthonyeleven Anthony D'Atri <anthony.datri@gmail.com>
 anuradhagadge Anuradha Gadge <Anuradha.Gadge@ibm.com>
-aaryanporwal Aaryan Porwal <aaryanporwal2233@gmail.com>
+AnuragRaut08 Anurag Raut <anuragtraut08@ibm.com>
+arbtfnf anuragbandhu <anuragbandhu007@gmail.com>
 asettle Alexandra Settle <asettle@suse.com>
+ashjosh1git Ashwin M Joshi <ashjosh1@in.ibm.com>
 athanatos Samuel Just <sjust@redhat.com>
 avanthakkar Avan Thakkar <athakkar@redhat.com>
-b-ranto Boris Ranto <branto@redhat.com>
 badone Brad Hubbard <bhubbard@redhat.com>
+baergj Joshua Baergen <jbaergen@digitalocean.com>
 baruza Barbora Ančincová <bara@redhat.com>
 bassamtabbara Bassam Tabbara <bassam.tabbara@quantum.com>
 batrick Patrick Donnelly <pdonnell@ibm.com>
+baum Alexander Indenbaum <aindenba@redhat.com>
+BBoozmen Oguzhan Ozmen <oozmen@bloomberg.net>
+benhanokh Gabriel Benhanokh <gbenhano@redhat.com>
 bigjust Justin Caratzas <jcaratza@redhat.com>
+bill-scales Bill Scales <bill_scales@uk.ibm.com>
 bk201 Kiefer Chang <kiefer.chang@suse.com>
 BlaineEXE Blaine Gardner <bgardner@suse.com>
 bluikko Ville Ojamo <git2233+ceph@ojamo.eu>
 branch-predictor Piotr Dałek <piotr.dalek@corp.ovh.com>
+b-ranto Boris Ranto <branto@redhat.com>
 bryanmontalvan Bryan Montalvan <bmontalv@redhat.com>
 callithea Laura Paduano <lpaduano@suse.com>
 capri1989 Kai Wagner <kwagner@suse.com>
+caroav Aviv Caro <Aviv.Caro@ibm.com>
 cbodley Casey Bodley <cbodley@redhat.com>
+cfsnyder Cory Snyder <csnyder@iland.com>
 chardan Jesse Williamson <jwilliamson@suse.de>
 chhabaramesh Ramesh Chander <Ramesh.Chander@sandisk.com>
 chrisphoffman Christopher Hoffman <choffman@redhat.com>
@@ -48,20 +61,24 @@ cloudbehl Ankush Behl <cloudbehl@gmail.com>
 CourtneyCCaldwell Courtney Caldwell <ccaldwel@redhat.com>
 Daniel-Pivonka Daniel Pivonka <dpivonka@redhat.com>
 ddiss David Disseldorp <ddiss@suse.de>
-devikab25 Devika Babrekar <devika.babrekar@ibm.com> 
+devikab25 Devika Babrekar <devika.babrekar@ibm.com>
 Devp00l Stephan Müller <smueller@suse.com>
 dillaman Jason Dillaman <dillaman@redhat.com>
 djgalloway David Galloway <dgallowa@redhat.com>
 dmick Dan Mick <dmick@redhat.com>
 dnyanee1997 Dnyaneshwari talwekar <dtalweka@redhat.com>
+dparmar18 Dhairya Parmar <dparmar@redhat.com>
 dragonylffly Li Wang <laurence.liwang@gmail.com>
 dsavineau Dimitri Savineau <dsavinea@redhat.com>
+dubeyko Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
 dvanders Dan van der Ster <dan.vanderster@clyso.com>
 dzafman David Zafman <dzafman@redhat.com>
+edwinzrodriguez Edwin Rodriguez <edwin.rodriguez1@ibm.com>
 emmericp Paul Emmerich <paul.emmerich@croit.io>
 epuertat Ernesto Puerta <epuertat@redhat.com>
 ErwanAliasr1 Erwan Velu <erwan@redhat.com>
 Exotelis Sebastian Krah <skrah@suse.com>
+ffilz Frank S. Filz <ffilzlnx@mindspring.com>
 fullerdj Douglas Fuller <dfuller@redhat.com>
 GabrielBrascher Gabriel Brascher <gabriel@apache.org>
 galsalomon66 Gal Salomon <gsalomon@redhat.com>
@@ -74,21 +91,27 @@ idryomov Ilya Dryomov <idryomov@redhat.com>
 ifed01 Igor Fedotov <ifedotov@suse.com>
 ivancich J. Eric Ivancich <ivancich@redhat.com>
 jan--f Jan Fajerski <jfajerski@suse.com>
+Jayaprakash-ibm Jaya Prakash Madaka <jayaprakash@ibm.com>
 jcsp John Spray <john.spray@redhat.com>
 jdurgin Josh Durgin <jdurgin@redhat.com>
 jecluis João Eduardo Luís <joao@suse.de>
 jmolmo Juan Miguel Olmo <jolmomar@redhat.com>
+jmundack Joseph Mundackal <jmundackal@bloomberg.net>
 joscollin Jos Collin <jcollin@redhat.com>
 josephsawaya Joseph Sawaya <jsawaya@redhat.com>
 jschmid1 Joshua Schmid <jschmid@suse.de>
 jtlayton Jeff Layton <jlayton@redhat.com>
 kalaspuffar Daniel Persson <mailto.woden@gmail.com>
+kamoltat Kamoltat Sirivadhna <ksirivad@redhat.com>
 karthik-us1 Karthik U S <karthik.u.s1@ibm.com>
+kchheda3 Krunal Chheda <kchheda3@bloomberg.net>
 knrt10 Kautilya Tripathi <kautilya.tripathi@ibm.com>
 kotreshhr Kotresh Hiremath Ravishankar <khiremat@redhat.com>
 kshtsk Kyr Shatskyy <kyrylo.shatskyy@suse.com>
 ktdreyer Ken Dreyer <kdreyer@redhat.com>
+Kushal-deb Kushal Deb <Kushal.Deb@ibm.com>
 LenzGr Lenz Grimmer <lgrimmer@suse.com>
+leonid-s-usov Leonid Usov <leonid.usov@ibm.com>
 leseb Sébastien Han <seb@redhat.com>
 liewegas Sage Weil <sage@redhat.com>
 liupan1111 Pan Liu <liupan1111@gmail.com>
@@ -99,27 +122,35 @@ markhpc Mark Nelson <mnelson@redhat.com>
 Matan-B Matan Breizman <mbreizma@redhat.com>
 mattbenjamin Matt Benjamin <mbenjami@redhat.com>
 mchangir Milind Changire <mchangir@redhat.com>
+mctaggatart Sage McTaggart <sagemct@ibm.com>
 melissa-kun-li Melissa Li <melissali@redhat.com>
 mgfritch Michael Fritch <mfritch@suse.com>
+mheler Matthew Heler <matthew.heler@hotmail.com>
 mikechristie Mike Christie <mchristi@redhat.com>
+mkogan1 Mark Kogan <mkogan@redhat.com>
+mmgaggle Kyle Bader <kbader@ibm.com>
 mogeb Mohamad Gebai <mgebai@suse.com>
 MrFreezeex Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@cern.ch>
 myoungwon Myoungwon Oh <myoungwon.oh@samsung.com>
-nmunet Naman Munet <nmunet@redhat.com>
 Naveenaidu Naveen Naidu <naveen.naidu@ibm.com>
+neesingh-rh Neeraj Pratap Singh <neesingh@redhat.com>
 neha-ojha Neha Ojha <nojha@redhat.com>
 NitzanMordhai Nitzan Mordechai <nmordech@redhat.com>
 nizamial09 Nizamudeen A <nia@redhat.com>
 nmshelke Nikhilkumar Shelke <nshelke@redhat.com>
-nSedrickm Ngwa Sedrick Meh <nsedrick101@gmail.com>
+nmunet Naman Munet <nmunet@redhat.com>
 noahdesu Noah Watkins <nwatkins@redhat.com>
+nSedrickm Ngwa Sedrick Meh <nsedrick101@gmail.com>
 oritwas Orit Wasserman <owasserm@redhat.com>
-p-na Patrick Nawracay <pnawracay@suse.com>
-p-se Patrick Seidensal <pseidensal@suse.com>
+parth-gr Parth Arora <paarora@redhat.com>
 pcuzner Paul Cuzner <pcuzner@redhat.com>
 Pegonzal Pedro Gonzalez Gomez <pegonzal@redhat.com>
 pereman2 Pere Diaz Bou <pdiazbou@redhat.com>
+petrutlucian94 Lucian Petrut <lpetrut@cloudbasesolutions.com>
+phlogistonjohn John Mulligan <jmulligan@redhat.com>
+p-na Patrick Nawracay <pnawracay@suse.com>
 prgoel-code Prachi prgoel@redhat.com
+p-se Patrick Seidensal <pseidensal@suse.com>
 pujaoshahu Puja Shahu <pshahu@redhat.com>
 rchagam Anjaneya Chagam <anjaneya.chagam@intel.com>
 renhwztetecs huanwen ren <ren.huanwen@zte.com.cn>
@@ -127,26 +158,33 @@ ricardoasmarques Ricardo Marques <rimarques@suse.com>
 rishabh-d-dave Rishabh Dave <ridave@redhat.com>
 rjfd Ricardo Dias <rdias@suse.com>
 rkachach Redouane Kachach <rkachach@redhat.com>
+robbat2 Robin H. Johnson <robbat2@orbis-terrarum.net>
 ronen-fr Ronen Friedman <rfriedma@redhat.com>
 runsisi luo runbing <luo.runbing@zte.com.cn>
 rzarzynski Radoslaw Zarzynski <rzarzyns@redhat.com>
 s0nea Tatjana Dehler <tdehler@suse.com>
 sagargopale2233 Sagar Gopale <sagar.gopale@ibm.com>
+salieri11 Igor Golikov <igolikov@ibm.com>
 Sarthak0702 Sarthak Gupta <sarthak.dev.0702@gmail.com>
 saschagrunert Sascha Grunert <sgrunert@suse.com>
 sebastian-philipp Sebastian Wagner <sewagner@redhat.com>
 shraddhaag Shraddha Agrawal <shraddhaag@ibm.com>
-Kushal-deb Kushal Deb <Kushal.Deb@ibm.com>
 ShwetaBhosale1 Shweta Bhosale <Shweta.Bhosale1@ibm.com>
+Shwetha-Acharya Shwetha Acharya <sacharya@redhat.com>
 ShyamsundarR Shyamsundar R <srangana@redhat.com>
 sidharthanup Sidharth Anupkrishnan <sanupkri@redhat.com>
+smanjara Shilpa Jagannath <smanjara@redhat.com>
 smithfarm Nathan Cutler <ncutler@suse.com>
+spuiuk Sachin Prabhu <sp@spui.uk>
 sunilangadi2 Sunil Angadi <Sunil.Angadi@ibm.com>
 sunnyku Sunny Kumar <sunkumar@redhat.com>
+synarete Shachar Sharon <ssharon@redhat.com>
 szuraski898 Steven Zuraski <steven.zuraski@ibm.com>
 taodd dongdong tao <tdd21151186@gmail.com>
 tchaikov Kefu Chai <k.chai@proxmox.com>
 theanalyst Abhishek Lekshmanan <abhishek.lekshmanan@gmail.com>
+Thingee Mike Perez <miperez@redhat.com>
+ThomasLamprecht Thomas Lamprecht <t.lamprecht@proxmox.com>
 toabctl Thomas Bechtold <tbechtold@suse.com>
 travisn Travis Nielsen <tnielsen@redhat.com>
 trociny Mykola Golub <mgolub@suse.com>
@@ -166,12 +204,13 @@ vumrao Vikhyat Umrao <vikhyat@redhat.com>
 Waadkh7 Waad Alkhoury <walkhour@redhat.com>
 wido Wido den Hollander <wido@42on.com>
 wjwithagen Willem Jan Withagen <wjw@digiware.nl>
+xhernandez Xavi Hernandez <xhernandez@gmail.com>
 xiaoxichen Xiaoxi Chen <superdebuger@gmail.com>
 xiexingguo xie xingguo <xie.xingguo@zte.com.cn>
 xxhdx1985126 Xuehan Xu <xuxuehan@360.cn>
 yaarith Yaarit Hatuka <yaarithatuka@gmail.com>
-Yan-waller yanjun <yan.jun8@zte.com.cn>
 yangdongsheng Dongsheng Yang <dongsheng.yang@easystack.cn>
+Yan-waller yanjun <yan.jun8@zte.com.cn>
 yehudasa Yehuda Sadeh <yehuda@redhat.com>
 yunfeiguan Yunfei Guan <yunfei.guan@xtaotech.com>
 yuriw Yuri Weinstein <yweins@redhat.com>
@@ -179,37 +218,3 @@ yuvalif Yuval Lifshitz <ylifshit@redhat.com>
 yuyuyu101 Haomai Wang <haomai@xsky.com>
 zdover23 Zac Dover <zac.dover@gmail.com>
 zmc Zack Cerza <zack@redhat.com>
-Thingee Mike Perez <miperez@redhat.com>
-cfsnyder Cory Snyder <csnyder@iland.com>
-benhanokh Gabriel Benhanokh <gbenhano@redhat.com>
-kamoltat Kamoltat Sirivadhna <ksirivad@redhat.com>
-anthonyeleven Anthony D Atri <anthony.datri@gmail.com>
-petrutlucian94 Lucian Petrut <lpetrut@cloudbasesolutions.com>
-dparmar18 Dhairya Parmar <dparmar@redhat.com>
-nmshelke Nikhilkumar Shelke <nshelke@redhat.com>
-neesingh-rh Neeraj Pratap Singh <neesingh@redhat.com>
-parth-gr Parth Arora <paarora@redhat.com>
-phlogistonjohn John Mulligan <jmulligan@redhat.com>
-baergj Joshua Baergen <jbaergen@digitalocean.com>
-zmc Zack Cerza <zack@redhat.com>
-robbat2 Robin H. Johnson <robbat2@orbis-terrarum.net>
-leonid-s-usov Leonid Usov <leonid.usov@ibm.com>
-ffilz Frank S. Filz <ffilzlnx@mindspring.com>
-Jayaprakash-ibm Jaya Prakash Madaka <jayaprakash@ibm.com>
-spuiuk Sachin Prabhu <sp@spui.uk>
-anoopcs9 Anoop C S <anoopcs@cryptolab.net>
-dubeyko Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
-bill-scales Bill Scales <bill_scales@uk.ibm.com>
-kchheda3 Krunal Chheda <kchheda3@bloomberg.net>
-Shwetha-Acharya Shwetha Acharya <sacharya@redhat.com>
-xhernandez Xavi Hernandez <xhernandez@gmail.com>
-ThomasLamprecht Thomas Lamprecht <t.lamprecht@proxmox.com>
-jmundack Joseph Mundackal <jmundackal@bloomberg.net>
-edwinzrodriguez Edwin Rodriguez <edwin.rodriguez1@ibm.com>
-synarete Shachar Sharon <ssharon@redhat.com>
-ashjosh1git Ashwin M Joshi <ashjosh1@in.ibm.com>
-mkogan1 Mark Kogan <mkogan@redhat.com>
-smanjara Shilpa Jagannath <smanjara@redhat.com>
-arbtfnf anuragbandhu <anuragbandhu007@gmail.com>
-aainscow Alex Ainscow <aainscow@uk.ibm.com>
-salieri11 Igor Golikov <igolikov@ibm.com>

.gitmodules

@@ -85,3 +85,6 @@
 [submodule "src/lss"]
 	path = src/lss
 	url = https://chromium.googlesource.com/linux-syscall-support
+[submodule "src/librdkafka"]
+	path = src/librdkafka
+	url = https://github.com/confluentinc/librdkafka.git

.mailmap

@@ -68,6 +68,7 @@ Anton Oks <anton.oks@gmx.de>
 Anton Turetckii <tyrchenok@gmail.com> banuchka <tyrchenok@gmail.com>
 Anuradha Gadge <anuradha.gadge@ibm.com> <anuradhagadge18@gmail.com>
 Anurag Bandhu <abandhu@redhat.com> <anurag@localhost.localdomain>
+Anurag Raut <anuragtraut08@ibm.com> <anuragtraut2003@gmail.com>
 Aravind Ramesh <Aravind.Ramesh@wdc.com> Aravind <aravind.ramesh@wdc.com>
 Aristoteles Neto <aristoteles.neto@webdrive.co.nz> <wdneto@users.noreply.github.com>
 Aron Gunn <ritz_303@yahoo.com>

.organizationmap

@@ -353,6 +353,7 @@ IBM <contact@IBM.com> Afreen Misbah <afreen@ibm.com>
 IBM <contact@IBM.com> Aliaksei Makarau <aliaksei.makarau@ibm.com>
 IBM <contact@IBM.com> Andrew Solomon <asolomon@us.ibm.com>
 IBM <contact@IBM.com> Anuradha Gadge <Anuradha.Gadge@ibm.com>
+IBM <contact@IBM.com> Anurag Raut <anuragtraut08@ibm.com>
 IBM <contact@IBM.com> Devika Babrekar <Devika.Babrekar@ibm.com>
 IBM <contact@IBM.com> Dnyaneshwari talwekar <Dnyaneshwari.Talwekar@ibm.com>
 IBM <contact@IBM.com> Guillaume Abrioux <gabrioux@ibm.com>

CMakeLists.txt

@@ -75,6 +75,20 @@ if(MINGW)
   link_directories(${MINGW_LINK_DIRECTORIES})
 endif()
 
+option(WITH_MOLD "Use the Mold linker" OFF)
+if(WITH_MOLD)
+  find_program(_mold_path mold REQUIRED)
+  message(STATUS "Mold linker: ${_mold_path}")
+  set(CMAKE_LINKER ${_mold_path} CACHE FILEPATH "Linker" FORCE)
+  set(MOLD_FUSE_LD_FLAG "-fuse-ld=mold" CACHE INTERNAL "")
+  foreach(_flags CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS)
+    if(NOT "${${_flags}}" MATCHES "fuse-ld=")
+      string(APPEND ${_flags} " ${MOLD_FUSE_LD_FLAG}")
+    endif()
+  endforeach()
+  set(USING_MOLD_LINKER TRUE CACHE INTERNAL "")
+endif()
+
 option(WITH_CCACHE "Build with ccache.")
 if(WITH_CCACHE)
   if(CMAKE_C_COMPILER_LAUNCHER OR CMAKE_CXX_COMPILER_LAUNCHER)
@@ -103,13 +117,13 @@ if(WITH_SCCACHE)
         ERROR_VARIABLE sccache_dist_status_error
         GET "${sccache_dist_status}" SchedulerStatus 1 num_cpus
       )
-      string(FIND "${sccache_dist_status}" "disabled" find_result)
-      if(find_result EQUAL -1)
+      if(sccache_dist_status_error)
+        message(WARNING "Using sccache, but it is not configured for distributed "
+          "compilation: ${sccache_dist_status_error}")
+      else()
         message(STATUS "Using sccache with distributed compilation. Effective cores: ${sccache_cores}")
         set(NINJA_MAX_COMPILE_JOBS ${sccache_cores})
         set(NINJA_MAX_LINK_JOBS ${sccache_cores})
-      else()
-        message(WARNING "Using sccache, but it is not configured for distributed complilation")
       endif()
     else()
       message(WARNING "Using sccache, but cannot determine maximum job value since cmake version is <3.19")
@@ -209,7 +223,6 @@ if(LINUX)
 elseif(FREEBSD)
   set(HAVE_UDEV OFF)
   set(HAVE_LIBAIO OFF)
-  set(HAVE_LIBDML OFF)
   set(HAVE_BLKID OFF)
   set(HAVE_KEYUTILS OFF)
 else()
@@ -290,13 +303,6 @@ if(WITH_LIBURING)
   endif()
 endif()
 
-CMAKE_DEPENDENT_OPTION(WITH_BLUESTORE_PMEM "Enable PMDK libraries" OFF
-  "WITH_BLUESTORE" OFF)
-if(WITH_BLUESTORE_PMEM)
-  find_package(dml)
-  set(HAVE_LIBDML ${DML_FOUND})
-endif()
-
 CMAKE_DEPENDENT_OPTION(WITH_RBD_MIRROR "Enable build for rbd-mirror daemon executable" OFF
     "WITH_RBD" OFF)
 
@@ -311,7 +317,7 @@ CMAKE_DEPENDENT_OPTION(WITH_RBD_SSD_CACHE "Enable librbd persistent write back c
     "WITH_RBD" OFF)
 
 CMAKE_DEPENDENT_OPTION(WITH_SYSTEM_PMDK "Require and build with system PMDK" OFF
-  "WITH_RBD_RWL OR WITH_BLUESTORE_PMEM" OFF)
+  "WITH_RBD_RWL" OFF)
 
 CMAKE_DEPENDENT_OPTION(WITH_RBD_UBBD "Enable ubbd support for rbd device utility" OFF
     "WITH_RBD" OFF)
@@ -321,10 +327,6 @@ if(WITH_RBD_UBBD)
   build_ubbd()
 endif()
 
-if(WITH_BLUESTORE_PMEM)
-  set(HAVE_BLUESTORE_PMEM ON)
-endif()
-
 CMAKE_DEPENDENT_OPTION(WITH_SPDK "Enable SPDK" OFF
   "CMAKE_SYSTEM_PROCESSOR MATCHES i386|i686|amd64|x86_64|AMD64|aarch64|riscv64" OFF)
 option(WITH_SYSTEM_SPDK "Require a system SPDK instead of building bundled src/spdk" OFF)
@@ -342,10 +344,10 @@ if(WITH_SPDK)
 endif(WITH_SPDK)
 
 if(WITH_BLUESTORE)
-  if(NOT AIO_FOUND AND NOT HAVE_POSIXAIO AND NOT WITH_SPDK AND NOT WITH_BLUESTORE_PMEM)
+  if(NOT AIO_FOUND AND NOT HAVE_POSIXAIO AND NOT WITH_SPDK)
     message(SEND_ERROR "WITH_BLUESTORE is ON, "
       "but none of the bluestore backends is enabled. "
-      "Please install libaio, or enable WITH_SPDK or WITH_BLUESTORE_PMEM (experimental)")
+      "Please install libaio, or enable WITH_SPDK")
   endif()
 endif()
 
@@ -460,6 +462,10 @@ if(ALLOCATOR)
   elseif(NOT ALLOCATOR STREQUAL "libc")
     message(FATAL_ERROR "Unsupported allocator selected: ${ALLOCATOR}")
   endif()
+elseif(WITH_ASAN)
+  # Force libc: tcmalloc/jemalloc still export operator new/delete even when the
+  # sanitizer shadows malloc, so sanitizer-allocated memory is freed via tcmalloc and SIGSEGVs.
+  set(ALLOCATOR "libc")
 else(ALLOCATOR)
   find_package(gperftools 2.6.2)
   set(HAVE_LIBTCMALLOC ${gperftools_FOUND})
@@ -569,12 +575,15 @@ option(WITH_RADOSGW "RADOS Gateway is enabled" ON)
 option(WITH_RADOSGW_BEAST_OPENSSL "RADOS Gateway's Beast frontend uses OpenSSL" ON)
 option(WITH_RADOSGW_AMQP_ENDPOINT "RADOS Gateway's pubsub support for AMQP push endpoint" ON)
 option(WITH_RADOSGW_KAFKA_ENDPOINT "RADOS Gateway's pubsub support for Kafka push endpoint" ON)
+option(WITH_SYSTEM_RDKAFKA "build against system librdkafka instead of the bundled submodule" OFF)
 option(WITH_RADOSGW_LUA_PACKAGES "RADOS Gateway's support for dynamically adding lua packagess" ON)
+option(WITH_RADOSGW_FDB "FoundationDB support for RADOS Gateway (experimental)" OFF)
 option(WITH_RADOSGW_DBSTORE "DBStore backend for RADOS Gateway" ON)
 option(WITH_RADOSGW_MOTR "CORTX-Motr backend for RADOS Gateway" OFF)
 option(WITH_RADOSGW_DAOS "DAOS backend for RADOS Gateway" OFF)
 option(WITH_RADOSGW_D4N "D4N wrapper for RADOS Gateway" ON)
-cmake_dependent_option(WITH_RADOSGW_POSIX "POSIX backend for RADOS Gateway" ON WITH_RADOSGW_DBSTORE OFF) # posix depends on dbstore
+option(WITH_RADOSGW_POSIX "POSIX backend for RADOS Gateway" ON)
+cmake_dependent_option(WITH_RADOSGW_STANDALONE "Standalone RADOS Gateway" ON WITH_RADOSGW_POSIX OFF)
 option(WITH_RADOSGW_RADOS "RADOS backend for Rados Gateway" ON)
 option(WITH_RADOSGW_SELECT_PARQUET "Support for s3 select on parquet objects" ON)
 option(WITH_RADOSGW_ARROW_FLIGHT "Build arrow flight when not using system-provided arrow" OFF)
@@ -583,6 +592,9 @@ option(WITH_RADOSGW_BACKTRACE_LOGGING "Enable backtraces in rgw logs" OFF)
 option(WITH_SYSTEM_ARROW "Use system-provided arrow" OFF)
 option(WITH_SYSTEM_UTF8PROC "Use system-provided utf8proc" OFF)
 
+# POSIX depends on DBStore:
+cmake_dependent_option(WITH_RADOSGW_POSIX "POSIX backend for RADOS Gateway" ON WITH_RADOSGW_DBSTORE OFF) 
+
 if(WITH_RADOSGW)
   find_package(EXPAT REQUIRED)
   find_package(OATH REQUIRED)
@@ -636,6 +648,23 @@ if(WITH_RADOSGW)
   message(STATUS "crypto soname: ${LIBCRYPTO_SONAME}")
 endif (WITH_RADOSGW)
 
+if(WITH_RADOSGW_FDB)
+ include(${CMAKE_MODULE_PATH}/CPM.cmake)
+
+ CPMAddPackage("gh:eyalz800/zpp_bits@4.5.1")
+ message("-- enabled zpp_bits")
+
+# JFW: sadly, I'm having trouble getting FoundationDB to build, but this is VERY close
+# to "just working". But, how would we install the RPMs, etc.? This will need looking at
+# before this can be non-experimental:
+# CPMAddPackage("gh:apple/foundationdb@7.3.63")
+ message("FoundationDB support is EXPERIMENTAL and requires manual setup:")
+ message(" wget https://github.com/apple/foundationdb/releases/download/7.3.63/foundationdb-clients-7.3.63-1.el7.x86_64.rpm")
+ message(" wget https://github.com/apple/foundationdb/releases/download/7.3.63/foundationdb-server-7.3.63-1.el7.x86_64.rpm")
+ message("-- enabled FoundationDB (whether its there or not)")
+
+endif()
+
 #option for CephFS
 option(WITH_CEPHFS "CephFS is enabled" ON)
 
@@ -720,6 +749,13 @@ endif(LINUX)
 option(WITH_ASAN "build with ASAN" OFF)
 if(WITH_ASAN)
   list(APPEND sanitizers "address")
+  # Shared ASan/LSan runtime options: the in-tree suppression files plus the
+  # flags our tests need.  Consumed by add_ceph_test() and baked into bin/ceph
+  # so both ignore the same still-reachable third-party leaks.
+  set(CEPH_ASAN_OPTIONS "suppressions=${CMAKE_SOURCE_DIR}/qa/asan.supp,detect_odr_violation=0"
+      CACHE INTERNAL "ASAN_OPTIONS for ceph tests and the ceph CLI")
+  set(CEPH_LSAN_OPTIONS "suppressions=${CMAKE_SOURCE_DIR}/qa/lsan.supp,print_suppressions=0"
+      CACHE INTERNAL "LSAN_OPTIONS for ceph tests and the ceph CLI")
 endif()
 
 option(WITH_ASAN_LEAK "explicitly enable ASAN leak detection" OFF)
@@ -817,6 +853,12 @@ else()
   include(BuildBoost)
   build_boost(1.87
     COMPONENTS ${BOOST_COMPONENTS} ${BOOST_HEADER_COMPONENTS})
+  if(WITH_ASAN)
+    # Boost.Context is built ucontext-only here (context-impl=ucontext); define
+    # the matching backend tree-wide so every Boost.Context/Coroutine2 consumer
+    # agrees on it, instead of relying on per-target propagation that is easy to miss.
+    add_compile_definitions(BOOST_USE_ASAN BOOST_USE_UCONTEXT)
+  endif()
 endif()
 include_directories(BEFORE SYSTEM ${Boost_INCLUDE_DIRS})
 add_library(Boost::asio INTERFACE IMPORTED)
@@ -893,4 +935,3 @@ add_tags(ctags
   EXCLUDE_OPTS ${CTAG_EXCLUDES}
   EXCLUDES "*.js" "*.css" ".tox" "python-common/build")
 add_custom_target(tags DEPENDS ctags)
-

Dockerfile.build

@@ -36,7 +36,9 @@ RUN DISTRO=$DISTRO \
     FOR_MAKE_CHECK=${FOR_MAKE_CHECK} \
     bash -x ${CEPH_CTR_SRC}/buildcontainer-setup.sh
 RUN \
-    if [ $(uname -m) != ppc64le ]; then \
+    if rpm --quiet --query sccache 2>/dev/null || { command -v dnf >/dev/null 2>&1 && dnf install -y sccache 2>/dev/null; }; then \
+    echo "sccache provided by distro packages"; \
+    elif [ $(uname -m) != ppc64le ]; then \
     SCCACHE_ARCH="$(uname -m)"; \
     if [ "$SCCACHE_ARCH" = riscv64 ]; then SCCACHE_ARCH=riscv64gc; fi; \
     SCCACHE_URL="${SCCACHE_REPO}/releases/download/${SCCACHE_VERSION}/sccache-${SCCACHE_VERSION}-${SCCACHE_ARCH}-unknown-linux-musl.tar.gz"; \

PendingReleaseNotes

@@ -1,3 +1,22 @@
+* CephFS: The ``client_force_lazyio`` configuration option is now correctly marked
+  as not supporting runtime updates. Previously, the configuration schema indicated
+  this option could be changed at runtime, but changes had no effect on opened file
+  handlers in ceph-fuse or libcephfs clients because there is no logic to propagate
+  changes to open file handles.
+
+* RADOS: PG autoscaler allows overlapping roots. Each root receives a PG target based
+  on its OSDs, with OSDs shared across multiple roots contributing proportionally
+  less to each root's allocation.
+  
+* CephFS: CephFS snapshots metadata is now mutable. It is now possible to add,
+  update and remove existing key-value pairs that are part of a snapshot
+  metadata via libcephfs API ceph_do_snap_md_op().
+
+* CephFS: MDS dmclock support for subvolume QoS. With this feature, MDS assigns QoS
+  to throttle client metadata requests (e.g., create, mkdir, lookup, and so on) to
+  subvolumes, where each subvolume QoS is shared among multiple client sessions at
+  that time.
+
 * librados/neorados: The C++ APIs for executing Ceph Class (CLS) methods
   have undergone a breaking change to enforce compile-time type safety, replacing
   legacy string-based parameters with strongly-typed ClsMethod structs. C++
@@ -17,6 +36,8 @@
   - The `rgw default data log backing` option is removed and it is no longer
     possible to create clusters with an omap based datalog.
   - `radosgw-admin datalog type` will only accept `--log_type=fifo`.
+* RGW: iam:RemoveClientIdFromOIDCProvider is now a recognized action for
+  policy, corrected from a typo of iam:RemoveCientIdFromOIDCProvider
 
 * MGR: The default values of ``mon_target_pg_per_osd`` and ``mon_max_pg_per_osd``
   have been increased from 100 and 250 to 200 and 500, respectively. These values
@@ -47,6 +68,12 @@
     If the default provider is required when also using custom providers,
     it must be explicitly loaded in the configuration file or code (see https://github.com/openssl/openssl/blob/master/README-PROVIDERS.md).
 * RGW: Fixed bucket notification events so the 'x_amz_request_id' in NotificationEvent now matches the 'x_amz_request_id' returned by the corresponding S3 operation.
+* RGW: The rgw_gc_max_deferred and rgw_gc_max_deferred_entries_size options have been removed, as they did not do anything.
+  - Updated the default for rgw_gc_max_queue_size to account for the extra space from removing rgw_gc_max_deferred_entries_size.
+* RGW: The default value of ``rgw_thread_pool_size`` has been reduced from 512 to 128.
+  Benchmarks showed that the lower thread count improves throughput and reduces latency
+  on NVMe and HDD based environments. Users with specific workload requirements can
+  tune this value; see also ``rgw_max_concurrent_requests``.
 
 
 * DASHBOARD: A new Overview landing page provides an at-a-glance cluster summary
@@ -165,6 +192,35 @@
   ``ceph fs snapshot mirror daemon status`` now shows the remote cluster's
   monitor addresses and cluster ID for each configured peer, making it easier
   to verify peer connectivity and troubleshoot mirroring issues.
+* CephFS Mirroring: The ``fs mirror peer status`` admin socket command reports
+  additional per-directory sync metrics (sync mode, throughput, crawl and
+  data-sync queue timing, bytes/files progress, and ETA). Output is grouped
+  under ``metrics/<mirrored-dir-path>/peer/<peer-uuid>``. For more information,
+  see https://tracker.ceph.com/issues/73453
+* CephFS Mirroring: Per-directory snapshot sync progress is exposed as labeled perf
+  counters in the ``cephfs_mirror_directory`` group (``counter dump`` on the mirror
+  daemon admin socket, exportable via ``ceph-exporter``). Counters mirror
+  ``fs mirror peer status`` fields (directory state, current sync, last sync, and
+  snap summary) and are labeled by peer UUID and mirrored directory path. See
+  https://tracker.ceph.com/issues/73457
+* CephFS Mirroring: The mirroring module provides ``ceph fs snapshot mirror status``,
+  a Ceph CLI command similar to the ``fs mirror peer status`` admin socket interface
+  for viewing per-directory snapshot sync metrics. The output layout matches
+  ``fs mirror peer status`` for core sync fields and additionally includes
+  ``metrics_updated_at`` (time of the last omap write). Optional filters by
+  mirrored directory path and peer UUID are supported. For more information,
+  see https://tracker.ceph.com/issues/76686
+* CephFS Mirroring: Introduced snapshot checkpoints feature that allows users to mark
+  specific snapshots as important milestones and track their replication status to remote
+  sites. Checkpoints automatically detect if a snapshot has already been synced and provide
+  visibility into disaster recovery readiness. The feature includes four new CLI commands:
+  ``ceph fs snapshot mirror checkpoint add`` to mark a snapshot,
+  ``ceph fs snapshot mirror checkpoint now`` to checkpoint the latest snapshot,
+  ``ceph fs snapshot mirror checkpoint ls`` to list all checkpoints with their status
+  (created/complete/failed), and ``ceph fs snapshot mirror checkpoint remove`` to remove
+  a checkpoint. Checkpoint metadata is persistent across daemon restarts. This feature is
+  useful for compliance auditing, application consistency verification, and SLA tracking.
+  For more information, see https://tracker.ceph.com/issues/73454
 * RBD: Mirror snapshot creation and trash purge schedules are now automatically
   staggered when no explicit "start-time" is specified. This reduces scheduling
   spikes and distributes work more evenly over time.
@@ -175,6 +231,17 @@
   than instantly aborting I/O and returning an error. It's possible to switch
   from ``RBD_LOCK_MODE_EXCLUSIVE`` to ``RBD_LOCK_MODE_EXCLUSIVE_TRANSIENT``
   policy and vice versa even if the lock is already held.
+* RGW: In multisite deployments, zone endpoints configured in the zonegroup
+  (e.g. ``https://zone-a.example.com``) can now be resolved to all IP addresses
+  returned by DNS, with inter-zone traffic distributed across them using
+  round-robin and per-IP health tracking. This enables DNS-based service discovery
+  for inter-zone traffic without an external load balancer. This feature is disabled
+  by default: to opt in, set ``rgw_rest_conn_connect_to_resolved_ips = true``. The
+  per-IP retry-after-failure timeout is controlled by ``rgw_rest_conn_ip_fail_timeout_secs``
+  (default: 2 seconds). Deployments that work around libcurl's single-address behavior
+  by repeating the same endpoint multiple times in zone configuration should review that
+  setup before enabling, as round-robin distribution makes such duplication unnecessary.
+
 * OSD: A health warning is reported when BlueFS usage exceeds the
   configured ratio of the main OSD data device size. This warning is
   informational and can be muted with:
@@ -196,6 +263,28 @@
   state and a subsequent redundancy loss occurs. Used in conjunction with
   ``last_clean``, the ``last_degraded`` timestamp enables the calculation of
   data vulnerability and durability scores.
+* RBD: It's possible to specify source cluster's ``mon_host`` and ``key`` for
+  ``native`` format migration via the migration spec now.  This eliminates the
+  dependency on ``<cluster-name>.conf`` file in a known location which is
+  rather rigid and also challenging to disseminate in some environments.  The
+  key can be embedded in the migration spec or just referenced from there while
+  stored in the MON config-key store.
+* RBD: `Group::list_images` python API will now correctly raise an ObjectNotFound
+  error when invoked on a non-existent group. The C APIs `rbd_group_image_list`,
+  `rbd_snap_list`, `rbd_group_snap_list` and C++ API `group_image_list` will now
+  return ENOENT instead of masking the error and returning 0.
+* BlueStore: The experimental PMEM device backend has been removed, together
+  with the ``pmem`` value of the ``bdev_type`` option and the DML/DSA offload
+  path. The hardware it targeted, Intel Optane DC persistent memory, was
+  discontinued in 2022. The RBD persistent write-back cache, which also uses
+  PMDK, is unaffected.
+
+  Existing OSDs backed by persistent memory in fsdax mode (a block device such
+  as ``/dev/pmem0``) keep working on the default ``aio`` backend over the same
+  data. Remove any explicit ``bdev_type = pmem`` from their configuration. OSDs
+  on a devdax namespace (a character device such as ``/dev/dax0.0``) will no
+  longer start, because no remaining backend can open one; reconfigure the
+  namespace to fsdax with ``ndctl`` or re-provision them before upgrading.
 
 >=20.0.0
 
@@ -429,6 +518,9 @@
   to upgrade all OSDs in the cluster. For more details see tracker:
   https://tracker.ceph.com/issues/73031.
 
+* NFS: cluster/export delete commands now throw a deprecation warning when
+       used and will be removed in V release. 
+
 >=19.2.1
 
 * CephFS: The `fs subvolume create` command now allows tagging subvolumes through option
@@ -996,3 +1088,13 @@ can be configured using the `rgw` option `rgw_bucket_persistent_notif_num_shards
   https://docs.ceph.com/en/latest/radosgw/notifications/
 
 Relevant tracker: https://tracker.ceph.com/issues/71677
+
+* RGW: Multipart upload part heads are now tracked under a new
+  ``rgw.multipart`` category in bucket stats, separate from completed
+  objects (``rgw.main``). This makes ``radosgw-admin bucket stats``
+  and the ``X-RGW-Object-Count`` header on HEAD Bucket more accurate:
+  in-progress or abandoned multipart parts no longer inflate the
+  object count. Existing in-progress uploads retain the old category
+  until they complete or abort.
+
+  Relevant tracker: https://tracker.ceph.com/issues/77509

admin/doc-read-the-docs.txt

@@ -1,2 +1 @@
 plantweb
-readthedocs-sphinx-search@git+https://github.com/readthedocs/readthedocs-sphinx-search@main

cmake/modules/AddCephTest.cmake

@@ -33,8 +33,8 @@ function(add_ceph_test test_name test_path)
     set_property(TEST ${test_name}
       APPEND
       PROPERTY ENVIRONMENT
-      ASAN_OPTIONS=suppressions=${CMAKE_SOURCE_DIR}/qa/asan.supp,detect_odr_violation=0
-      LSAN_OPTIONS=suppressions=${CMAKE_SOURCE_DIR}/qa/lsan.supp,print_suppressions=0)
+      ASAN_OPTIONS=${CEPH_ASAN_OPTIONS}
+      LSAN_OPTIONS=${CEPH_LSAN_OPTIONS})
   endif()
   set_property(TEST ${test_name}
     PROPERTY TIMEOUT ${CEPH_TEST_TIMEOUT})
@@ -73,8 +73,11 @@ if(WITH_GTEST_PARALLEL)
       BUILD_COMMAND ""
       INSTALL_COMMAND "")
     add_dependencies(tests gtest-parallel_ext)
+    # CACHE INTERNAL: the set() runs only in the first directory to create the
+    # target, so a plain variable would be invisible to PARALLEL tests elsewhere.
     set(GTEST_PARALLEL_COMMAND
-      ${Python3_EXECUTABLE} ${gtest_parallel_source_dir}/gtest-parallel)
+      ${Python3_EXECUTABLE} ${gtest_parallel_source_dir}/gtest-parallel
+      CACHE INTERNAL "command to run a gtest binary through gtest-parallel")
   endif()
 endif()
 

cmake/modules/BuildBoost.cmake

@@ -144,15 +144,26 @@ function(do_build_boost root_dir version)
   if(WITH_BOOST_VALGRIND)
     list(APPEND b2 valgrind=on)
   endif()
+  set(b2_targets headers stage)
+  set(b2_install_targets install)
   if(WITH_ASAN)
     list(APPEND b2 context-impl=ucontext)
+    # build the library with the BOOST_USE_ASAN consumers get from Boost::context,
+    # so fiber_activation_record has one layout (else heap-buffer-overflow)
+    list(APPEND b2 define=BOOST_USE_ASAN)
+    # `context-impl` is declared in libs/context/build/Jamfile.v2; the headers/stage
+    # and install targets never load it, so b2 aborts with `unknown feature
+    # "<context-impl>"`. Name the context project as a target so its Jamfile loads
+    # the feature first.
+    list(PREPEND b2_targets libs/context/build)
+    list(PREPEND b2_install_targets libs/context/build)
   endif()
   set(build_command
-    ${b2} headers stage
+    ${b2} ${b2_targets}
     #"--buildid=ceph" # changes lib names--can omit for static
     ${boost_features})
   set(install_command
-    ${b2} install)
+    ${b2} ${b2_install_targets})
   if(EXISTS "${PROJECT_SOURCE_DIR}/src/boost/bootstrap.sh")
     check_boost_version("${PROJECT_SOURCE_DIR}/src/boost" ${version})
     set(source_dir
@@ -254,10 +265,8 @@ macro(build_boost version)
       set_target_properties(Boost::${c} PROPERTIES
         INTERFACE_COMPILE_DEFINITIONS "BOOST_USE_VALGRIND")
     endif()
-    if((c MATCHES "context") AND (WITH_ASAN))
-      set_target_properties(Boost::${c} PROPERTIES
-        INTERFACE_COMPILE_DEFINITIONS "BOOST_USE_ASAN;BOOST_USE_UCONTEXT")
-    endif()
+    # ASan's BOOST_USE_ASAN/BOOST_USE_UCONTEXT are defined tree-wide in the
+    # top-level CMakeLists.txt, not per-target.
     list(APPEND Boost_LIBRARIES ${Boost_${upper_c}_LIBRARY})
   endforeach()
   foreach(c ${Boost_BUILD_COMPONENTS})

cmake/modules/BuildFIO.cmake

@@ -30,10 +30,10 @@ function(build_fio)
   file(MAKE_DIRECTORY ${source_dir})
   ExternalProject_Add(fio_ext
     UPDATE_COMMAND "" # this disables rebuild on each run
-    GIT_REPOSITORY "https://github.com/ceph/fio.git"
+    GIT_REPOSITORY "https://github.com/axboe/fio.git"
     GIT_CONFIG advice.detachedHead=false
     GIT_SHALLOW 1
-    GIT_TAG "fio-3.27-cxx"
+    GIT_TAG "fio-3.42"
     SOURCE_DIR ${source_dir}
     BUILD_IN_SOURCE 1
     CONFIGURE_COMMAND <SOURCE_DIR>/configure

cmake/modules/Buildpmdk.cmake

@@ -1,4 +1,4 @@
-function(build_pmdk enable_ndctl)
+function(build_pmdk)
   include(FindMake)
   find_make("MAKE_EXECUTABLE" "make_cmd")
 
@@ -15,12 +15,6 @@ function(build_pmdk enable_ndctl)
   endif()
 
   set(LIBPMEM_INTERFACE_LINK_LIBRARIES Threads::Threads)
-  if(${enable_ndctl})
-    set(ndctl "y")
-    list(APPEND LIBPMEM_INTERFACE_LINK_LIBRARIES ndctl::ndctl daxctl::daxctl)
-  else()
-    set(ndctl "n")
-  endif()
 
   # Use debug PMDK libs in debug lib/rbd builds
   if(CMAKE_BUILD_TYPE STREQUAL Debug)
@@ -34,7 +28,7 @@ function(build_pmdk enable_ndctl)
   ExternalProject_Add(pmdk_ext
       ${source_dir_args}
       CONFIGURE_COMMAND ""
-      BUILD_COMMAND ${make_cmd} CC=${CMAKE_C_COMPILER} "EXTRA_CFLAGS=${pmdk_cflags}" NDCTL_ENABLE=${ndctl} BUILD_EXAMPLES=n BUILD_BENCHMARKS=n DOC=n
+      BUILD_COMMAND ${make_cmd} CC=${CMAKE_C_COMPILER} "EXTRA_CFLAGS=${pmdk_cflags}" NDCTL_ENABLE=n BUILD_EXAMPLES=n BUILD_BENCHMARKS=n DOC=n
       BUILD_IN_SOURCE 1
       BUILD_BYPRODUCTS "<SOURCE_DIR>/src/${PMDK_LIB_DIR}/libpmem.a" "<SOURCE_DIR>/src/${PMDK_LIB_DIR}/libpmemobj.a"
       INSTALL_COMMAND "")

cmake/modules/CephChecks.cmake

@@ -202,3 +202,12 @@ try_compile(HAVE_LINK_EXCLUDE_LIBS
   ${CMAKE_CURRENT_BINARY_DIR}
   SOURCES ${CMAKE_CURRENT_LIST_DIR}/CephCheck_link.c
   LINK_LIBRARIES "-Wl,--exclude-libs,ALL")
+
+# Mold linker applies --exclude-libs after version script processing,
+# which hides .symver-aliased symbols (e.g. rados_*) even when the
+# version script lists them as global.  Disable --exclude-libs for Mold;
+# version scripts already control symbol visibility.
+if(HAVE_LINK_EXCLUDE_LIBS AND USING_MOLD_LINKER)
+  message(STATUS "Mold linker -- disabling --exclude-libs (incompatible with .symver)")
+  set(HAVE_LINK_EXCLUDE_LIBS FALSE CACHE INTERNAL "" FORCE)
+endif()

cmake/modules/Distutils.cmake

@@ -72,7 +72,11 @@ function(distutils_add_cython_module target name src)
   list(APPEND PY_CPPFLAGS -D'__Pyx_check_single_interpreter\(ARG\)=ARG\#\#0')
   set(PY_CC ${compiler_launcher} ${CMAKE_C_COMPILER} ${c_compiler_arg1})
   set(PY_CXX ${compiler_launcher} ${CMAKE_CXX_COMPILER} ${cxx_compiler_arg1})
-  set(PY_LDSHARED ${link_launcher} ${CMAKE_C_COMPILER} ${c_compiler_arg1} "-shared")
+  if(USING_MOLD_LINKER)
+    set(PY_LDSHARED ${link_launcher} ${CMAKE_C_COMPILER} ${c_compiler_arg1} "-shared" "${MOLD_FUSE_LD_FLAG}")
+  else()
+    set(PY_LDSHARED ${link_launcher} ${CMAKE_C_COMPILER} ${c_compiler_arg1} "-shared")
+  endif()
   string(REPLACE " " ";" PY_LDFLAGS "${CMAKE_SHARED_LINKER_FLAGS}")
   list(APPEND PY_LDFLAGS -L${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
 
@@ -117,7 +121,11 @@ function(distutils_install_cython_module name)
   get_property(compiler_launcher GLOBAL PROPERTY RULE_LAUNCH_COMPILE)
   get_property(link_launcher GLOBAL PROPERTY RULE_LAUNCH_LINK)
   set(PY_CC "${compiler_launcher} ${CMAKE_C_COMPILER}")
-  set(PY_LDSHARED "${link_launcher} ${CMAKE_C_COMPILER} -shared")
+  if(USING_MOLD_LINKER)
+    set(PY_LDSHARED "${link_launcher} ${CMAKE_C_COMPILER} -shared ${MOLD_FUSE_LD_FLAG}")
+  else()
+    set(PY_LDSHARED "${link_launcher} ${CMAKE_C_COMPILER} -shared")
+  endif()
   set(PY_LDFLAGS "${CMAKE_SHARED_LINKER_FLAGS} -L${CMAKE_LIBRARY_OUTPUT_DIRECTORY}")
   cmake_parse_arguments(DU "DISABLE_VTA" "" "" ${ARGN})
   if(DU_DISABLE_VTA AND HAS_VTA)

cmake/modules/Finddaxctl.cmake

@@ -1,42 +0,0 @@
-# - Find libdaxctl
-# Find the daxctl libraries and includes
-#
-# daxctl_INCLUDE_DIR - where to find libdaxctl.h etc.
-# daxctl_LIBRARIES - List of libraries when using daxctl.
-# daxctl_FOUND - True if daxctl found.
-
-find_path(daxctl_INCLUDE_DIR daxctl/libdaxctl.h)
-
-if(daxctl_INCLUDE_DIR AND EXISTS "${daxctl_INCLUDE_DIR}/libdaxctl.h")
-  foreach(ver "MAJOR" "MINOR" "RELEASE")
-    file(STRINGS "${daxctl_INCLUDE_DIR}/libdaxctl.h" daxctl_VER_${ver}_LINE
-      REGEX "^#define[ \t]+daxctl_VERSION_${ver}[ \t]+[0-9]+[ \t]+.*$")
-    string(REGEX REPLACE "^#define[ \t]+daxctl_VERSION_${ver}[ \t]+([0-9]+)[ \t]+.*$"
-      "\\1" daxctl_VERSION_${ver} "${daxctl_VER_${ver}_LINE}")
-    unset(${daxctl_VER_${ver}_LINE})
-  endforeach()
-  set(daxctl_VERSION_STRING
-    "${daxctl_VERSION_MAJOR}.${daxctl_VERSION_MINOR}.${daxctl_VERSION_RELEASE}")
-endif()
-
-find_library(daxctl_LIBRARY daxctl)
-
-include(FindPackageHandleStandardArgs)
-find_package_handle_standard_args(daxctl
-  REQUIRED_VARS daxctl_LIBRARY daxctl_INCLUDE_DIR
-  VERSION_VAR daxctl_VERSION_STRING)
-
-mark_as_advanced(daxctl_INCLUDE_DIR daxctl_LIBRARY)
-
-if(daxctl_FOUND)
-  set(daxctl_INCLUDE_DIRS ${daxctl_INCLUDE_DIR})
-  set(daxctl_LIBRARIES ${daxctl_LIBRARY})
-  if(NOT (TARGET daxctl::daxctl))
-    add_library(daxctl::daxctl UNKNOWN IMPORTED)
-    set_target_properties(daxctl::daxctl PROPERTIES
-      INTERFACE_INCLUDE_DIRECTORIES "${daxctl_INCLUDE_DIRS}"
-      IMPORTED_LINK_INTERFACE_LANGUAGES "C"
-      IMPORTED_LOCATION "${daxctl_LIBRARIES}"
-      VERSION "${daxctl_VERSION_STRING}")
-  endif()
-endif()

cmake/modules/Finddml.cmake

@@ -1,58 +0,0 @@
-# - Find libdml
-# Find the dml and dmlhl libraries and includes
-#
-# DML_INCLUDE_DIR - where to find dml.hpp etc.
-# DML_LIBRARIES - List of libraries when using dml.
-# DML_HL_LIBRARIES - List of libraries when using dmlhl.
-# DML_FOUND - True if DML found.
-
-
-find_path(DML_INCLUDE_DIR
-  dml/dml.hpp
-  PATHS
-  /usr/include
-  /usr/local/include)
-
-find_library(DML_LIBRARIES NAMES dml libdml PATHS
-  /usr/local/
-  /usr/local/lib64
-  /usr/lib64
-  /usr/lib)
-
-find_library(DML_HL_LIBRARIES NAMES dmlhl libdmlhl PATHS
-  /usr/local/
-  /usr/local/lib64
-  /usr/lib64
-  /usr/lib)
-
-include(FindPackageHandleStandardArgs)
-find_package_handle_standard_args(dml DEFAULT_MSG
-  DML_LIBRARIES
-  DML_INCLUDE_DIR
-  DML_HL_LIBRARIES)
-
-mark_as_advanced(
-  DML_LIBRARIES
-  DML_INCLUDE_DIR
-  DML_HL_LIBRARIES)
-
-if(DML_FOUND)
-  if(NOT (TARGET dml::dml))
-    add_library(dml::dml UNKNOWN IMPORTED)
-    set_target_properties(dml::dml PROPERTIES
-      INTERFACE_INCLUDE_DIRECTORIES "${DML_INCLUDE_DIR}"
-      IMPORTED_LINK_INTERFACE_LANGUAGES "C"
-      IMPORTED_LOCATION "${DML_LIBRARIES}")
-  endif()
-
-  if(NOT (TARGET dml::dmlhl))
-    add_library(dml::dmlhl UNKNOWN IMPORTED)
-    set_target_properties(dml::dmlhl PROPERTIES
-      INTERFACE_INCLUDE_DIRECTORIES "${DML_INCLUDE_DIR}"
-      INTERFACE_LINK_LIBRARIES ${CMAKE_DL_LIBS}
-      INTERFACE_COMPILE_FEATURES cxx_std_17
-      INTERFACE_COMPILE_DEFINITIONS "DML_HW"
-      IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"
-      IMPORTED_LOCATION "${DML_HL_LIBRARIES}")
-  endif()
-endif()

cmake/modules/Findndctl.cmake

@@ -1,42 +0,0 @@
-# - Find libndctl
-# Find the ndctl libraries and includes
-#
-# ndctl_INCLUDE_DIR - where to find libndctl.h etc.
-# ndctl_LIBRARIES - List of libraries when using ndctl.
-# ndctl_FOUND - True if ndctl found.
-
-find_path(ndctl_INCLUDE_DIR ndctl/libndctl.h)
-
-if(ndctl_INCLUDE_DIR AND EXISTS "${ndctl_INCLUDE_DIR}/libndctl.h")
-  foreach(ver "MAJOR" "MINOR" "RELEASE")
-    file(STRINGS "${ndctl_INCLUDE_DIR}/libndctl.h" ndctl_VER_${ver}_LINE
-      REGEX "^#define[ \t]+ndctl_VERSION_${ver}[ \t]+[0-9]+[ \t]+.*$")
-    string(REGEX REPLACE "^#define[ \t]+ndctl_VERSION_${ver}[ \t]+([0-9]+)[ \t]+.*$"
-      "\\1" ndctl_VERSION_${ver} "${ndctl_VER_${ver}_LINE}")
-    unset(${ndctl_VER_${ver}_LINE})
-  endforeach()
-  set(ndctl_VERSION_STRING
-    "${ndctl_VERSION_MAJOR}.${ndctl_VERSION_MINOR}.${ndctl_VERSION_RELEASE}")
-endif()
-
-find_library(ndctl_LIBRARY ndctl)
-
-include(FindPackageHandleStandardArgs)
-find_package_handle_standard_args(ndctl
-  REQUIRED_VARS ndctl_LIBRARY ndctl_INCLUDE_DIR
-  VERSION_VAR ndctl_VERSION_STRING)
-
-mark_as_advanced(ndctl_INCLUDE_DIR ndctl_LIBRARY)
-
-if(ndctl_FOUND)
-  set(ndctl_INCLUDE_DIRS ${ndctl_INCLUDE_DIR})
-  set(ndctl_LIBRARIES ${ndctl_LIBRARY})
-  if(NOT (TARGET ndctl::ndctl))
-    add_library(ndctl::ndctl UNKNOWN IMPORTED)
-    set_target_properties(ndctl::ndctl PROPERTIES
-      INTERFACE_INCLUDE_DIRECTORIES "${ndctl_INCLUDE_DIRS}"
-      IMPORTED_LINK_INTERFACE_LANGUAGES "C"
-      IMPORTED_LOCATION "${ndctl_LIBRARIES}"
-      VERSION "${ndctl_VERSION_STRING}")
-  endif()
-endif()

container/Containerfile

@@ -1,4 +1,4 @@
-ARG FROM_IMAGE="quay.io/centos/centos:stream9"
+ARG FROM_IMAGE="docker.io/rockylinux/rockylinux:10"
 FROM $FROM_IMAGE
 
 # allow FROM_IMAGE to be visible inside this stage
@@ -124,7 +124,16 @@ RUN --mount=type=secret,id=prerelease_creds set -ex && \
         source /run/secrets/prerelease_creds; \
         REPO_URL="https://${PRERELEASE_USERNAME}:${PRERELEASE_PASSWORD}@download.ceph.com/prerelease/ceph/rpm-${CEPH_REF}/${EL_VER}/" ;\
     fi && \
-    rpm -Uvh "$REPO_URL/noarch/ceph-release-1-${IS_RELEASE}.${EL_VER}.noarch.rpm" ; \
+    # Trim trailing slashes
+    REPO_URL="${REPO_URL%/}" && \
+    if [[ "$REPO_URL" == */pulp/content/* ]] ; then \
+        # Pulp nests packages under noarch/Packages/<first-letter>/
+        CEPH_RELEASE_RPM="$REPO_URL/noarch/Packages/c/ceph-release-1-${IS_RELEASE}.${EL_VER}.noarch.rpm" ; \
+    else \
+        # chacra serves packages flat under noarch/
+        CEPH_RELEASE_RPM="$REPO_URL/noarch/ceph-release-1-${IS_RELEASE}.${EL_VER}.noarch.rpm" ; \
+    fi && \
+    rpm -Uvh "$CEPH_RELEASE_RPM" ; \
     if [[ "$IS_RELEASE" == 1 ]] ; then \
         sed -i "s;http://download.ceph.com/;https://${PRERELEASE_USERNAME}:${PRERELEASE_PASSWORD}@download.ceph.com/prerelease/ceph/;" /etc/yum.repos.d/ceph.repo ; \
         dnf clean expire-cache ; \

container/build.sh

@@ -16,7 +16,7 @@ usage() {
 $0 [containerfile] (defaults to 'Containerfile')
 For a CI build (from ceph-ci.git, built and pushed to shaman):
 CI_CONTAINER: must be 'true'
-FROM_IMAGE: defaults to quay.io/centos/centos9:stream
+FROM_IMAGE: defaults to docker.io/rockylinux/rockylinux:10
 FLAVOR (OSD flavor, default or crimson)
 BRANCH (of Ceph. <remote>/<ref>)
 CEPH_SHA1 (of Ceph)
@@ -125,7 +125,7 @@ CONTAINER_BUILD_ARGS=(
     --squash
     -f "$CFILE"
     -t build.sh.output
-    --build-arg FROM_IMAGE="${FROM_IMAGE:-quay.io/centos/centos:stream9}"
+    --build-arg FROM_IMAGE="${FROM_IMAGE:-docker.io/rockylinux/rockylinux:10}"
     --build-arg CEPH_SHA1="${CEPH_SHA1}"
     --build-arg CEPH_GIT_REPO="${CEPH_GIT_REPO}"
     --build-arg CEPH_REF="${BRANCH:-main}"

debian/ceph-common.install

@@ -23,6 +23,7 @@ usr/bin/rgw-gap-list
 usr/bin/rgw-gap-list-comparator
 usr/bin/rgw-orphan-list
 usr/bin/rgw-policy-check
+usr/bin/rgw-policy-test
 usr/bin/rgw-restore-bucket-index
 usr/bin/rbd
 usr/bin/rbdmap
@@ -44,6 +45,7 @@ usr/share/man/man8/mount.ceph.8
 usr/share/man/man8/rados.8
 usr/share/man/man8/radosgw-admin.8
 usr/share/man/man8/rgw-policy-check.8
+usr/share/man/man8/rgw-policy-test.8
 usr/share/man/man8/rgw-gap-list.8
 usr/share/man/man8/rbd.8
 usr/share/man/man8/rbdmap.8

debian/ceph-mgr-modules-core.requires

@@ -1,5 +1,3 @@
 natsort
-CherryPy
-packaging
 requests
 python-dateutil

debian/control

@@ -76,13 +76,11 @@ Build-Depends: automake,
                libgrpc++-dev,
                protobuf-compiler-grpc,
                libutf8proc-dev (>= 2.2.0),
-               librdkafka-dev (>= 1.1.0),
+               librdkafka-dev (>= 2.11) <pkg.ceph.system-rdkafka>,
+               libsasl2-dev <!pkg.ceph.system-rdkafka>,
                libthrift-dev (>= 0.13.0),
                libyaml-cpp-dev (>= 0.6),
                libzstd-dev <pkg.ceph.check>,
-               libdaxctl-dev (>= 63) <pkg.ceph.pmdk>,
-               libndctl-dev (>= 63) <pkg.ceph.pmdk>,
-               libpmem-dev <pkg.ceph.pmdk>,
                libpmemobj-dev (>= 1.8) <pkg.ceph.pmdk>,
                libprotobuf-dev,
                libxsimd-dev <!pkg.ceph.arrow>,

debian/copyright

@@ -209,9 +209,8 @@ License: GPL-2
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.
  .
- You should have received a copy of the GNU General Public License along
- with this program; if not, write to the Free Software Foundation, Inc.,
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ You should have received a copy of the GNU General Public License
+ along with this program.  If not, see <https://www.gnu.org/licenses/>.
  .
  On Debian systems, the complete text of the GNU General Public License
  version 2 can be found in `/usr/share/common-licenses/GPL-2' file.

debian/rules

@@ -18,6 +18,9 @@ endif
 ifneq ($(filter pkg.ceph.crimson,$(DEB_BUILD_PROFILES)),)
   extraopts += -DWITH_CRIMSON=ON
 endif
+ifneq ($(filter pkg.ceph.system-rdkafka,$(DEB_BUILD_PROFILES)),)
+  extraopts += -DWITH_SYSTEM_RDKAFKA=ON
+endif
 
 extraopts += -DWITH_JAEGER=ON
 extraopts += -DWITH_SYSTEM_JERASURE=ON
@@ -54,6 +57,11 @@ endif
 
 ifeq ($(DWZ), false)
 override_dh_dwz:
+else
+override_dh_dwz:
+	# Exclude ceph-osd-crimson, librgw, and radosgw due to excessive debug info (too many DIEs)
+	dh_dwz -Xceph-osd-crimson -Xlibrgw -Xradosgw
+
 endif
 
 # for python3-${pkg} packages

doc/cephadm/host-management.rst

@@ -551,8 +551,28 @@ cephadm operations. Run a command of the following form:
 
    ceph cephadm set-user <user>
 
-Prior to running this, the cluster SSH key needs to be added to this user's
-``authorized_keys`` file and non-root users must have passwordless sudo access.
+The ``set-user`` command automatically configures the specified user on all cluster
+hosts by calling ``cephadm setup-ssh-user`` on each host. This command includes the following:
+
+- Setting up passwordless sudo access for non-root users
+- Authorizing the cluster's SSH public key for the user
+
+If you have already manually configured the user on all hosts, you can skip
+the automatic setup by using the ``--skip-pre-steps`` flag:
+
+.. prompt:: bash #
+
+   ceph cephadm set-user <user> --skip-pre-steps
+
+For manual setup of SSH users on individual hosts, you can use the
+``cephadm setup-ssh-user`` command directly:
+
+.. prompt:: bash #
+
+   cephadm setup-ssh-user --ssh-user <user> --ssh-pub-key <public_key>
+
+This command validates that the user exists, configures passwordless sudo access,
+and authorizes the SSH public key.
 
 
 Customizing the SSH Configuration
@@ -668,6 +688,95 @@ when executing ``ceph * metadata``. This in turn means cephadm also
 requires the bare host name when adding a host to the cluster:
 ``ceph orch host add <bare-name>``.
 
-..
-  TODO: This chapter needs to provide way for users to configure
-  Grafana in the dashboard, as this is right now very hard to do.
+Sudo Hardening
+==============
+
+Cephadm supports sudo hardening to enhance security by restricting sudo privilege
+escalation for non-root SSH users. When sudo hardening is enabled, cephadm uses the
+``cephadm_invoker.py`` script to securely execute cephadm commands with controlled
+privilege escalation.
+
+Enabling Sudo Hardening
+-----------------------
+
+To enable sudo hardening for the entire cluster, use the following command:
+
+.. prompt:: bash #
+
+  ceph cephadm prepare-host-and-enable-sudo-hardening <user>
+
+This command performs a comprehensive sudo hardening setup:
+
+1. **Host Preparation**: Prepares all cluster hosts for sudo hardening by:
+   - Installing/upgrading cephadm RPM with the invoker script
+   - Configuring restricted sudo access for non-root users
+   - Setting up SSH key authorization
+
+2. **SSH User Configuration**: Sets the specified user for cluster SSH operations
+
+3. **Global Enablement**: Enables sudo hardening cluster-wide
+
+The ``<user>`` parameter specifies which non-root user should be configured for SSH access.
+This user will have restricted sudo access configured through the sudoers file.
+
+You can manually prepare a host for sudo hardening using:
+
+.. prompt:: bash #
+
+  cephadm prepare-host-sudo-hardening --ssh-user <user> --ssh-pub-key <pub_key>
+
+.. note:: During initial host addition, the root user is used for setup. After
+   Sudo hardening is enabled, the specified non-root user with restricted sudo
+   access will be used for ongoing operations.
+
+Sudo Hardening Workflow
+-----------------------
+
+When sudo hardening is enabled, the following workflow is used:
+
+1. **Host Addition**: Before adding a new host with ``ceph orch host add``,
+   the cluster SSH key needs to be added to this user's ``authorized_keys``
+   file and non-root users must have passwordless sudo access.
+2. **Command Execution**: Instead of executing cephadm directly, commands are
+   routed through ``cephadm_invoker.py``
+3. **Binary Verification**: The invoker validates the cephadm binary's hash before execution
+4. **Secure Execution**: Commands are executed with restricted permissions
+
+The ``cephadm_invoker.py`` script provides the following subcommands:
+
+- ``run``: Execute cephadm binary with hash verification
+- ``deploy_cephadm_binary``: Deploy cephadm binary to final location
+- ``check_existence``: Check if a file exists
+
+Sudo Access Restrictions
+-------------------------
+
+Sudo hardening restricts sudo access for non-root users to enhance security. When a
+host is prepared for sudo hardening, the sudoers configuration is modified to limit
+the commands that can be executed with sudo. This prevents unauthorized command
+execution while still allowing necessary cephadm operations.
+
+The sudoers configuration restricts access to only the ``cephadm_invoker.py`` script
+and essential system commands, providing a secure execution environment.
+
+Security Benefits
+-----------------
+Sudo hardening provides the following security benefits:
+
+1. The invoker validates the cephadm binary's hash
+2. If validation fails, it signals for binary redeployment
+3. Commands are executed with restricted sudo permissions
+4. All operations are logged for security auditing
+
+
+Disabling Sudo Hardening
+------------------------
+
+To disable sudo hardening:
+
+.. prompt:: bash #
+
+  ceph config set mgr mgr/cephadm/sudo_hardening false
+
+.. note:: Disabling sudo hardening does not automatically revert host configurations.
+   Hosts that were prepared for sudo hardening will retain the invoker setup.

doc/cephadm/install.rst

@@ -149,6 +149,7 @@ packages that provide the ``cephadm`` command, run the following commands:
 #. Add the repository:
 
    .. prompt:: bash #
+      :substitutions:
 
       ./cephadm add-repo --release |stable-release|
 

doc/cephadm/operations.rst

@@ -393,6 +393,34 @@ For example:
    ``--log-dest`` options described in the bootstrap section above.
 
 
+Setting Cephadm Log Verbosity
+-----------------------------
+
+The verbosity of cephadm's persistent logging (``/var/log/ceph/cephadm.log``
+and syslog, when enabled) can be controlled separately from its terminal
+output. Valid levels are ``info``, ``debug``, ``error``, and ``warning``.
+The default is ``debug``.
+
+When the cephadm orchestration module runs ``cephadm`` on cluster hosts, it
+uses the :confval:`mgr/cephadm/cephadm_binary_logging_level` configuration
+value:
+
+.. prompt:: bash #
+
+  ceph config set mgr mgr/cephadm/cephadm_binary_logging_level info
+
+For manual invocations, pass ``--logging-level`` on the command line:
+
+.. prompt:: bash #
+
+  cephadm --logging-level info check-host
+
+.. note:: The logging level applies only to persistent log destinations
+   (the log file and syslog). Console output during bootstrap and other
+   interactive use is unchanged. When you run ``cephadm`` directly, the
+   mgr configuration does not apply; use ``--logging-level`` as shown above.
+
+
 Data Location
 =============
 

doc/cephadm/services/index.rst

@@ -806,6 +806,13 @@ For example:
 
     ceph orch rm rgw.myrgw
 
+The same command accepts ``--force`` and ``--force-delete-data``. Use
+``ceph orch rm <service-name> --force --force-delete-data`` when you want
+cephadm to remove on-disk data for supported daemon types instead of relocating
+it under ``<fsid>/removed/``. The latter flag requires ``--force``. The same
+pair of flags applies to ``ceph orch daemon rm <daemon-name>`` when removing
+individual daemons.
+
 
 .. _cephadm-spec-unmanaged:
 

doc/cephadm/services/mgmt-gateway.rst

@@ -8,10 +8,10 @@ Deploying mgmt-gateway
 ======================
 
 In Ceph releases beginning with Tentacle, the ``mgmt-gateway`` service introduces a new design for Ceph applications
-based on a modular, service-based architecture. This service, managed by cephadm and built on top of nginx
+based on a modular, service-based architecture. This service, managed by cephadm and built on top of NGINX
 (an open-source, high-performance web server), acts as the new front-end and single entry point to the
 Ceph cluster. The ``mgmt-gateway`` provides unified access to all Ceph applications, including the Ceph dashboard
-and monitoring stack. Employing nginx enhances security and simplifies access management due to its robust
+and monitoring stack. Employing NGINX enhances security and simplifies access management due to its robust
 community support and high-security standards. The ``mgmt-gateway`` service acts as a reverse proxy that routes
 requests to the appropriate Ceph application instances.
 
@@ -28,10 +28,10 @@ consolidated behind the new service endpoint: ``https://<node-ip>:<port>``.
 
 Benefits of the mgmt-gateway service
 ====================================
-* ``Unified Access``: Consolidated access through nginx improves security and provides a single entry point to services.
+* ``Unified Access``: Consolidated access through NGINX improves security and provides a single entry point to services.
 * ``Improved user experience``: Users no longer need to know where each application is running (IP/host).
-* ``High Availability for dashboard``: nginx HA mechanisms are used to provide high availability for the Ceph dashboard.
-* ``High Availability for monitoring``: nginx HA mechanisms are used to provide high availability for monitoring.
+* ``High Availability for dashboard``: NGINX HA mechanisms are used to provide high availability for the Ceph dashboard.
+* ``High Availability for monitoring``: NGINX HA mechanisms are used to provide high availability for monitoring.
 
 Security enhancements
 =====================
@@ -42,7 +42,7 @@ Ceph dashboard.
 
 High availability enhancements
 ==============================
-nginx HA mechanisms are used to provide high availability for all the Ceph management applications including the Ceph dashboard
+NGINX HA mechanisms are used to provide high availability for all the Ceph management applications including the Ceph dashboard
 and monitoring stack. In case of the Ceph dashboard, users no longer need to know where the active manager is running.
 ``mgmt-gateway`` handles manager failover transparently and redirects the user to the active manager. In case of the
 monitoring ``mgmt-gateway`` takes care of handling HA when several instances of Prometheus, Alertmanager or Grafana are
@@ -58,7 +58,7 @@ even if certain core components for the service fail, including the ``mgmt-gatew
 
 Multiple ``mgmt-gateway`` instances can be deployed in an active/standby configuration using keepalived
 for seamless failover. The ``oauth2-proxy`` service can be deployed as multiple stateless instances,
-with nginx acting as a load balancer across them using a round-robin strategy. This setup removes
+with NGINX acting as a load balancer across them using a round-robin strategy. This setup removes
 single points of failure and enhances the resilience of the entire system.
 
 In this setup, the underlying internal services follow the same high availability mechanism. Instead of
@@ -188,7 +188,7 @@ Limitations
 Default images
 ~~~~~~~~~~~~~~
 
-The ``mgmt-gateway`` service internally makes use of nginx reverse proxy. The following container image is used by default:
+The ``mgmt-gateway`` service internally makes use of NGINX reverse proxy. The following container image is used by default:
 
 ::
 

doc/cephadm/services/monitoring.rst

@@ -463,11 +463,16 @@ To disable monitoring and remove the software that supports it, run the followin
 .. prompt:: bash #
 
   ceph orch rm grafana
-  ceph orch rm prometheus --force   # this will delete metrics data collected so far
+  ceph orch rm prometheus
   ceph orch rm node-exporter
   ceph orch rm alertmanager
   ceph mgr module disable prometheus
 
+By default, cephadm moves Prometheus data aside under ``<fsid>/removed/`` on the
+host. To delete that data instead, use
+``ceph orch rm prometheus --force --force-delete-data`` in place of
+``ceph orch rm prometheus`` (``--force-delete-data`` requires ``--force``).
+
 See also :ref:`orch-rm`.
 
 Setting up RBD-Image Monitoring

doc/cephadm/services/nfs.rst

@@ -60,6 +60,7 @@ Alternatively, an NFS service can be applied using a YAML specification.
         host2: 10.0.0.124
       monitoring_networks:
       - 192.168.124.0/24
+      enable_nfsv3: true
 
 
 In this example, we run the server on the non-default ``port`` of
@@ -78,6 +79,8 @@ IP address is assigned to the host, that IP address will be used. If the IP
 address is not present and ``monitoring_networks`` is specified, an IP address
 that matches one of the specified networks will be used. If neither condition
 is met, the default binding will happen on all available network interfaces.
+By default, only the NFSv4 protocol is enabled. NFSv3 can be enabled by setting
+``enable_nfsv3`` to ``true`` in the service specification.
 
 NFS over RDMA
 -------------
@@ -280,6 +283,27 @@ The following parameters can be used to configure TLS/SSL encryption for the NFS
    If using ``inline`` certificates, all three certificate fields (``ssl_cert``,
    ``ssl_key``, ``ssl_ca_cert``) must be provided.
 
+Cluster-level QoS can also be configured at deployment time by specifying
+``cluster_qos_config`` and ``cluster_qos_port`` in the service spec.
+See :ref:`mgr-nfs` (Cluster QoS management) for supported keys and
+parameter constraints.
+
+.. code-block:: yaml
+
+    service_type: nfs
+    service_id: mynfs
+    placement:
+      hosts:
+        - host1
+    spec:
+      port: 2049
+      cluster_qos_port: 31311
+      cluster_qos_config:
+        qos_type: PerShare
+        enable_bw_control: true
+        max_export_write_bw: 100MB
+        max_export_read_bw: 100MB
+
 The specification can then be applied by running the following command:
 
 .. prompt:: bash #

doc/cephadm/services/oauth2-proxy.rst

@@ -43,7 +43,7 @@ a secure and flexible authentication mechanism.
 High availability
 =================
 In general, `oauth2-proxy` is used in conjunction with the `mgmt-gateway`. The `oauth2-proxy` service can be deployed as multiple
-stateless instances, with the `mgmt-gateway` (nginx reverse-proxy) handling load balancing across these instances using a round-robin strategy.
+stateless instances, with the `mgmt-gateway` (NGINX reverse-proxy) handling load balancing across these instances using a round-robin strategy.
 Since oauth2-proxy integrates with an external identity provider (IDP), ensuring high availability for login is managed externally
 and not the responsibility of this service.
 

doc/cephadm/services/smb.rst

@@ -53,13 +53,100 @@ An SMB service can be applied using a specification. An example in YAML follows:
       include_ceph_users:
         - client.smb.fs.cluster.tango
 
+TLS/SSL Example
+---------------
+
+Here's an example SMB service specification with TLS/SSL configuration:
+
+.. code-block:: yaml
+
+   service_id: smbcluster
+   service_type: smb
+   cluster_id: tango
+   config_uri: rados://smb/foxtrot/config.json
+   placement:
+     hosts:
+       - host0
+   spec:
+     ssl_certificates:
+       remote_control:
+         enabled: true
+         certificate_source: inline
+         ssl_cert: |
+           -----BEGIN CERTIFICATE-----
+           ...
+           -----END CERTIFICATE-----
+
+         ssl_key: |
+           -----BEGIN PRIVATE KEY-----
+           ...
+           -----END PRIVATE KEY-----
+
+         ssl_ca_cert: |
+           -----BEGIN CERTIFICATE-----
+           ...
+           -----END CERTIFICATE-----
+       keybridge:
+         enabled: true
+         certificate_source: inline
+         ssl_cert: |
+           -----BEGIN CERTIFICATE-----
+           ...
+           -----END CERTIFICATE-----
+
+         ssl_key: |
+           -----BEGIN PRIVATE KEY-----
+           ...
+           -----END PRIVATE KEY-----
+
+         ssl_ca_cert: |
+           -----BEGIN CERTIFICATE-----
+           ...
+           -----END CERTIFICATE-----
+
+This example configures an SMB service with TLS encryption enabled using
+inline certificates.
+
+TLS/SSL Parameters
+~~~~~~~~~~~~~~~~~~
+
+The following parameters can be used to configure TLS/SSL encryption per sidecar
+for the SMB service:
+
+* ``enabled`` (boolean): Enable or disable SSL/TLS encryption. Default is ``false``.
+
+* ``certificate_source`` (string): Specifies the source of the TLS certificates.
+  Options include:
+
+  - ``cephadm-signed``: Use certificates signed by cephadm's internal CA
+  - ``inline``: Provide certificates directly in the specification using ``ssl_cert``,
+    ``ssl_key`` and ``ssl_ca_cert`` fields
+  - ``reference``: Users can register their own certificate and key with certmgr and
+    set the ``certificate_source`` to ``reference`` in the spec.
+
+* ``ssl_cert`` (string): The SSL certificate in PEM format. Required when using
+  ``inline`` certificate source.
+
+* ``ssl_key`` (string): The SSL private key in PEM format. Required when using
+  ``inline`` certificate source.
+
+* ``ssl_ca_cert`` (string): The SSL CA certificate in PEM format. Required when
+  using ``inline`` certificate source.
+
+.. note::
+   ``ssl_key``, ``ssl_cert`` and ``ssl_ca_cert`` can be set from the smb manager
+   module. If ``cert`` and ``key`` are specified in the resource_type
+   ``ceph.smb.tls.credential`` and applied from the smb manager will be automatically
+   configured as ssl_certificate is enabled and update ``ssl_key``, ``ssl_cert`` to
+   the certificate manager. ``ssl_ca_cert`` will be set if it is specified in the
+   resource_type ``ceph.smb.tls.credential``
+
 The specification can then be applied by running the following command:
 
 .. prompt:: bash #
 
    ceph orch apply -i smb.yaml
 
-
 Service Spec Options
 --------------------
 

doc/cephadm/upgrade.rst

@@ -136,7 +136,7 @@ Requirements:
   (same shape as ``ceph_version_short`` in ``ceph osd metadata``).
 * If the Monitors indicate to cephadm that no OSDs in the selected CRUSH bucket
   are okay to upgrade, cephadm will log details and then retry the operation.
-*  If the bucket parameters for a ceph ``osd ok-to-upgrade`` upgrade are not provided,
+* If the bucket parameters for a ceph ``osd ok-to-upgrade`` upgrade are not provided,
   cephadm will fall back to the default ceph osd ok-to-stop gate for OSD upgrades.
 * Bucket-scope upgrades apply only to OSDs. CRUSH buckets do not influence upgrades
   of other daemon types, for example Monitors, Managers, and MDSes.

doc/cephfs/cephfs-journal-tool.rst

@@ -150,6 +150,8 @@ Filtering:
 * ``--dname <string>`` only include events referring to this named dentry within a directory
   fragment (may only be used in conjunction with ``--frag``)
 * ``--client <int>`` only include events from this client session ID
+* ``--max-rss <bytes>`` (works only with ``recover_dentries`` for now) limits the RSS of the cephfs-journal-tool
+  by scanning and flushing journal events in batches
 
 Filters may be combined on an AND basis (i.e. only the intersection of events from each filter).
 

doc/cephfs/cephfs-mirroring-checkpoints.rst

@@ -0,0 +1,360 @@
+========================================
+CephFS Snapshot Mirroring Checkpoints
+========================================
+
+.. contents::
+   :depth: 3
+   :local:
+
+Introduction
+============
+
+CephFS Snapshot Mirroring Checkpoints allow you to mark specific snapshots as important
+milestones and track whether they have been successfully replicated to your remote site.
+This feature provides visibility into your disaster recovery readiness by showing which
+critical data states have been safely mirrored.
+
+**Use Cases:**
+
+- **Compliance & Auditing**: Verify that end-of-day or end-of-month snapshots are replicated
+- **Application Consistency**: Ensure application-consistent snapshots reach the DR site
+- **Migration Tracking**: Monitor progress when migrating data between sites
+- **SLA Verification**: Confirm that critical snapshots meet replication SLAs
+
+What is a Checkpoint?
+=====================
+
+A checkpoint is a marker you place on a snapshot to track its replication status. When you
+checkpoint a snapshot, the system monitors whether that snapshot (and all previous snapshots)
+have been successfully synchronized to the remote filesystem.
+
+**Key Concepts:**
+
+- **Automatic Status Tracking**: Checkpoints automatically detect if a snapshot has already been synced
+- **Persistent**: Checkpoint information survives daemon restarts
+- **Per-Directory**: Each mirrored directory has its own set of checkpoints
+
+Checkpoint Lifecycle
+--------------------
+
+Every checkpoint goes through these states:
+
+.. code-block:: text
+
+    ┌─────────┐
+    │ CREATED │  ← Checkpoint added, snapshot not yet synced
+    └────┬────┘
+         │
+         ├──→ ┌──────────┐
+         │    │ COMPLETE │  ← Snapshot successfully synced to remote
+         │    └──────────┘
+         │
+         └──→ ┌────────┐
+              │ FAILED │  ← Sync failed (will be retried automatically)
+              └────────┘
+
+- **created**: Waiting for synchronization or sync in progress
+- **complete**: Successfully replicated to remote site
+- **failed**: Sync encountered an error (check error message for details)
+
+Prerequisites
+=============
+
+Before using checkpoints, ensure:
+
+1. **CephFS Mirroring is Enabled**:
+
+   .. code-block:: bash
+
+       ceph fs snapshot mirror enable <fs_name>
+
+2. **Remote Peer is Configured**:
+
+   .. code-block:: bash
+
+       ceph fs snapshot mirror peer_add <fs_name> <peer_spec>
+
+3. **Directory is Being Mirrored**:
+
+   .. code-block:: bash
+
+       ceph fs snapshot mirror add <fs_name> <dir_path>
+
+4. **Snapshots Exist**: You need snapshots to checkpoint
+
+For detailed mirroring setup, see :doc:`cephfs-mirroring`.
+
+Getting Started
+===============
+
+Basic Workflow
+--------------
+
+Here's a typical workflow for using checkpoints:
+
+**Step 1: Create Snapshots**
+
+.. code-block:: bash
+
+    # Create snapshots in your mirrored directory
+    mkdir /mnt/cephfs/data/.snap/daily_backup_2026_06_01
+    mkdir /mnt/cephfs/data/.snap/daily_backup_2026_06_02
+    mkdir /mnt/cephfs/data/.snap/daily_backup_2026_06_03
+
+**Step 2: Add Checkpoints**
+
+.. code-block:: bash
+
+    # Mark important snapshots as checkpoints
+    ceph fs snapshot mirror checkpoint add myfs /data daily_backup_2026_06_01
+    ceph fs snapshot mirror checkpoint add myfs /data daily_backup_2026_06_03
+
+**Step 3: Monitor Status**
+
+.. code-block:: bash
+
+    # Check checkpoint status
+    ceph fs snapshot mirror checkpoint ls myfs /data --format json-pretty
+
+**Example Output:**
+
+.. code-block:: json
+
+    {
+      "dir_root": "/data",
+      "checkpoints": [
+        {
+          "snap_id": 100,
+          "snap_name": "daily_backup_2026_06_01",
+          "status": "complete",
+          "created_at": "2026-06-01T23:00:00.000000+0000",
+          "updated_at": "2026-06-01T23:15:00.000000+0000"
+        },
+        {
+          "snap_id": 102,
+          "snap_name": "daily_backup_2026_06_03",
+          "status": "created",
+          "created_at": "2026-06-03T23:00:00.000000+0000",
+          "updated_at": "2026-06-03T23:00:00.000000+0000"
+        }
+      ]
+    }
+
+Command Reference
+=================
+
+checkpoint add
+--------------
+
+Add a checkpoint to a specific snapshot.
+
+**Syntax:**
+
+.. code-block:: bash
+
+    ceph fs snapshot mirror checkpoint add <fs_name> <dir_path> <snap_name>
+
+**Parameters:**
+
+- ``fs_name``: Name of the filesystem
+- ``dir_path``: Path to the mirrored directory (e.g., ``/data``)
+- ``snap_name``: Name of the snapshot to checkpoint
+
+**Example:**
+
+.. code-block:: bash
+
+    ceph fs snapshot mirror checkpoint add myfs /data backup_snapshot_1
+
+**Output:**
+
+.. code-block:: json
+
+    {
+      "status": "success",
+      "message": "checkpoint added for snapshot backup_snapshot_1",
+      "dir_root": "/data",
+      "snap_id": 123,
+      "snap_name": "backup_snapshot_1",
+      "checkpoint_status": "created"
+    }
+
+**Notes:**
+
+- If the snapshot has already been synced, status will be ``complete`` immediately
+- You cannot checkpoint the same snapshot twice
+- The snapshot must exist in the directory
+
+checkpoint now
+--------------
+
+Add a checkpoint to the most recent snapshot in a directory.
+
+**Syntax:**
+
+.. code-block:: bash
+
+    ceph fs snapshot mirror checkpoint now <fs_name> <dir_path>
+
+**Example:**
+
+.. code-block:: bash
+
+    ceph fs snapshot mirror checkpoint now myfs /data
+
+**Output:**
+
+.. code-block:: json
+
+    {
+      "status": "success",
+      "message": "checkpoint created on latest snapshot",
+      "dir_root": "/data",
+      "snap_id": 125,
+      "snap_name": "daily_backup_2026_06_03",
+      "checkpoint_status": "created"
+    }
+
+**Use Case:**
+
+Useful when you want to checkpoint the latest state without knowing the exact snapshot name.
+
+checkpoint ls
+-------------
+
+List all checkpoints for a directory.
+
+**Syntax:**
+
+.. code-block:: bash
+
+    ceph fs snapshot mirror checkpoint ls <fs_name> <dir_path> [--format <format>]
+
+**Parameters:**
+
+- ``format``: Output format (``json`` or ``json-pretty``), default is ``json``
+
+**Example:**
+
+.. code-block:: bash
+
+    ceph fs snapshot mirror checkpoint ls myfs /data --format json-pretty
+
+**Output Fields:**
+
+- ``snap_id``: Internal snapshot ID
+- ``snap_name``: Snapshot name
+- ``status``: Current status (created/complete/failed)
+- ``created_at``: When checkpoint was created
+- ``updated_at``: Last status update time
+- ``error_msg``: Error description (only present if status is failed)
+
+checkpoint remove
+-----------------
+
+Remove a checkpoint from a specific snapshot.
+
+**Syntax:**
+
+.. code-block:: bash
+
+    ceph fs snapshot mirror checkpoint remove <fs_name> <dir_path> <snap_name>
+
+**Example:**
+
+.. code-block:: bash
+
+    # Remove checkpoint from a specific snapshot
+    ceph fs snapshot mirror checkpoint remove myfs /data backup_snapshot_1
+
+**Output:**
+
+.. code-block:: json
+
+    {
+      "status": "success",
+      "message": "checkpoint removed for snapshot backup_snapshot_1",
+      "dir_root": "/data",
+      "snap_name": "backup_snapshot_1"
+    }
+
+**Notes:**
+
+- Removing a checkpoint does NOT delete the snapshot itself
+- The snapshot and its data remain intact
+- This operation only removes the checkpoint tracking metadata
+- This operation cannot be undone
+- To remove multiple checkpoints, run the command multiple times
+
+Important Notes
+===============
+
+Snapshot Deletion Behavior
+---------------------------
+
+.. warning::
+
+   **If a snapshot with a checkpoint is deleted, the checkpoint metadata is permanently lost.**
+
+When you delete a snapshot that has a checkpoint:
+
+1. **Before Sync Completes**: The checkpoint is lost and will never reach "complete" status
+2. **After Sync Completes**: The checkpoint history is lost, but the data was already replicated
+
+**Impact on Commands:**
+
+- ``checkpoint ls``: Will not show the deleted snapshot's checkpoint
+- ``checkpoint remove``: Will fail with "snapshot not found" error
+
+**Best Practice:**
+
+- Do not delete snapshots with active checkpoints until they reach "complete" status
+- Use ``checkpoint ls`` to verify checkpoint status before deleting snapshots
+- Consider removing checkpoints explicitly before deleting important snapshots
+
+Snapshot Rename Behavior
+-------------------------
+
+.. note::
+
+   **Checkpoints survive snapshot renames, but you must use the new snapshot name in commands.**
+
+When you rename a snapshot that has a checkpoint:
+
+1. **Checkpoint Persists**: The checkpoint metadata remains attached to the snapshot
+2. **Name Updates Automatically**: ``checkpoint ls`` will show the new snapshot name
+3. **Old Name No Longer Works**: You must use the new name for ``checkpoint remove``
+
+**Example:**
+
+.. code-block:: bash
+
+    # Original snapshot with checkpoint
+    ceph fs snapshot mirror checkpoint add myfs /data old_name
+
+    # Rename the snapshot (using CephFS snapshot rename)
+    # ... snapshot renamed from 'old_name' to 'new_name' ...
+
+    # List checkpoints - shows new name
+    ceph fs snapshot mirror checkpoint ls myfs /data
+    # Output shows: "snap_name": "new_name"
+
+    # Remove using NEW name (this works)
+    ceph fs snapshot mirror checkpoint remove myfs /data new_name
+
+    # Remove using OLD name (this fails)
+    ceph fs snapshot mirror checkpoint remove myfs /data old_name
+    # Error: snapshot 'old_name' not found
+
+**Best Practice:**
+
+- Always use ``checkpoint ls`` to verify current snapshot names before removing checkpoints
+- Update any automation scripts if you rename snapshots
+
+
+Additional Resources
+====================
+
+- **CephFS Mirroring Guide**: :doc:`cephfs-mirroring`
+- **Snapshot Documentation**: :doc:`/cephfs/snapshots`
+- **Tracker Issue**: https://tracker.ceph.com/issues/73454

doc/cephfs/cephfs-tool.rst

@@ -15,6 +15,10 @@ Key features include:
 * Configurable block sizes, file counts, and fsync intervals.
 * Detailed statistical reporting (Mean, Std Dev, Min/Max) for throughput and IOPS.
 * Support for specific CephFS user/group impersonation (UID/GID) via ``ceph_mount_perms_set``.
+* Optional JSON output and libcephfs perf counter dumps.
+* Optional progress reporting during benchmark phases.
+* Optional asynchronous I/O benchmarking with configurable queue depth.
+* Optional overrides for selected client configuration settings such as object cache and messenger worker threads.
 
 Building
 ========
@@ -60,7 +64,7 @@ General Options
 
    Path to keyring file
 
-.. option:: --filesystem <name>
+.. option:: --filesystem, --fs <name>
 
    CephFS filesystem name to mount
 
@@ -72,6 +76,19 @@ General Options
 
    Group ID to mount as (default: ``-1``)
 
+.. option:: --client-oc <0|1>
+
+   Override the ``client_oc`` setting for the benchmark mount
+
+.. option:: --client-oc-size <value>
+
+   Override the ``client_oc_size`` setting for the benchmark mount
+
+.. option:: --msgr-workers <n>
+
+   Override ``ms_async_op_threads`` for the benchmark mount. Valid values are
+   ``1`` to ``24``; ``0`` keeps the configured default.
+
 Benchmark Options
 -----------------
 
@@ -121,6 +138,40 @@ These options are used with the ``bench`` command.
 
    Disable cleanup of files
 
+.. option:: --json <path>
+
+   Write structured benchmark results to a JSON file. Use ``-`` to output to stdout.
+
+.. option:: --duration <seconds>
+
+   Limit each write and read phase to ``N`` seconds. A value of ``0`` means the
+   benchmark processes all files.
+
+.. option:: --perf-dump <path>
+
+   Dump libcephfs performance counters to the specified file after the benchmark
+
+.. option:: --progress
+
+   Show live progress, bandwidth, file rate, and ETA during benchmark phases
+
+.. option:: --progress-interval <percent>
+
+   Minimum percentage increment between progress updates (default: ``10``;
+   valid range: ``1`` to ``100``)
+
+.. option:: --async-io
+
+   Use asynchronous I/O via ``ceph_ll_nonblocking_readv_writev`` for read and
+   write phases
+
+.. option:: --queue-depth <n>
+
+   Maximum number of outstanding async I/Os per worker thread (default:
+   ``16``; valid range: ``1`` to ``1024``). This option is only meaningful with
+   ``--async-io`` and ``--async-io`` cannot be combined with
+   ``--per-thread-mount``.
+
 Examples
 ========
 

doc/cephfs/disaster-recovery-experts.rst

@@ -65,6 +65,18 @@ InoTables of each ``in`` MDS rank, to indicate that any written inodes' numbers
 are now in use. In simple cases, this will result in an entirely valid backing
 store state.
 
+.. warning::
+   
+    Large journal sizes can cause the tool's Resident Set Size (RSS) to spike
+    significantly. Use the ``--max-rss <bytes>`` flag to limit memory usage, keeping the following
+    in mind:
+
+    * **Performance Impact:** Do not set this value too low. Restricting memory excessively will
+        severely degrade runtime performance and prolong the recovery process.
+    * **30% Buffer Rule:** Maintain a safety buffer of at least 30% relative to the tool's total
+        memory budget. For example, if 100 GiB can be allotted to the tool, cap its RSS limit at
+        70 GiB: ``--max-rss 75161927680``.
+
 .. warning::
 
     The resulting state of the backing store is not guaranteed to be

doc/cephfs/disaster-recovery.rst

@@ -85,6 +85,18 @@ Using first-damage.py
 
       cephfs-journal-tool --rank=<fs_name>:0 event recover_dentries summary
 
+   .. warning::
+
+      Large journal sizes can cause the tool's Resident Set Size (RSS) to
+      spike significantly. To prevent excessive memory consumption, use the
+      ``--max-rss <bytes>`` flag to cap the RSS. 
+
+      Avoid setting this value too low, as it will severely degrade runtime
+      performance and prolong recovery. It is best practice to maintain a memory
+      buffer of at least 30% of the tool's total budget. For example, if 100 GiB
+      is to be allotted to the tool, cap the RSS at 70 GiB
+      (``--max-rss 75161927680``).
+
 #. Reset the journal:
    
    .. prompt:: bash #

doc/cephfs/experimental-features.rst

@@ -24,8 +24,8 @@ failures within it are unlikely to make non-inlined data inaccessible.
 Inline data has always been off by default and requires setting
 the ``inline_data`` flag.
 
-Inline data has been declared deprecated for the Octopus release, and will
-likely be removed altogether in a future release.
+Inline data has been deprecated since the Octopus release. Enabling it triggers
+a health warning, and the feature will be removed altogether in a future release.
 
 Mantle: Programmable Metadata Load Balancer
 -------------------------------------------

doc/cephfs/fs-volumes.rst

@@ -476,6 +476,15 @@ This command resizes the subvolume quota, using the size specified by
 ``new_size``.  The ``--no_shrink`` flag prevents the subvolume from shrinking
 below the current "used size" of the subvolume.
 
+Resizing can also be done using human-friendly units::
+
+  ceph fs subvolume resize foo subvol1 100KiB
+  ceph fs subvolume resize foo subvol1 200.45KiB
+  ceph fs subvolume resize foo subvol1 300KB
+
+.. note:: Values will be strictly cast to IEC units even when SI units
+   are input, i.e. 1{K|KB|Ki|KiB} all translate to 1024 bytes.
+
 The subvolume can be resized to an unlimited (but sparse) logical size by
 passing ``inf`` or ``infinite`` as ``<new_size>``.
 

doc/cephfs/index.rst

@@ -93,6 +93,7 @@ Administration
     cephfs-tool <cephfs-tool>
     Scheduled Snapshots <snap-schedule>
     CephFS Snapshot Mirroring <cephfs-mirroring>
+    CephFS Snapshot Mirroring Checkpoints <cephfs-mirroring-checkpoints>
     Purge Queue <purge-queue>
 
 .. raw:: html

doc/cephfs/kernel-features.rst

@@ -8,9 +8,9 @@ in the kernel driver.
 
 Inline data
 -----------
-Inline data was introduced by the Firefly release. This feature is being
-deprecated in mainline CephFS, and may be removed from a future kernel
-release.
+Inline data was introduced by the Firefly release. This feature has been
+deprecated since the Octopus release: enabling it triggers a health warning,
+and it will be removed in a future release.
 
 Linux kernel clients >= 3.19 can read inline data and convert existing
 inline data to RADOS objects when file data is modified. At present,

doc/cephfs/lazyio.rst

@@ -14,7 +14,7 @@ Enable LazyIO
 LazyIO can be enabled in the following ways.
 
 - ``client_force_lazyio`` option enables LAZY_IO globally for libcephfs and
-  ceph-fuse mount.
+  ceph-fuse mount. This is strictly a startup flag.
 
 - ``ceph_lazyio(...)`` and ``ceph_ll_lazyio(...)`` enable LAZY_IO for file handle
   in libcephfs.

doc/cephfs/mds-config-ref.rst

@@ -68,3 +68,7 @@
 .. confval:: mds_symlink_recovery
 .. confval:: mds_extraordinary_events_dump_interval
 .. confval:: subv_metrics_window_interval
+.. confval:: mds_dmclock_enable
+.. confval:: mds_dmclock_reservation
+.. confval:: mds_dmclock_weight
+.. confval:: mds_dmclock_limit

doc/cephfs/upgrading.rst

@@ -54,37 +54,3 @@ command. Older versions of Ceph require you to stop these daemons manually.
     ceph fs set <fs_name> max_mds <old_max_mds>
     ceph fs set <fs_name> allow_standby_replay <old_allow_standby_replay>
 
-
-Upgrading pre-Firefly file systems past Jewel
-=============================================
-
-.. tip::
-
-    This advice only applies to users with file systems
-    created using versions of Ceph older than *Firefly* (0.80).
-    Users creating new file systems may disregard this advice.
-
-Pre-firefly versions of Ceph used a now-deprecated format
-for storing CephFS directory objects, called TMAPs.  Support
-for reading these in RADOS will be removed after the Jewel
-release of Ceph, so for upgrading CephFS users it is important
-to ensure that any old directory objects have been converted.
-
-After installing Jewel on all your MDS and OSD servers, and restarting
-the services, run the following command:
-
-::
-    
-    cephfs-data-scan tmap_upgrade <metadata pool name>
-
-This only needs to be run once, and it is not necessary to
-stop any other services while it runs.  The command may take some
-time to execute, as it iterates over all objects in your metadata
-pool.  It is safe to continue using your file system as normal while
-it executes.  If the command aborts for any reason, it is safe
-to simply run it again.
-
-If you are upgrading a pre-Firefly CephFS file system to a newer Ceph version
-than Jewel, you must first upgrade to Jewel and run the ``tmap_upgrade``
-command before completing your upgrade to the latest version.
-

doc/conf.py

@@ -165,9 +165,6 @@ else:
         'engine': 'ditaa'
     }
 
-if build_with_rtd:
-    extensions += ['sphinx_search.extension']
-
 # sphinx.ext.todo options
 todo_include_todos = True
 

doc/dev/cephadm/cephadm-invoker.rst

@@ -0,0 +1,58 @@
+Cephadm Invoker
+===============
+
+The ``cephadm_invoker.py`` script provides a wrapper intended for executing
+cephadm commands with limited sudo priviliges. It is used when sudo hardening
+is enabled.
+
+Overview
+--------
+
+The cephadm invoker validates the cephadm binary hash before execution and
+provides a secure way to run cephadm commands and deploy binaries. It is installed as
+part of the cephadm RPM at ``/usr/libexec/cephadm_invoker.py``.
+
+Commands
+--------
+
+The invoker supports the following subcommands:
+
+``run``
+
+Execute cephadm binary with arguments after hash verification::
+
+    cephadm_invoker.py run <binary> [args...]
+
+The binary path must include a hash in the filename for verification.
+
+``deploy_binary``
+
+Deploy cephadm binary from a temporary file to the final location::
+
+    cephadm_invoker.py deploy_binary <temp_file> <final_path>
+
+``check_binary``
+
+Check if a cephadm binary exists::
+
+    cephadm_invoker.py check_binary <cephadm_binary_path>
+
+Returns exit code 0 if the file exists, 2 if it does not exist.
+
+Exit Codes
+----------
+
+- ``0``: Success
+- ``1``: General error (file not found, permission issues, etc.)
+- ``2``: Binary hash mismatch or file doesn't exist (triggers redeployment)
+- ``126``: Permission denied during execution
+
+Security Features
+-----------------
+
+The cephadm invoker provides the following security features:
+
+- **Binary Hash Verification**: Validates the cephadm binary integrity before execution
+- **Restricted Execution**: Only allows execution of verified cephadm binaries
+- **Secure Deployment**: Safely deploys cephadm binaries with proper permissions
+- **Logging**: Comprehensive logging to both console and syslog for audit trails

doc/dev/cephadm/index.rst

@@ -11,5 +11,6 @@ CEPHADM Developer Documentation
    developing-cephadm
    host-maintenance
    compliance-check
+   cephadm-invoker
    Storage devices and OSDs management <./design/storage_devices_and_osds>
    scalability-notes

doc/dev/cephfs-mirroring.rst

@@ -326,8 +326,48 @@ For example:
   ]
 
 One entry per mirror-daemon instance is displayed, along with information
-including configured peers and basic statistics. For more detailed statistics,
-use the admin socket interface as detailed below.
+including configured peers and basic statistics.
+
+**Directory snapshot sync metrics (mgr)**
+
+The mirroring module implements ``ceph fs snapshot mirror status``. The
+``cephfs-mirror`` daemon persists per-directory sync statistics to the
+``cephfs_mirror`` object omap in the metadata pool so the Manager can expose
+them through the Ceph CLI without an admin socket on a mirror daemon host. The
+``metrics_status`` handler reads that omap, applies stale detection and default
+idle metrics for newly mirrored directories, and returns JSON in the same nested
+``metrics/<dir>/peer/<uuid>`` format as ``fs mirror peer status``. When
+``snapshot_mirror_metrics_cache_enabled`` is true (default TTL 15 seconds via
+``snapshot_mirror_metrics_cache_ttl``), responses are served from a complete
+cache (full file system snapshot) and, for single-directory queries, a partial
+per-directory cache that avoids full omap scans on complete-cache miss. When
+caching is disabled, each query reads omap directly. Omap entries are marked
+``stale`` when the persisted ``_instance_id`` is not among live mirror instances
+or does not match the directory's tracked instance while persisted state is not
+``idle``.
+
+Each omap value includes metadata fields written by ``cephfs-mirror``:
+
+- ``_instance_id`` — RADOS client instance of the writer; used for stale
+  detection and stripped from CLI output.
+- ``metrics_updated_at`` — wall-clock time of the last omap write. Exposed in
+  ``ceph fs snapshot mirror status`` output only; omitted from admin socket
+  ``fs mirror peer status``, which reads live in-memory state and does not
+  need a separate persist timestamp. Operators use this field to judge how
+  fresh omap-backed metrics are, given ``cephfs_mirror_tick_interval`` omap
+  persist cadence and Manager caching (``snapshot_mirror_metrics_cache_enabled``
+  and ``snapshot_mirror_metrics_cache_ttl``).
+
+Omap entries are removed when a directory is removed from mirroring. All metric
+fields are written to omap; on daemon restart only ``last_synced_snap`` metadata
+is loaded back. Per-session counters (``snaps_synced``, ``snaps_deleted``,
+``snaps_renamed``) are persisted but not loaded and therefore start at zero each
+session.
+
+See :ref:`Directory snapshot sync metrics<cephfs_mirroring_mgr_snapshot_status>`
+and :ref:`Snapshot sync metric fields<cephfs_mirroring_sync_metric_fields>` in
+:doc:`/cephfs/cephfs-mirroring` for command syntax, examples, and operator
+guidance.
 
 CephFS mirror daemons provide admin socket commands for querying mirror status.
 To list the available commands for ``mirror status``, run the following
@@ -393,20 +433,35 @@ status. Commands of this kind take the form ``filesystem-name@filesystem-id peer
 ::
 
   {
-    "/d0": {
-        "state": "idle",
-        "last_synced_snap": {
-            "id": 120,
-            "name": "snap1",
-            "sync_duration": 0.079997898999999997,
-            "sync_time_stamp": "274900.558797s"
-        },
-        "snaps_synced": 2,
-        "snaps_deleted": 0,
-        "snaps_renamed": 0
+    "metrics": {
+        "/d0": {
+            "peer": {
+                "a2dc7784-e7a1-4723-b103-03ee8d8768f8": {
+                    "state": "idle",
+                    "last_synced_snap": {
+                        "id": 120,
+                        "name": "snap1",
+                        "crawl_duration": "2s",
+                        "datasync_queue_wait_duration": "1s",
+                        "sync_duration": "33s",
+                        "sync_time_stamp": "2026-07-15T12:00:00.558797+0530",
+                        "sync_bytes": "149.94 MiB",
+                        "sync_files": 5000
+                    },
+                    "snaps_synced": 2,
+                    "snaps_deleted": 0,
+                    "snaps_renamed": 0
+                }
+            }
+        }
     }
   }
 
+Several fields in the status output are formatted for readability rather than reported as raw
+numbers. See :ref:`Value formatting <cephfs_mirror_peer_status_formatting>` in
+:doc:`/cephfs/cephfs-mirroring` for duration, data size, throughput, percentage, count, and
+timestamp formats.
+
 Synchronization stats such as ``snaps_synced``, ``snaps_deleted`` and
 ``snaps_renamed`` are reset when the daemon is restarted or (when multiple
 mirror daemons are deployed), when a directory is reassigned to another mirror
@@ -419,6 +474,49 @@ A directory can be in one of the following states::
   - `syncing`: The directory is currently being synchronized
   - `failed`: The directory has hit upper limit of consecutive failures
 
+::
+
+  {
+    "metrics": {
+        "/d0": {
+            "peer": {
+                "a2dc7784-e7a1-4723-b103-03ee8d8768f8": {
+                    "state": "syncing",
+                    "current_syncing_snap": {
+                        "id": 121,
+                        "name": "snap2",
+                        "sync-mode": "full",
+                        "avg_read_throughput_bytes": "13.03 MiB/s",
+                        "avg_write_throughput_bytes": "24.24 MiB/s",
+                        "crawl": {
+                            "state": "completed",
+                            "duration": "2s"
+                        },
+                        "datasync_queue_wait": {
+                            "state": "complete",
+                            "duration": "1s"
+                        },
+                        "bytes": {
+                            "sync_bytes": "60.40 MiB",
+                            "total_bytes": "149.94 MiB",
+                            "sync_percent": "40.29%"
+                        },
+                        "files": {
+                            "sync_files": 2013,
+                            "total_files": 5000,
+                            "sync_percent": "40.26%"
+                        },
+                        "eta": "7s"
+                    },
+                    "snaps_synced": 2,
+                    "snaps_deleted": 0,
+                    "snaps_renamed": 0
+                }
+            }
+        }
+    }
+  }
+
 When a directory hits a configured number of consecutive synchronization
 failures, the mirror daemon marks it as ``failed``. Synchronization for these
 directories is retried. By default, the number of consecutive failures before a
@@ -439,23 +537,37 @@ status:
 ::
 
   {
-    "/d0": {
-        "state": "idle",
-        "last_synced_snap": {
-            "id": 120,
-            "name": "snap1",
-            "sync_duration": 0.079997898999999997,
-            "sync_time_stamp": "274900.558797s"
+    "metrics": {
+        "/d0": {
+            "peer": {
+                "a2dc7784-e7a1-4723-b103-03ee8d8768f8": {
+                    "state": "idle",
+                    "last_synced_snap": {
+                        "id": 120,
+                        "name": "snap1",
+                        "crawl_duration": "2s",
+                        "datasync_queue_wait_duration": "1s",
+                        "sync_duration": "33s",
+                        "sync_time_stamp": "2026-07-15T12:00:00.558797+0530",
+                        "sync_bytes": "149.94 MiB",
+                        "sync_files": 5000
+                    },
+                    "snaps_synced": 2,
+                    "snaps_deleted": 0,
+                    "snaps_renamed": 0
+                }
+            }
         },
-        "snaps_synced": 2,
-        "snaps_deleted": 0,
-        "snaps_renamed": 0
-    },
-    "/f0": {
-        "state": "failed",
-        "snaps_synced": 0,
-        "snaps_deleted": 0,
-        "snaps_renamed": 0
+        "/f0": {
+            "peer": {
+                "a2dc7784-e7a1-4723-b103-03ee8d8768f8": {
+                    "state": "failed",
+                    "snaps_synced": 0,
+                    "snaps_deleted": 0,
+                    "snaps_renamed": 0
+                }
+            }
+        }
     }
   }
 

doc/dev/continuous-integration.rst

@@ -94,6 +94,33 @@ Shaman
    for its `Web UI`_. But please note, shaman does not build the
    packages, it just offers information on the builds.
 
+ceph-perf-pull-requests
+-----------------------
+
+``ceph-perf-pull-requests`` runs CBT performance regression checks on dedicated
+``performance`` Jenkins agents. The job definition lives in `ceph-build`_ and
+generates two jobs from a single template: ``ceph-perf-classic`` and
+``ceph-perf-crimson``.
+
+A pull request can trigger a run with::
+
+    jenkins test classic perf
+    jenkins test crimson perf
+
+The ``performance`` label is also whitelisted for automatic runs. Each job:
+
+#. checks out ``ceph-main`` (``origin/main``) and the PR merge ref
+#. builds both trees (classic ``vstart-base`` or Crimson ``crimson-osd``)
+#. runs the checked-in ``radosbench_4K_read.yaml`` workload via ``run-cbt.sh``
+#. compares PR results against ``main`` with ``cbt/compare.py``
+#. publishes a GitHub check named ``perf-test-{classic,crimson}``
+
+The benchmark YAML is always taken from ``ceph-main`` so PR and baseline runs use
+the same workload definition. Teuthology-to-CBT translation is handled by
+``src/test/crimson/cbt/t2c.py`` in the Ceph tree (not patched at build time).
+
+.. _ceph-build: https://github.com/ceph/ceph-build
+
 As the following shows, `chacra`_ manages multiple projects whose metadata
 are stored in a database. These metadata are exposed via Shaman as a web
 service. `chacractl`_ is a utility to interact with the `chacra`_ service.
@@ -179,9 +206,7 @@ libzbd
     packages `libzbd`_ . The upstream libzbd includes debian packaging already.
 
 libpmem
-    packages `pmdk`_ . Please note, ``ndctl`` is one of the build dependencies of
-    pmdk, for an updated debian packaging, please see
-    https://github.com/ceph/ceph-ndctl .
+    packages `pmdk`_ .
 
 .. note::
 

doc/dev/crimson/index.rst

@@ -101,7 +101,7 @@ run::
   $ MDS=0 MON=1 OSD=1 MGR=1 taskset -ac '0-95' /ceph/src/vstart.sh --new -x \
   --localhost --without-dashboard --redirect-output --seastore --osd-args \
   "--seastore_max_concurrent_transactions=128 --seastore_cachepin_type=LRU \
-  --seastore_main_device_type=RANDOM_BLOCK_SSD" --seastore-devs  /dev/nvme0n1 \
+  --seastore_hot_device_type=RANDOM_BLOCK_SSD" --seastore-devs  /dev/nvme0n1 \
   --crimson  --crimson-smp 1 --no-restart
 
 Another SeaStore example::
@@ -253,7 +253,17 @@ In order to use ``fio`` to test ``crimson-store-nbd``, perform the below steps.
 
 CBT
 ---
-We can use `cbt`_ for performance tests::
+We can use `cbt`_ for performance tests. Benchmark workloads are checked in under
+``src/test/crimson/cbt/`` as teuthology-style YAML files. Before ``run-cbt.sh``
+invokes CBT, ``t2c.py`` translates the teuthology ``tasks`` list into a
+CBT-ready configuration: it extracts the ``cbt`` task, fills in cluster paths
+(``ceph.conf``, ``ceph``/``rados`` binaries, PID directory), and writes the
+result to a temporary YAML file consumed by ``cbt.py``.
+
+Unit tests for the translator live in ``src/test/crimson/cbt/test_t2c.py`` and
+are registered with ``make check`` via ``add_ceph_test``.
+
+::
 
   $ git checkout main
   $ make crimson-osd
@@ -410,3 +420,5 @@ Code Walkthroughs
    BackfillMachine <backfillmachine>
    SeaStore <seastore>
    PoseidonStore <poseidonstore>
+   PG Merge Synchronization <pgmerging>
+   The Logical Address in SeaStore <seastore_laddr>

doc/dev/crimson/pgmerging.rst

@@ -0,0 +1,106 @@
+===========================================
+PG Merge Synchronization in Crimson
+===========================================
+
+This document describes the infrastructure used to coordinate the merging
+of Placement Groups (PGs) in Crimson.
+
+Background
+----------
+Crimson utilizes a shared-nothing memory model where each PG is owned by
+a specific CPU core. Merging requires cross-core coordination while
+maintaining memory safety and epoch consistency.
+
+Core Concepts
+-------------
+
+.. _migration_safety:
+
+Migration Safety (Memory Ownership)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+PGs are managed by their ``birth_shard``. To prevent cross-shard
+deallocation crashes:
+
+1. **Extraction**: ``ShardServices::extract_pg()`` removes the source PG
+   from its shard map so it stops receiving messages.
+2. **Transportation**: The PG crosses cores in a ``seastar::foreign_ptr``.
+3. **Storage**: The target shard stores each source in
+   ``crimson::local_shared_foreign_ptr<Ref<PG>>`` inside the target PG's
+   rendezvous map. When the target drops the last reference after
+   ``PG::merge_from()``, destruction is routed back to the source
+   ``birth_shard``.
+
+.. _synchronization:
+
+Target and Source PG Synchronization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Merging involves a race between source PGs checking in and the target PG
+reaching the merge point in ``PGAdvanceMap``.
+
+Synchronization state lives on the **target PG**, not in a per-shard
+registry:
+
+* **``merge_rendezvous_t``**: A map of arrived sources plus a
+  ``seastar::semaphore`` counting first-time registrations.
+* **``PG::add_merge_source()``**: Called on the target's shard when
+  ``ShardServices::register_merge_source()`` delivers a source PG.
+  Duplicate source pgids are ignored (idempotent under replay).
+* **``PG::collect_merge_sources(n)``**: Waits on the rendezvous semaphore
+  for ``n`` arrivals (one signal per first insert), asserts the map has
+  ``n`` entries, then returns sources and clears the rendezvous.  If
+  ``reset_merge_rendezvous()`` breaks the wait, returns an empty map.
+* **``PG::reset_merge_rendezvous()``**: Clears in-flight handoffs and
+  resets the semaphore. Called on ``PG::stop()`` or after a Seastore
+  cross-shard abort so a failed try cannot leave stale sources for a
+  later epoch.
+
+**Cross-shard handoff**: ``register_merge_source()`` resolves the target
+shard, extracts the source locally, and uses ``invoke_on`` to call
+``add_merge_source()`` on the target PG.
+
+.. _map_consistency:
+
+Map Advancement and Pipeline Stalling
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To ensure the merge occurs between PGs at the same logical time:
+
+* ``PGAdvanceMap::check_for_merges()`` detects ``pg_num`` shrink between
+  map epochs and returns a ``merge_result_t`` (source, target, or none).
+* ``merge_pg()`` performs merge-specific work only (Seastore eligibility,
+  rendezvous collection, ``PG::merge_from()`` on the target).
+* A single ``PGAdvanceMap`` operation may batch multiple map epochs
+  (``from`` through ``to``). Only a **merge source** stops the epoch
+  loop early: ``finish_merge_source()`` commits ``rctx``, stops the PG,
+  and calls ``register_merge_source()``. A **merge target** runs
+  ``merge_from()`` at the merge epoch, then continues advancing through
+  the remaining epochs up to ``to`` (matching classic OSD behavior).
+  Normal completion at the end of ``start()`` activates the final map
+  and commits ``rctx`` (also covering a completed merge target).
+* The target does not call ``merge_from()`` until sources frozen at the
+  merge epoch have arrived on its rendezvous.
+
+.. _seastore_cross_shard:
+
+Seastore Cross-Shard Merges
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Seastore does not support merging collections across reactor shards.
+Before a source hands off or a target collects sources, ``merge_pg()``
+calls ``ShardServices::seastore_merge_shards_ok()`` with the full sibling
+set. If the target and any source map to different shards, the OSD aborts
+the attempt: clears ready-to-merge state, sends
+``MOSDPGReadyToMerge{ ready=false }`` for the source so the monitor does
+not commit the unsafe ``pg_num`` decrement, resets the target rendezvous,
+and sends ``MOSDPGStopMerge`` to the monitor (once per pool per OSD).
+The monitor clamps ``pg_num_target`` to ``pg_num`` and clears
+``FLAG_CRIMSON_ALLOW_PG_MERGE`` for that pool until operators re-enable
+merging (``crimson_allow_pg_merge``).
+
+Cleanup
+-------
+After ``complete_rctx()``, the target releases its ``local_shared_foreign_ptr``
+references; source PG objects are destroyed on their ``birth_shard``.
+
+When the OSD finishes consuming a new OSDMap in ``OSD::committed_osd_maps()``,
+``OSDSingletonState::prune_sent_ready_to_merge()`` drops ``sent_ready_to_merge_source``
+entries (and stale ``pools_merge_stopped_reported`` pool ids) for PGs that no
+longer exist in the committed map, mirroring classic ``OSD::consume_map()``.

doc/dev/crimson/seastore.rst

@@ -204,7 +204,7 @@ Metadata Structures
 Device Types
 ------------
 
-Configured via the ``seastore_main_device_type`` option, the device types are
+Configured via the ``seastore_hot_device_type`` option, the device types are
 separated into **Segmented** and **RBM** backend types as follows:
 
 

doc/dev/crimson/seastore_laddr.rst

@@ -201,7 +201,8 @@ after the upgrade finishes.
 
 TODO: fsck/tooling must support scanning and migrating all mappings
 between upgrades.
-             //create tracker after PR merged/ready.
+
+//create tracker after PR merged/ready.
 
 Multi-push Recovery
 -------------------

doc/dev/crimson/seastore_logical_bucket_cache.rst

@@ -0,0 +1,85 @@
+=====================================
+ The Logical Bucket Cache in SeaStore
+=====================================
+
+This document introduces the LogicalBucketCache machinery which is
+mainly for using SSDs as non-volatile cache for the relatively slow
+HDD devices. Specifically, it serves to:
+
+#. Load frequently accessed data from the cold tier to the Logical
+   Bucket Cache.
+#. Evict relatively cold data from the Logical Bucket Cache to the
+   cold tier based on the heat of both data read and write.
+
+The Logical Bucket Cache is enabled when there is at least one cold
+tier.
+
+General Approach
+================
+
+#. Cache line: a range of continuous laddr address space, which we
+   call logical bucket. For now, that continuous laddr range is the
+   scope of a RADOS object.
+#. Extents are loaded to the cache device when: 1) they are newly
+   written by clients and don't trigger the write_through machinery.
+   For now, the write_through machinery is triggered when the newly
+   written data is larger than a specific threshold; 2) they are on
+   the slow cold device and read to or evicted from the in-memory Cache.
+#. Extents are evicted from the cache device in units of logical buckets,
+   that is, extents of the same logical bucket are evicted from the cache
+   device altogether.
+#. The process that write extents evicted from Cache down to the cache
+   device is called promotion.
+#. The process that evict extents from the cache device to the cold device
+   is called demotion.
+#. Extents that are loaded from the cold tier to the Logical Bucket Cache
+   are NOT removed from the cold tier, which means they'd have two paddrs,
+   one in the Logical Bucket Cache, the other in the cold tier, and the
+   promoted data is stored twice. This is designed to make the demote process
+   cheap. We call paddrs corresponding to the cold tier shadow paddrs.
+   So lba mappings have two paddrs now, the primary paddr and the shadow
+   paddr.
+
+Promotion
+=========
+
+Promotion is the process that load the extents in the cold tier to the
+Logical Bucket Cache.
+
+Extents that are read from the cold tier are first added to the in-memory
+cache; when evicted from the in-memory cache, they are added to the Promoter.
+
+The Promoter write its extents down to the Logical Bucket Cache when the size
+of its extents grows larger than ``seastore_cache_promotion_size``.
+
+Demotion
+========
+
+Demotion happens when:
+
+#. The usage of the Logical Bucket Cache reaches ``seastore_multiple_tiers_fast_evict_ratio``.
+#. The in-memory data index of the Logical Bucket Cache reaches ``seastore_logical_bucket_capacity``.
+
+Demoting extents that are live in both the Logical Bucket Cache and the
+cold tier only involves setting the shadow paddr to the primary paddr and
+removing the shadow paddr itself.
+
+Demoting extents that are only live in the Logical Bucket Cache would involve
+rewriting the extents to the cold tier.
+
+WriteThrough
+============
+
+When the newly written data is larger than ``seastore_write_through_size``,
+it would be written directly to the cold tier.
+
+Internal Test Workload
+=======================
+
+To test the correctness of the whole Logical Bucket Cache machinery, we also
+implemented an internal stress test workload. When turned on, SeaStore would
+aggressively load the extents from the cold tier to the Logical Bucket Cache,
+and demote extents back to the cold tier. The newly written data may also be
+written directly to the cold tier based on ``seastore_test_workload_write_through_probability``.
+
+The internal test workload is turned on by ``crimson_test_workload``.

doc/dev/developer_guide/tests-unit-tests.rst

@@ -71,6 +71,31 @@ teuthology using the `cram task`_.
 .. _`cram`: https://bitheap.org/cram/
 .. _`cram task`: https://github.com/ceph/ceph/blob/master/qa/tasks/cram.py
 
+Running CLI tools tests
+-----------------------
+
+A convenience script is provided to run CLI tests easily without having to manually set up the environment.
+From the Ceph source tree root directory:
+
+  .. prompt:: bash $
+
+     # Run all CLI tests
+     ./src/script/run-cli-tests.sh
+
+     # Run with custom build directory
+     ./src/script/run-cli-tests.sh -b /path/to/build
+
+Alternatively, you can run the tests directly from the build directory by setting up your PATH:
+
+  .. prompt:: bash $
+
+     cd build
+     PATH="$PWD/bin:$PATH" ../src/test/run-cli-tests
+
+The test suite includes tests for: ``ceph-authtool``, ``ceph-conf``, 
+``ceph-kvstore-tool``, ``crushtool``, ``monmaptool``, ``osdmaptool``, 
+``radosgw-admin``, and ``rbd``.
+
 Tox-based testing of Python modules
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Some of the Python modules in Ceph use `tox <https://tox.readthedocs.io/en/latest/>`_ 

doc/dev/osd_internals/erasure_coding/client_support.rst

@@ -466,7 +466,7 @@ These operations provide the same semantics as in replicated pools, ensuring
 compatibility with existing applications.
 
 Read Operation Flow
-~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~
 
 Read operations follow a simple flow:
 
@@ -906,9 +906,10 @@ Required Settings
 
 To enable the new features, the following OSDMap pool settings are required:
 
-- ``allows_ec_overwrites = true`
+- ``allows_ec_overwrites = true``
 - ``allows_ec_optimizations = true``
-- ``supports_omap = true``
 
 These settings can be configured per-pool. The cluster will enforce that all
-OSDs are at the Umbrella release before allowing omap support to be enabled.
+OSDs are at the Umbrella release before allowing omap support to be enabled.
+
+The `supports_omap` pool flag is automatically enabled in pools with EC optimizations enabled.

doc/dev/release-checklists.rst

@@ -41,8 +41,7 @@ Make sure X (and, ideally, X+1) is defined:
 Github Actions
 ~~~~~~~~~~~~~~
 
-- [ ] .github/workflows/redmine-upkeep.yml add release branch to pull_request_target trigger
-- [ ] .github/workflows/releng-audit.yml add release branch to pull_request_target trigger
+- [ ] `.github/workflows/*.yml' add release branch to pull_request_target trigger
 
 Scripts
 ~~~~~~~
@@ -137,6 +136,8 @@ After dev freeze
 - [ ] open the Branch Protection settings of the Ceph repo.  Duplicate settings to the new release branch.
 - [ ] create vX.3.0 annotated tag on ``main`` so upgrades from new release to main are not wrongly considered downgrades.
 - [ ] remove ``doc/releases/*.rst``. This should leave behind ``doc/releases/releases.yml`` which is used for doc building purposes. See also commit 33d63c3 ("doc: remove release notes for release branch") for details.
+- [ ] remove ``.github/workflows``. ``main`` is authoritative for workflows; avoid possible confusion/conflicts.
+- [ ] remove ``.github/pull_request_template.md``. Backports do not use it.
 - [ ] cherry-pick 8cf9ad62949516666ad0f2c0bb7726ef68e4d666 ("doc: add releases links to toc"). There will be trivial conflicts.
 - [ ] add redirect for new major release at `RTD <https://readthedocs.org/dashboard/ceph/redirects/>`_.
 - [ ] add release name to redmine (using https://tracker.ceph.com/custom_fields/16/edit)

doc/dev/release-process.rst

@@ -87,8 +87,8 @@ Once QE has determined a stopping point in the working (e.g., ``squid``) branch,
 
 Notify the "Build Lead" that the release branch is ready.
 
-2. Starting the build
-=====================
+2a. Starting the build
+======================
 
 We'll use a stable/regular 19.2.2 release of Squid as an example throughout this document.
 
@@ -104,25 +104,52 @@ We'll use a stable/regular 19.2.2 release of Squid as an example throughout this
 
 NOTE: if for some reason the build has to be restarted (for example if one distro failed) then the ``TAG`` option has to be unchecked.
 
-4. Use https://docs.ceph.com/en/latest/start/os-recommendations/?highlight=debian#platforms to determine the ``DISTROS`` parameter.  For example,
+4. Use :ref:`start-platforms` to determine the ``DISTROS`` parameter.  For example,
 
-    +-------------------+--------------------------------------------------+
-    | Release           | Distro Codemap                                   |
-    +===================+==================================================+
-    | pacific (16.X.X)  | ``focal bionic buster bullseye``                 |
-    +-------------------+--------------------------------------------------+
-    | quincy (17.X.X)   | ``jammy focal centos9 bullseye``                 |
-    +-------------------+--------------------------------------------------+
-    | reef (18.X.X)     | ``jammy focal centos9 windows bookworm``         |
-    +-------------------+--------------------------------------------------+
-    | squid (19.X.X)    | ``jammy centos9 windows bookworm``               |
-    +-------------------+--------------------------------------------------+
-    | tentacle (20.X.X) | ``jammy centos9 noble windows bookworm rocky10`` |
-    +-------------------+--------------------------------------------------+
+    +-------------------+---------------------------------------------------------+
+    | Release           | Distro Codemap                                          |
+    +===================+=========================================================+
+    | squid (19.X.X)    | ``jammy centos9 windows bookworm``                      |
+    +-------------------+---------------------------------------------------------+
+    | tentacle (20.X.X) | ``jammy centos9 rocky10 windows bookworm``              |
+    +-------------------+---------------------------------------------------------+
+    | umbrella (21.X.X) | ``jammy noble centos9 rocky10 bookworm trixie windows`` |
+    +-------------------+---------------------------------------------------------+
 
 
 5. Click ``Build``.
 
+2b. What to do if your build fails
+==================================
+
+The ceph-release-pipeline parent job has three stages.
+
+If your build fails during the "create ceph release tag" stage, troubleshoot the child ceph-tag job and re-run the parent ceph-release-pipeline job with the same parameters.
+
+----
+
+If your build fails during the "package build" stage, troubleshoot the child ceph-dev-pipeline job.  If only one variant failed to build (e.g., centos9 arm64), start a new ceph-release-pipeline job specifying::
+
+    DISTROS=centos9
+    ARCHS=arm64
+    TAG=false <-- VERY IMPORTANT
+
+This will leave the version commit and previously-created tag intact in ceph-releases.git.  You will want the subsequent ceph-dev-pipeline job to reuse that SHA/tag.
+
+Once all of your variants are successfully built, you will have to manually run the ceph-tag job.  For example,::
+
+    BRANCH=tentacle
+    TAG=true
+    TAG_PHASE=push
+    VERSION=20.2.0
+    RELEASE_TYPE=STABLE
+
+Then proceed with the normal release process.
+
+----
+
+If your build fails during the "push ceph release tag" stage, troubleshoot the child ceph-tag job and re-run **just** the ceph-tag job again manually.  Do not re-run ceph-release-pipeline.
+
 3. Release Notes
 ================
 
@@ -178,18 +205,57 @@ See `the Ceph Tracker wiki page that explains how to write the release notes <ht
 
    .. prompt:: bash
 
-      merfi gpg /opt/repos/ceph/squid-19.2.2/debian/
+      sign-debs ceph squid
 
    Example::
 
+      + project=ceph
+      + releases=(squid)
+      + distro_versions=(jessie)
+      + for release in "${releases[@]}"
+      + for distro_version in "${distro_versions[@]}"
+      + for path in /opt/repos/ceph/squid*
+      + '[' -d /opt/repos/ceph/squid-19.2.2/debian/jessie ']'
+      + needs_signing=0
+      + gpg --verify /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release.gpg /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release
+      + needs_signing=1
+      + break
+      + '[' 1 -eq 0 ']'
+      + echo 'Signing: /opt/repos/ceph/squid-19.2.2/debian/jessie'
+      Signing: /opt/repos/ceph/squid-19.2.2/debian/jessie
+      + merfi gpg /opt/repos/ceph/squid-19.2.2/debian/jessie
       --> Starting path collection, looking for files to sign
-      --> 1 repos found
+      --> 2 repos found
       --> signing: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release
       --> Running command: gpg --batch --yes --armor --detach-sig --output Release.gpg Release
       --> Running command: gpg --batch --yes --clearsign --output InRelease Release
       --> signing: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/Release
       --> Running command: gpg --batch --yes --armor --detach-sig --output Release.gpg Release
       --> Running command: gpg --batch --yes --clearsign --output InRelease Release
+      + gpg --verify /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release.gpg /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release
+      gpg: Signature made Thu May 14 12:00:00 2026 UTC
+      gpg:                using RSA key 460F3994
+      gpg: Good signature from "Ceph Release Key <security@ceph.com>"
+      + echo 'verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release.gpg'
+      verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/Release.gpg
+      + gpg --verify /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/InRelease
+      gpg: Signature made Thu May 14 12:00:00 2026 UTC
+      gpg:                using RSA key 460F3994
+      gpg: Good signature from "Ceph Release Key <security@ceph.com>"
+      + echo 'verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/InRelease'
+      verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/bookworm/InRelease
+      + gpg --verify /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/Release.gpg /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/Release
+      gpg: Signature made Thu May 14 12:00:00 2026 UTC
+      gpg:                using RSA key 460F3994
+      gpg: Good signature from "Ceph Release Key <security@ceph.com>"
+      + echo 'verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/Release.gpg'
+      verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/Release.gpg
+      + gpg --verify /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/InRelease
+      gpg: Signature made Thu May 14 12:00:00 2026 UTC
+      gpg:                using RSA key 460F3994
+      gpg: Good signature from "Ceph Release Key <security@ceph.com>"
+      + echo 'verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/InRelease'
+      verifying: /opt/repos/ceph/squid-19.2.2/debian/jessie/dists/jammy/InRelease
 
       etc...
 

doc/foundation.rst

@@ -20,59 +20,11 @@ cost.
 For more information, see `https://ceph.com/foundation
 <https://ceph.com/foundation>`_.
 
-
 Members
 =======
 
-Diamond
--------
+Visit `https://ceph.io/en/foundation/members/ <https://ceph.io/en/foundation/members/>`_ to see the full list of Ceph Foundation Members
 
-* `45Drives <https://45drives.com/>`_
-* `Bloomberg <https://bloomberg.com>`_
-* `IBM <https://ibm.com>`_
-* `Clyso <https://www.clyso.com/en/>`_
-
-
-Platinum
---------
-
-* `Western Digital <https://westerndigital.com/>`_
-
-
-Gold
-----
-
-* `42on <https://www.42on.com/>`_
-* `OVH <https://www.ovh.com/>`_
-* `Samsung Electronics <https://samsung.com/>`_
-
-
-Silver
-------
-
-* `Canonical <https://www.canonical.com/>`_
-* `CloudFerro <https://cloudferro.com/>`_
-* `croit <http://www.croit.io/>`_
-* `Digital Ocean <http://digitalocean.com/>`_
-* `ISS <http://iss-integration.com/>`_
-* `Intel <http://www.intel.com/>`_
-* `OSNexus <https://osnexus.com/>`_
-* `Sony Interactive <https://sonyinteractive.com/>`_
-
-Associate
----------
-
-* `Boston University <http://www.bu.com/>`_
-* `Center for Research in Open Source Systems (CROSS) <http://cross.ucsc.edu/>`_
-* `CERN <https://home.cern/>`_
-* `FASRC <https://www.rc.fas.harvard.edu/>`_
-* `grnet <https://grnet.gr/>`_
-* `Monash University <http://www.monash.edu/>`_
-* `NRF SARAO <http://www.ska.ac.za/about/sarao/>`_
-* `Open Infrastructure Foundation <http://openinfra.dev>`_
-* `Science & Technology Facilities Councel (STFC) <https://stfc.ukri.org/>`_
-* `SWITCH <https://switch.ch/>`_
-* `University of Michigan <http://www.osris.org/>`_
 
 Governing Board
 ===============
@@ -97,21 +49,6 @@ engineering activities are managed through traditional open source
 processes and are overseen by the :ref:`csc`. For more
 information see :ref:`governance`.
 
-Members
--------
-
-* Brett Kelly (45Drives)
-* Enrico Bocchi (CERN) - Associate member representative
-* Dan van der Ster (Clyso) - Ceph Council representative
-* Joachim Kraftmayer (Clyso)
-* Josh Durgin (IBM) - Ceph Council representative
-* Matthew Leonard (Bloomberg)
-* Anthony Middleton (Linux Foundation) - Ceph Community Manager
-* Neha Ojha (IBM) - Ceph Council Representative
-* Steven Umbehocker (OSNexus) - General member representative
-* Pawel Sadowski (OVH)
-* Sungmin Lee (Samsung Electronics)
-* Vincent Hsu (IBM)
 
 Joining
 =======

doc/glossary.rst

@@ -353,9 +353,8 @@
                 reduce the time it takes to read data from and to write to the
                 Ceph cluster. RGW bucket indexes are stored as omaps.
                 Erasure-coded pools, by default, cannot store RADOS omap data
-                structures. This functionality can be enabled in erasure-coded
-                pools with optimizations enabled by setting the
-                ``supports_omap`` flag to true.
+                structures. This functionality can be enabled in non-Crimson
+                erasure-coded pools by enabling EC optimizations.
                
                 Run the command ``ceph osd df`` to see the storage space used by
                 omaps on each OSD.

doc/governance.rst

@@ -38,8 +38,7 @@ Membership
  * Candidates self-nominate or are nominated by other members
  * Discussion of how roles/responsibilities may be delegated
  * Ranked-choice vote by the steering committee
- * 2 year terms, with one member being elected in even years, and the
-   other two in odd years
+ * 1 year terms with all members elected yearly
  * Members may resign at any time, and the steering committee may vote
    to appoint a replacement for the rest of their term
  * members must involve >1 employer
@@ -86,6 +85,7 @@ Current Members
  * Adam King <adking@redhat.com>
  * Afreen Misbah <afreen@ibm.com>
  * Anthony D'Atri <anthony.datri@gmail.com>
+ * Aviv Caro <Aviv.Caro@ibm.com>
  * Casey Bodley <cbodley@redhat.com>
  * Dan van der Ster <dan.vanderster@clyso.com>
  * David Orman <ormandj@1111systems.com>
@@ -99,15 +99,18 @@ Current Members
  * Joseph Mundackal <jmundackal@bloomberg.net>
  * Josh Durgin <jdurgin@redhat.com>
  * João Eduardo Luis <joao@clyso.com>
- * Laura Flores <lflores@redhat.com>
+ * Kyle Bader <kbader@ibm.com>
+ * Laura Flores <lflores@ibm.com>
  * Mark Nelson <mark.nelson@clyso.com>
  * Matan Breizman <mbreizma@redhat.com>
  * Matt Benjamin <mbenjami@redhat.com>
  * Mike Perez <miperez@redhat.com>
  * Myoungwon Oh <ohmyoungwon@gmail.com>
+ * Sage McTaggart <sagemct@ibm.com>
  * Neha Ojha <nojha@redhat.com>
  * Patrick Donnelly <pdonnell@ibm.com>
  * Radoslaw Zarzynski <rzarzyns@redhat.com>
+ * Redouane Kachach <rkachach@redhat.com>
  * Venky Shankar <vshankar@redhat.com>
  * Vikhyat Umrao <vikhyat@ibm.com>
  * Xie Xingguo <xie.xingguo@zte.com.cn>

doc/hardware-monitoring/index.rst

@@ -88,7 +88,8 @@ Supported categories are:
 * network
 * power
 * fans
-* firmwares
+* temperatures
+* firmware
 * criticals
 
 
@@ -143,7 +144,7 @@ ________________
 
 .. prompt:: bash # auto
 
-  # ceph orch hardware status node-10 --category firmwares
+  # ceph orch hardware status node-10 --category firmware
   +------------+----------------------------------------------------------------------------+--------------------------------------------------------------+----------------------+-------------+--------+
   |    HOST    |                                 COMPONENT                                  |                             NAME                             |         DATE         |   VERSION   | STATUS |
   +------------+----------------------------------------------------------------------------+--------------------------------------------------------------+----------------------+-------------+--------+
@@ -187,6 +188,7 @@ For Developers
 .. automethod:: NodeProxyEndpoint.power
 .. automethod:: NodeProxyEndpoint.processors
 .. automethod:: NodeProxyEndpoint.fans
-.. automethod:: NodeProxyEndpoint.firmwares
+.. automethod:: NodeProxyEndpoint.temperatures
+.. automethod:: NodeProxyEndpoint.firmware
 .. automethod:: NodeProxyEndpoint.led
 

doc/install/build-ceph.rst

@@ -42,13 +42,13 @@ repository and execute the following::
     cd build
     ninja
 
-See `Installing a Build`_ to install a build in user space and `Ceph README.md`_
+See :ref:`install-storage-cluster-build` to install a build in user space and `Ceph README.md`_
 doc for more details on build.
 
 Build Ceph Packages
 ===================
 
-To build packages, you must clone the `Ceph`_ repository. You can create 
+To build packages, you must clone the :ref:`Ceph repository <install-clone-source>`. You can create
 installation packages from the latest code using ``dpkg-buildpackage`` for 
 Debian/Ubuntu or ``rpmbuild`` for the RPM Package Manager.
 
@@ -61,7 +61,7 @@ Advanced Package Tool (APT)
 ---------------------------
 
 To create ``.deb`` packages for Debian/Ubuntu, ensure that you have cloned the 
-`Ceph`_ repository, installed the `Build Prerequisites`_ and installed 
+:ref:`Ceph repository <install-clone-source>`, installed the `Build Prerequisites`_ and installed
 ``debhelper``::
 
 	sudo apt-get install debhelper
@@ -76,7 +76,7 @@ For multi-processor CPUs use the ``-j`` option to accelerate the build.
 RPM Package Manager
 -------------------
 
-To create ``.rpm`` packages, ensure that you have cloned the `Ceph`_ repository,
+To create ``.rpm`` packages, ensure that you have cloned the :ref:`Ceph repository <install-clone-source>`,
 installed the `Build Prerequisites`_ and installed ``rpm-build`` and 
 ``rpmdevtools``::
 
@@ -104,6 +104,4 @@ Build the RPM packages::
 
 For multi-processor CPUs use the ``-j`` option to accelerate the build.
 
-.. _Ceph: ../clone-source
-.. _Installing a Build: ../install-storage-cluster#installing-a-build
 .. _Ceph README.md: https://github.com/ceph/ceph#building-ceph

doc/install/clone-source.rst

@@ -1,3 +1,5 @@
+.. _install-clone-source:
+
 =========================================
  Cloning the Ceph Source Code Repository
 =========================================

doc/install/get-packages.rst

@@ -123,7 +123,7 @@ For RPMs::
 The major releases of Ceph are summarized at: :ref:`Releases <ceph-releases-index>`
 
 .. tip:: For non-US users: There might be a mirror close to you where
-         to download Ceph from. For more information see: `Ceph Mirrors`_.
+         to download Ceph from. For more information see: :ref:`install-mirrors`.
 
 Debian Packages
 ~~~~~~~~~~~~~~~
@@ -168,7 +168,7 @@ of Debian and Ubuntu releases supported.
    echo deb https://download.ceph.com/debian-testing/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list
 
 .. tip:: For non-US users: There might be a mirror close to you where
-         to download Ceph from. For more information see: `Ceph Mirrors`_.
+         to download Ceph from. For more information see: :ref:`install-mirrors`.
 
 
 RPM Packages
@@ -234,7 +234,7 @@ You can download the RPMs directly from
    https://download.ceph.com/rpm-testing
 
 .. tip:: For non-US users: There might be a mirror close to you where
-         to download Ceph from. For more information see: `Ceph Mirrors`_.
+         to download Ceph from. For more information see: :ref:`install-mirrors`.
 
 openSUSE Leap 15.1
 ^^^^^^^^^^^^^^^^^^
@@ -389,4 +389,3 @@ line to get the short codename.
 
 .. _the testing Debian repository: https://download.ceph.com/debian-testing/dists
 .. _the shaman page: https://shaman.ceph.com
-.. _Ceph Mirrors: ../mirrors

doc/install/get-tarballs.rst

@@ -7,8 +7,7 @@ source code. You may download source code tarballs for Ceph releases here:
 
 `Ceph Release Tarballs`_
 
-.. tip:: For international users: There might be a mirror close to you where download Ceph from. For more information see: `Ceph Mirrors`_.
+.. tip:: For international users: There might be a mirror close to you where download Ceph from. For more information see: :ref:`install-mirrors`.
 
 
 .. _Ceph Release Tarballs: https://download.ceph.com/tarballs/
-.. _Ceph Mirrors: ../mirrors

doc/install/index.rst

@@ -24,7 +24,6 @@ in Kubernetes, while also enabling management of storage resources and
 provisioning via Kubernetes APIs. We recommend Rook as the way to run Ceph in
 Kubernetes or to connect an existing Ceph storage cluster to Kubernetes.
 
-* Rook supports only Nautilus and newer releases of Ceph.
 * Rook is the preferred method for running Ceph on Kubernetes, or for
   connecting a Kubernetes cluster to an existing (external) Ceph
   cluster.
@@ -34,15 +33,6 @@ Kubernetes or to connect an existing Ceph storage cluster to Kubernetes.
 Other methods
 ~~~~~~~~~~~~~
 
-`ceph-ansible <https://docs.ceph.com/ceph-ansible/>`_ deploys and manages
-Ceph clusters using Ansible.
-
-* ceph-ansible is widely deployed.
-* ceph-ansible is not integrated with the orchestrator APIs that were
-  introduced in Nautilus and Octopus, which means that the management features
-  and dashboard integration introduced in Nautilus and Octopus are not
-  available in Ceph clusters deployed by means of ceph-ansible.
-
 `ceph-salt <https://github.com/ceph/ceph-salt>`_ installs Ceph using Salt and cephadm.
 
 `jaas.ai/ceph-mon <https://jaas.ai/ceph-mon>`_ installs Ceph using Juju.
@@ -63,6 +53,4 @@ Windows
 ~~~~~~~
 
 For Windows installations, consult this document:
-`Windows installation guide`_.
-
-.. _Windows installation guide: ./windows-install
+:ref:`install-windows`.

doc/install/install-storage-cluster.rst

@@ -1,3 +1,5 @@
+.. _install_storage_cluster:
+
 ==============================
  Install Ceph Storage Cluster
 ==============================
@@ -79,6 +81,7 @@ Once you have added either release or development packages, or added a
 
    sudo yum install ceph
 
+.. _install-storage-cluster-build:
 
 Installing a Build
 ==================

doc/install/mirrors.rst

@@ -1,3 +1,5 @@
+.. _install-mirrors:
+
 =============
  Ceph Mirrors
 =============
@@ -24,17 +26,18 @@ These mirrors are available on the following locations:
 - **US-West: US West Coast**: http://us-west.ceph.com/
 - **CN: China**: http://mirrors.ustc.edu.cn/ceph/
 
-You can replace all download.ceph.com URLs with any of the mirrors, for example:
+You can replace all ``download.ceph.com`` URLs with any of the mirrors,
+for example:
 
-- http://download.ceph.com/tarballs/
-- http://download.ceph.com/debian-hammer/
-- http://download.ceph.com/rpm-hammer/
+- https://download.ceph.com/tarballs/
+- https://download.ceph.com/debian-tentacle/
+- https://download.ceph.com/rpm-tentacle/
 
 Change this to:
 
-- http://eu.ceph.com/tarballs/
-- http://eu.ceph.com/debian-hammer/
-- http://eu.ceph.com/rpm-hammer/
+- https://eu.ceph.com/tarballs/
+- https://eu.ceph.com/debian-tentacle/
+- https://eu.ceph.com/rpm-tentacle/
 
 
 Mirroring
@@ -62,4 +65,4 @@ set for all mirrors. These can be found on `GitHub`_.
 If you want to apply for an official mirror, please contact the ceph-users mailinglist.
 
 
-.. _GitHub: https://github.com/ceph/ceph/tree/master/mirroring
+.. _GitHub: https://github.com/ceph/ceph/tree/main/mirroring

doc/install/windows-basic-config.rst

@@ -1,5 +1,7 @@
 :orphan:
 
+.. _install-windows-basic-config:
+
 ===========================
 Windows basic configuration
 ===========================

doc/install/windows-install.rst

@@ -1,5 +1,7 @@
 :orphan:
 
+.. _install-windows:
+
 ==========================
 Installing Ceph on Windows
 ==========================
@@ -15,7 +17,7 @@ Supported platforms
 -------------------
 .. note::
 
-  Please see the `OS recommendations`_ regarding client package support.
+  Please see the :ref:`os-recommendations` regarding client package support.
 
 Windows Server 2019 and Windows Server 2016 are supported. Previous Windows
 Server versions, including Windows client versions such as Windows 10, might
@@ -66,7 +68,7 @@ https://github.com/ceph/ceph/blob/master/README.windows.rst
 Configuration
 =============
 
-Please check the `Windows configuration sample`_ to get started.
+Please check the :ref:`Windows configuration sample <install-windows-basic-config>` to get started.
 
 You'll also need a keyring file. The `General CephFS Prerequisites`_ page provides a
 simple example, showing how a new CephX user can be created and how its secret
@@ -80,12 +82,8 @@ Further reading
 
 * `RBD Windows documentation`_
 * :ref:`CephFS Windows documentation <ceph-dokan>`
-* `Windows troubleshooting`_
+* :ref:`install-windows-troubleshooting`
 
-.. _Windows configuration sample: ../windows-basic-config
 .. _RBD Windows documentation: ../../rbd/rbd-windows/
-.. _Windows troubleshooting: ../windows-troubleshooting
 .. _General CephFS Prerequisites: ../../cephfs/mount-prerequisites
 .. _Client Authentication: ../../cephfs/client-auth
-.. _Windows testing: ../dev/tests-windows
-.. _OS recommendations: ../../start/os-recommendations

doc/install/windows-troubleshooting.rst

@@ -1,5 +1,7 @@
 :orphan:
 
+.. _install-windows-troubleshooting:
+
 ===============================
 Troubleshooting Ceph on Windows
 ===============================

doc/man/8/CMakeLists.txt

@@ -61,6 +61,7 @@ if(WITH_RADOSGW)
 	rgw-orphan-list.rst
 	rgw-gap-list.rst
 	rgw-policy-check.rst
+	rgw-policy-test.rst
 	ceph-diff-sorted.rst
 	rgw-restore-bucket-index.rst)
 endif()

doc/man/8/ceph-bluestore-tool.rst

@@ -20,6 +20,7 @@ Synopsis
 | **ceph-bluestore-tool** qfsck       --path *osd path*
 | **ceph-bluestore-tool** allocmap    --path *osd path*
 | **ceph-bluestore-tool** restore_cfb --path *osd path*
+| **ceph-bluestore-tool** recovery-compare --path *osd path*
 | **ceph-bluestore-tool** show-label --dev *device* ...
 | **ceph-bluestore-tool** show-label-at --dev *device* --offset *lba* ...
 | **ceph-bluestore-tool** prime-osd-dir --dev *device* --path *osd path*
@@ -72,6 +73,9 @@ Commands
 
    Reverses changes done by the new NCB code (either through ceph restart or when running allocmap command) and restores RocksDB B Column-Family (allocator-map).
 
+:command:`recovery-compare`
+
+   Runs legacy onode recovery and multithread onode recovery. Prints timings and compares results.
 
 :command:`bluefs-export`
 

doc/man/8/ceph.rst

@@ -632,11 +632,11 @@ rules and failure handling on all pools. For a given PG to successfully peer
 and be marked active, ``min_size`` replicas will now need to be active under all
 (currently two) CRUSH buckets of type <dividing_bucket>.
 
-<tiebreaker_mon> is the tiebreaker mon to use if a network split happens.
+<tiebreaker_mon> is the tiebreaker Monitor to use if a network split happens.
 This parameter is optional. If not supplied, the system will automatically
-select a monitor that is not in either data zone. If there are multiple
-monitors outside the data zones, automatic selection will fail and you must
-explicitly specify the tiebreaker monitor.
+select a Monitor that is not in either data zone. If there are multiple
+Monitors outside the data zones, automatic selection will fail and you must
+explicitly specify the tiebreaker Monitor.
 
 <dividing_bucket> is the bucket type across which to stretch.
 This will typically be ``datacenter`` or other CRUSH hierarchy bucket type that
@@ -1196,7 +1196,8 @@ Subcommand ``get`` gets pool parameter <var>.
 
 Usage::
 
-    ceph osd pool get <poolname> size|min_size|pg_num|pgp_num|crush_rule|write_fadvise_dontneed
+    ceph osd pool get <poolname> size|min_size|pg_num|pgp_num|crush_rule|hashpspool|
+    nodelete|nopgchange|nosizechange|write_fadvise_dontneed
 
 Only for tiered pools::
 
@@ -1249,7 +1250,7 @@ Usage::
 
     ceph osd pool set <poolname> size|min_size|pg_num|
     pgp_num|crush_rule|hashpspool|nodelete|nopgchange|nosizechange|
-    hit_set_type|hit_set_period|hit_set_count|hit_set_fpp|debug_fake_ec_pool|
+    hit_set_type|hit_set_period|hit_set_count|hit_set_fpp|
     target_max_bytes|target_max_objects|cache_target_dirty_ratio|
     cache_target_dirty_high_ratio|
     cache_target_full_ratio|cache_min_flush_age|cache_min_evict_age|

doc/man/8/cephadm.rst

@@ -13,8 +13,8 @@ Synopsis
 |             [--log-dir LOG_DIR] [--logrotate-dir LOGROTATE_DIR]
 |             [--unit-dir UNIT_DIR] [--verbose] [--timeout TIMEOUT]
 |             [--retry RETRY] [--no-container-init]
-|             {version,pull,inspect-image,ls,list-networks,list-rdma,adopt,rm-daemon,rm-cluster,run,shell,enter,ceph-volume,unit,logs,bootstrap,deploy,check-host,prepare-host,add-repo,rm-repo,install,list-images,update-osd-service}
-|             ...
+|             {version,pull,inspect-image,ls,list-networks,list-rdma,adopt,rm-daemon,rm-cluster,remove-file,deploy-file,run,shell,enter,ceph-volume,unit,logs,bootstrap,deploy,check-host,prepare-host,prepare-host-sudo-hardening,setup-ssh-user,add-repo,rm-repo,install,list-images,update-osd-service}
+|               ...
 
 
 | **cephadm** **pull**
@@ -90,8 +90,19 @@ Synopsis
 
 | **cephadm** **check-host** [-h] [--expect-hostname EXPECT_HOSTNAME]
 
+| **cephadm** **remove-file** [-h] [--fsid FSID] --path PATH
+
+| **cephadm** **deploy-file** [-h] [--fsid FSID] --path PATH [--mode MODE]
+|                          [--uid UID] [--gid GID]
+
 | **cephadm** **prepare-host**
 
+| **cephadm** **prepare-host-sudo-hardening** [-h] [--ssh-user SSH_USER]
+|                                          [--ssh-pub-key SSH_PUB_KEY]
+|                                          [--cephadm-version VERSION]
+
+| **cephadm** **setup-ssh-user** [-h] --ssh-user SSH_USER --ssh-pub-key SSH_PUB_KEY
+
 | **cephadm** **add-repo** [-h] [--release RELEASE] [--version VERSION]
 |                          [--dev DEV] [--dev-commit DEV_COMMIT]
 |                          [--gpg-url GPG_URL] [--repo-url REPO_URL]
@@ -289,6 +300,32 @@ Arguments:
 * [--expect-hostname EXPECT_HOSTNAME] Check that hostname matches an expected value
 
 
+remove-file
+-----------
+
+Remove a regular file on the local host. Missing paths are ignored.
+
+Arguments:
+
+* [--fsid FSID]   cluster FSID
+* --path PATH     absolute path of the file to remove (required)
+
+
+deploy-file
+-----------
+
+Write or replace a file on the local host. The **entire file body** is read from
+**standard input** as raw bytes (no encoding or line-ending translation).
+
+Arguments:
+
+* [--fsid FSID]   cluster FSID
+* --path PATH     absolute destination path for the file (required)
+* [--mode MODE]   octal file mode (for example ``644`` or ``0644``)
+* [--uid UID]    numeric owner user id (**must** be given together with ``--gid``)
+* [--gid GID]    numeric owner group id (**must** be given together with ``--uid``)
+
+
 deploy
 ------
 
@@ -420,6 +457,49 @@ Arguments:
 * [--expect-hostname EXPECT_HOSTNAME] Set hostname
 
 
+prepare-host-sudo-hardening
+---------------------------
+
+Prepare a host for sudo hardening by authorizing SSH keys, installing/upgrading
+the cephadm package, and setting up restricted sudoers permissions::
+
+    cephadm prepare-host-sudo-hardening --ssh-user cephadm --ssh-pub-key <key>
+
+This command performs the following steps:
+
+1. Authorizes the provided SSH public key for the specified user
+2. Installs or upgrades the cephadm package to match the cluster version (includes cephadm_invoker.py)
+3. Sets up sudoers with restricted permissions for cephadm_invoker.py
+
+Arguments:
+
+* [--ssh-user SSH_USER]       SSH user for key authorization (default: root)
+* [--ssh-pub-key SSH_PUB_KEY] SSH public key to authorize
+* [--cephadm-version VERSION] Specific cephadm version to install
+
+
+setup-ssh-user
+--------------
+
+Setup SSH user with passwordless sudo and SSH key authorization::
+
+    cephadm setup-ssh-user --ssh-user cephadm --ssh-pub-key <public_key>
+
+This command configures an SSH user for cephadm operations by:
+
+1. Validating that the user exists on the system
+2. Setting up passwordless sudo for the user (skipped for root)
+3. Authorizing the SSH public key for the user
+
+This command is automatically called by ``ceph cephadm set-user`` to configure
+SSH users across all cluster hosts.
+
+Arguments:
+
+* [--ssh-user SSH_USER]       SSH user to setup (required)
+* [--ssh-pub-key SSH_PUB_KEY] SSH public key to add to user's authorized_keys (required)
+
+
 pull
 ----
 

doc/man/8/crushtool.rst

@@ -151,15 +151,35 @@ pools; it only runs simulations by mapping values in the range
    Displays how many attempts were needed to find a device mapping.
    For instance::
 
-      0:     95224
-      1:      3745
-      2:      2225
+      tries 0:     95224
+      tries 1:      3745
+      tries 2:      2225
       ..
 
    shows that **95224** mappings succeeded without retries, **3745**
    mappings succeeded with one attempts, etc. There are as many rows
    as the value of the **--set-choose-total-tries** option.
 
+.. option:: --show-retry-exhaustion
+
+   Checks whether any PG mappings hit the maximum retry limit
+   (typically 50 tries) and displays a warning if retry exhaustion
+   is detected. This is useful for validating CRUSH rules, especially
+   in stretch cluster configurations with exactly
+   2 datacenters and 4 replicas can potentially fail to map some PGs due to CRUSH's
+   pseudorandom selection repeatedly choosing the same datacenter.
+   Although, the probability is extremely low, we still want to detect this.
+   
+   Outputs either a warning message if exhaustion is detected::
+
+      WARNING: Retry exhaustion detected!
+        5 PG(s) hit the maximum retry limit of 50
+        This indicates CRUSH failed to find optimal placement for some PGs.
+
+   or a success message showing the maximum tries actually needed::
+
+      No retry exhaustion detected (maximum tries needed: 7 / 50)
+
 .. option:: --output-csv
 
    Creates CSV files (in the current directory) containing information

doc/man/8/radosgw-admin.rst

@@ -639,7 +639,7 @@ Options
 
 .. option:: --shard-id=<shard-id>
 
-   Optional for mdlog list, bi list, data sync status. Required for ``mdlog trim``.
+   Optional for mdlog list, bi list, data sync status, gc list, gc process. Required for ``mdlog trim``.
 
 .. option:: --max-entries=<entries>
 

doc/man/8/rgw-policy-test.rst

@@ -0,0 +1,65 @@
+:orphan:
+
+===================================================
+rgw-policy-test -- test evaluation of bucket policy
+===================================================
+
+.. program:: rgw-policy-test
+
+Synopsis
+========
+
+| **rgw-policy-test**
+   [-e *key*=*value*]... [-t *tenant*] [-R resource] [-I identity] *action* *filename* 
+
+
+Description
+===========
+
+This utility reads a policy from a file or stdin and evaluates it
+against the supplied identity, resource, action, and request context
+(the key/value pairs evaluated by conditions.) The utility will print
+a trace of evaluating the policy and the effect of its evaluation.
+
+On error it will print a message and return non-zero.
+
+Options
+=======
+
+.. option:: -t *tenant*, --tenant *tenant*
+
+   Specify *tenant* as the tenant. If not provided, the default
+   (empty) tenant is used.
+
+.. option:: -e *key*=*value*, --environment *key*=*value*
+
+   Add (*key*, *value*) to the environment for evaluation. May be
+   specified multiple times.
+
+.. option:: -I *SCHEMA:STRING*, --identity *SCHEMA:STRING*
+
+   Specify *identity* as the identity whose access is to be checked.
+
+.. option:: -R *ARN*, --resource *ARN*
+
+   Specify *ARN* as the resource for which to check access.
+
+.. option:: *action*
+
+   Use *action* as the action to check.
+
+.. option:: *filename*
+
+   Read the policy from *filename*, or - for standard input.
+
+Availability
+============
+
+**rgw-policy-test** is part of Ceph, a massively scalable, open-source,
+distributed storage system.  Please refer to the Ceph documentation at
+https://docs.ceph.com/ for more information.
+
+See also
+========
+
+:doc:`radosgw <radosgw>`\(8)

doc/man_index.rst

@@ -48,4 +48,5 @@
    man/8/ceph-immutable-object-cache
    man/8/ceph-diff-sorted
    man/8/rgw-policy-check
+   man/8/rgw-policy-test
    man/8/rgw-restore-bucket-index

doc/mgr/administrator.rst

@@ -161,9 +161,9 @@ The Manager automatically adjusts :confval:`mgr_stats_period` based on message q
 depth to prevent overload during high cluster activity. This feature is enabled by
 default and can be controlled with the following settings:
 
-- :confval:`mgr_stats_period_autotune` (boolean, default: true): Enable or disable
+- :confval:`mgr_stats_period_autotune` : Enable or disable
   automatic tuning of the stats period.
-- :confval:`mgr_stats_period_autotune_queue_threshold` (integer, default: 100):
+- :confval:`mgr_stats_period_autotune_queue_threshold` :
   The message queue depth threshold that triggers an increase in the stats period.
 
 When the queue depth exceeds this threshold, the stats period is increased to

doc/mgr/ceph_secrets.rst

@@ -0,0 +1,434 @@
+.. _mgr-ceph-secrets:
+
+===================
+Ceph Secrets Module
+===================
+
+The ``ceph_secrets`` manager module provides centralised secret storage for
+Ceph operators and Ceph manager modules.  Instead of embedding plaintext
+credentials in service specifications or configuration objects, secrets are
+stored once and referenced by URI.  Ceph manager modules such as cephadm
+and rook can store secret payloads centrally, reference them by URI, and
+resolve them to plaintext only when needed at deploy time.
+
+For example, a cephadm-managed service may need an API token.  Instead of
+embedding that token directly in the service specification, an operator can
+store it once:
+
+.. prompt:: bash $
+
+   ceph secret set cephadm/service/my-service/api_token -i /tmp/api-token
+
+and then use the URI
+``secret:/cephadm/service/my-service/api_token`` in the
+service spec instead of the plaintext token.  A cephadm integration can then
+resolve the URI at deploy time and write the token only into the daemon files
+that need it.
+
+Secrets are stored in the Monitor KV store under the ``secret_store/v1/`` prefix
+and are organised by namespace, scope, and name.  Each secret is versioned and
+carries ``created``/``updated`` timestamps.  A per-namespace epoch counter
+is incremented on every ``set`` and on any ``rm`` that actually removes a
+secret, allowing consumers to detect changes without fetching the full secret
+list.
+
+.. note::
+
+   The ``mon`` backend stores secrets in the Monitor KV store, which is not an
+   external KMS or vault.  Users and MGR modules with sufficient Ceph
+   permissions can still reveal or resolve stored secret values.  Namespaces
+   provide logical and storage isolation, not an authorisation boundary.
+
+If the module is not already enabled, run::
+
+    ceph mgr module enable ceph_secrets
+
+.. contents::
+   :local:
+   :depth: 2
+
+
+Concepts
+========
+
+Namespace
+---------
+
+A namespace is a logical storage boundary, typically matching the name of
+the consuming MGR module (e.g. ``cephadm``, ``rook``).  Secrets in different
+namespaces are stored independently and have independent epoch counters.
+Namespaces are not an authorisation boundary; any caller with access to the
+``ceph_secrets`` module can read secrets from any namespace.
+
+Scope
+-----
+
+Within a namespace, every secret has a scope that encodes what the secret
+belongs to:
+
+.. list-table::
+   :header-rows: 1
+   :widths: 15 40 45
+
+   * - Scope
+     - Meaning
+     - CLI path form
+   * - ``global``
+     - Cluster-wide secret, not tied to any specific target
+     - ``<namespace>/global/<name>``
+   * - ``service``
+     - Secret for a specific named service
+     - ``<namespace>/service/<service-name>/<name>``
+   * - ``host``
+     - Secret for a specific host
+     - ``<namespace>/host/<hostname>/<name>``
+   * - ``custom``
+     - Arbitrary slash-delimited path under the namespace
+     - ``<namespace>/custom/<path>``
+
+Path grammar
+------------
+
+All path segments (namespace, scope target, name, and each segment of a
+custom path) must match ``[A-Za-z0-9._-]+`` and must not end with ``'.'``.
+Empty segments, percent-encoding, and leading/trailing whitespace are
+rejected.
+
+Custom scope paths may contain multiple slash-separated segments (e.g.
+``cephadm/custom/app/db/password``).  Two custom paths that share a common
+prefix are independent secrets; ``cephadm/custom/a/b`` and
+``cephadm/custom/a/b/c`` do not conflict.
+
+Secret URIs
+-----------
+
+Internally, secrets are identified by URIs of the form::
+
+    secret:/<namespace>/global/<name>
+    secret:/<namespace>/service/<target>/<name>
+    secret:/<namespace>/host/<target>/<name>
+    secret:/<namespace>/custom/<path>
+
+These URIs appear in the output of :ref:`scan_refs <mgr-ceph-secrets-scan>`
+and may be embedded in configuration objects as opaque references to be
+resolved at deploy time.
+
+
+CLI Reference
+=============
+
+All CLI commands use the path form described above.  Responses are JSON by
+default; pass ``--format yaml`` for YAML output.
+
+.. _mgr-ceph-secrets-set:
+
+secret set
+----------
+
+Create or update a secret. The input file content is stored as an opaque string::
+
+    ceph secret set <path> -i <file>
+
+Secret data must not be empty.  Other contents, including leading or trailing
+whitespace and final newlines, are preserved exactly.  Callers that need to
+store structured data should encode it themselves, for example as JSON, and
+decode it after retrieval or resolution.
+
+If the secret already exists its data is replaced and its version
+incremented, unless the existing secret policy marks it non-editable (set via
+the Python API with ``editable=False``), in which case the update is rejected.
+The ``created`` timestamp is set on the first write and is never changed
+thereafter; ``updated`` is refreshed on every write.
+
+Example:
+
+.. prompt:: bash $
+
+   ceph secret set cephadm/service/my-service/api_token -i /tmp/api-token
+   {"metadata": {"version": 1, "created": "2025-06-01T12:00:00Z", "updated": "2025-06-01T12:00:00Z"}}
+
+.. _mgr-ceph-secrets-get:
+
+secret get
+----------
+
+Retrieve the metadata (and, optionally, the data) for a secret::
+
+    ceph secret get <path> [--reveal] [--format {json|yaml}]
+
+Without ``--reveal``, the ``data`` field is omitted from the response to
+avoid accidental exposure in terminal output or logs.  With ``--reveal``,
+``data`` contains the stored opaque string.
+
+Example:
+
+.. prompt:: bash $
+
+   ceph secret get cephadm/service/my-service/api_token
+   {
+     "metadata": {
+       "version": 1,
+       "created": "2025-06-01T12:00:00Z",
+       "updated": "2025-06-01T12:00:00Z"
+     }
+   }
+
+   ceph secret get cephadm/service/my-service/api_token --reveal
+   {
+     "metadata": {
+       "version": 1,
+       "created": "2025-06-01T12:00:00Z",
+       "updated": "2025-06-01T12:00:00Z"
+     },
+     "data": "api-token-value"
+   }
+
+.. _mgr-ceph-secrets-get-value:
+
+secret get-value
+----------------
+
+Return the raw secret data string directly, with no JSON envelope::
+
+    ceph secret get-value <path>
+
+Unlike ``secret get --reveal``, the output is the stored string itself,
+making it suitable for use in shell scripts and pipelines.  Returns an
+error if the secret does not exist.
+
+Example:
+
+.. prompt:: bash $
+
+   ceph secret get-value cephadm/service/my-service/api_token
+   api-token-value
+
+.. _mgr-ceph-secrets-ls:
+
+secret ls
+---------
+
+List secrets, optionally filtered by namespace, scope, and/or target::
+
+    ceph secret ls [--namespace <ns>] [--scope <scope>]
+                   [--sec_target <target>] [--reveal] [--show_internals]
+                   [--format {json|yaml}]
+
+Without filters, all secrets across all namespaces are listed.
+``--reveal`` includes the stored opaque data string in each output record.
+``--show_internals`` additionally includes the ``policy`` object (``user_made``
+and ``editable`` flags) in each record.
+
+Example:
+
+.. prompt:: bash $
+
+   ceph secret ls --namespace cephadm --scope host --sec_target node1
+   {
+     "cephadm/host/node1/ssh_key": {
+       "metadata": {
+         "version": 3,
+         "created": "2025-05-10T08:00:00Z",
+         "updated": "2025-06-01T09:00:00Z"
+       },
+       "ref": {
+         "namespace": "cephadm",
+         "scope": "host",
+         "target": "node1",
+         "name": "ssh_key"
+       }
+     }
+   }
+
+.. _mgr-ceph-secrets-rm:
+
+secret rm
+---------
+
+Remove a secret::
+
+    ceph secret rm <path>
+
+The operation is idempotent: removing a secret that does not exist succeeds
+and reports ``"status": "not_found"`` rather than an error.
+
+Example:
+
+.. prompt:: bash $
+
+   ceph secret rm cephadm/service/my-service/api_token
+   {"status": "removed"}
+
+   ceph secret rm cephadm/service/my-service/api_token
+   {"status": "not_found"}
+
+.. _mgr-ceph-secrets-get-epoch:
+
+Epoch
+-----
+
+The epoch for a namespace is accessible via the Python API only (see
+:ref:`Epoch-based change detection <mgr-ceph-secrets-epoch>`).  There is
+no CLI command for it.
+
+
+Module API
+==========
+
+Other MGR modules should consume ``ceph_secrets`` via ``CephSecretsClient``
+(``src/pybind/mgr/ceph_secrets_client.py``) rather than calling
+``mgr.remote()`` directly.  The client file, along with
+``ceph_secrets_types.py``, lives at the top level of ``src/pybind/mgr/`` so
+any MGR module can import it without depending on the ``ceph_secrets`` package
+internals.
+
+.. code-block:: python
+
+    from ceph_secrets_client import CephSecretsClient
+    from ceph_secrets_types import SecretScope
+
+    client = CephSecretsClient(self)   # self is a MgrModule instance
+
+    # Store a secret as an opaque string
+    client.secret_set(
+        namespace="cephadm",
+        scope=SecretScope.HOST,
+        target="node1",
+        name="ssh_key",
+        data="AQB...==",
+    )
+
+    # Retrieve metadata (no data unless reveal=True)
+    rec = client.secret_get("cephadm", SecretScope.HOST, "node1", "ssh_key")
+    if rec:
+        version = rec["metadata"]["version"]
+
+    # Remove
+    client.secret_rm("cephadm", SecretScope.HOST, "node1", "ssh_key")
+
+CephSecretsClient methods
+--------------------------
+
+.. list-table::
+   :header-rows: 1
+   :widths: 35 65
+
+   * - Method
+     - Description
+   * - ``secret_set(namespace, scope, target, name, data, ...)``
+     - Create or update a secret.  ``data`` must be a non-empty opaque
+       string.  Increments the version and refreshes ``updated`` on each
+       call; ``created`` is set only on the first write.  Optional
+       ``user_made`` and ``editable`` flags control the stored policy;
+       ``editable=False`` blocks future updates but does not prevent removal.
+   * - ``secret_get(namespace, scope, target, name, reveal=False)``
+     - Return the secret's metadata dict, plus the opaque ``data`` string if
+       *reveal* is True.  Returns ``None`` if the secret does not exist.
+   * - ``secret_get_value(namespace, scope, target, name)``
+     - Return the stored opaque string directly, or ``None`` if the secret
+       does not exist.  Use this when only the value is needed and the
+       metadata envelope is not required.
+   * - ``secret_get_version(namespace, scope, target, name)``
+     - Return the current version integer, or ``None`` if not found.  A
+       cheaper alternative to ``secret_get`` when only change-detection is needed.
+   * - ``secret_get_versions(uris)``
+     - Batch-fetch version numbers for a list of canonical ``secret:/...``
+       URIs.  Returns a dict keyed by URI; missing secrets map to ``None``.
+       Malformed URIs are skipped entirely, so a missing key indicates
+       malformed input rather than an absent secret.
+   * - ``secret_rm(namespace, scope, target, name)``
+     - Remove a secret.  Idempotent: returns ``False`` if not found.
+   * - ``secret_get_epoch(namespace)``
+     - Return the current epoch for the namespace.  Use as a cheap
+       change-detector before a full refresh.
+   * - ``scan_refs(obj, namespace)``
+     - Walk a JSON-like object and return secret-like reference strings found
+       within it.  This includes valid whole-value secret URIs and malformed
+       or embedded secret-like references that should be reported to the
+       caller.  Only canonical ``secret:/...`` URIs should be passed to
+       ``secret_get_versions``.
+   * - ``scan_unresolved_refs(obj, namespace)``
+     - Like ``scan_refs`` but returns only references that are missing,
+       malformed, embedded inside a larger string, or cannot currently be
+       read successfully.  Useful for pre-flight validation.
+   * - ``resolve_object(obj)``
+     - Walk a JSON-like object and replace every whole-value ``secret:/...``
+       URI string with the stored opaque string for the referenced secret.
+
+.. _mgr-ceph-secrets-scan:
+
+Secret URI embedding and resolution
+-----------------------------------
+
+Configuration objects that need to reference secrets without embedding
+plaintext can store ``secret:/...`` URIs as string values.  The module
+resolves them on demand:
+
+.. code-block:: python
+
+    spec = {
+        "service_type": "my-service",
+        "spec": {
+            "api_token": " secret:/cephadm/service/my-service/api_token ",
+        },
+    }
+
+    # Check for missing, malformed, embedded, or unresolvable secret references
+    unresolved = client.scan_unresolved_refs(spec, namespace="cephadm")
+    if unresolved:
+        raise RuntimeError(f"Unresolved secret references: {unresolved}")
+
+    # Replace URI references with plaintext values
+    resolved = client.resolve_object(spec)
+    # resolved["spec"]["api_token"] now holds the stored API token
+
+.. note::
+
+   Resolution replaces the entire string value of a field.  Surrounding
+   whitespace around a URI reference is ignored, so values such as
+   ``" secret:/cephadm/global/foo "`` are accepted.  Embedding a secret URI
+   inside a larger string (for example ``"Bearer secret:/..."``) is not
+   supported; after trimming surrounding whitespace, the field value must be
+   the URI.
+
+   The resolved value is the stored opaque string.  The module does not parse
+   stored data as JSON and does not support field-level URI selection.  If a
+   caller stores structured data, it must encode and decode that structure
+   itself.
+
+.. _mgr-ceph-secrets-epoch:
+
+Epoch-based change detection
+----------------------------
+
+Consumers that maintain a local cache of secrets can use the epoch to avoid
+unnecessary full refreshes:
+
+.. code-block:: python
+
+    def maybe_refresh(client, namespace, last_epoch):
+        current_epoch = client.secret_get_epoch(namespace)
+        if current_epoch == last_epoch:
+            return last_epoch   # nothing changed
+        # ... do a full refresh ...
+        return current_epoch
+
+    last_epoch = 0
+    last_epoch = maybe_refresh(client, "cephadm", last_epoch)
+
+The epoch is incremented by every successful ``set`` operation and by
+``rm`` only when an existing secret is actually removed (an idempotent
+``rm`` returning ``"not_found"`` does not bump the epoch).  It starts at 0
+for a namespace that has never been written to, and mutations in one namespace
+never affect another namespace's epoch.
+
+
+Configuration
+=============
+
+.. mgr_module:: ceph_secrets
+.. confval:: secrets_backend
+
+   The storage backend used for secrets.  Currently only the Monitor KV store
+   (``mon``) is supported.  This option is reserved for future backends
+   (e.g. HashiCorp Vault).

doc/mgr/dashboard.rst

@@ -1176,7 +1176,8 @@ The list of system roles are:
 - **cluster-manager**: allows full permissions for the *hosts*, *osd*,
   *monitor*, *manager*, and *config-opt* scopes.
 - **pool-manager**: allows full permissions for the *pool* scope.
-- **cephfs-manager**: allows full permissions for the *cephfs* scope.
+- **cephfs-manager**: allows full permissions for the *cephfs* scope, and
+  *read* permission for the *hosts* and *pool* scopes.
 
 The list of available roles can be retrieved with the following command:
 

doc/mgr/index.rst

@@ -47,5 +47,6 @@ sensible.
     MDS Autoscaler module <mds_autoscaler>
     NFS module <nfs>
     SMB module <smb>
+    Secrets module <ceph_secrets>
     Progress Module <progress>
     CLI API Commands module <cli_api>

doc/mgr/nfs.rst

@@ -31,7 +31,7 @@ Create NFS Ganesha Cluster
 
 .. prompt:: bash #
 
-   ceph nfs cluster create <cluster_id> [<placement>] [--ingress] [--virtual_ip <value>] [--ingress-mode {default|keepalive-only|haproxy-standard|haproxy-protocol}] [--port <int>] [--enable-rdma] [--rdma_port <int>] [-i <spec_file>]
+   ceph nfs cluster create <cluster_id> [<placement>] [--ingress] [--virtual_ip <value>] [--ingress-mode {default|keepalive-only|haproxy-standard|haproxy-protocol}] [--ingress-placement <placement>] [--port <int>] [--enable-rdma] [--rdma_port <int>] [--enable-nfsv3] [-i <spec_file>]
 
 This creates a common recovery pool for all NFS Ganesha daemons, new user based on
 ``cluster_id``, and a common NFS Ganesha config RADOS object.
@@ -62,6 +62,9 @@ cluster)::
 
 NFS can be deployed on a port other than 2049 (the default) with ``--port <port>``.
 
+By default, only NFS v4 protocol is enabled. To enable both NFS v3 and v4 protocols,
+add the ``--enable-nfsv3`` flag.
+
 To deploy NFS with a high-availability front-end (virtual IP and load balancer), add the
 ``--ingress`` flag and specify a virtual IP address. This will deploy a combination
 of keepalived and haproxy to provide an high-availability NFS frontend for the NFS
@@ -108,6 +111,18 @@ of the details of NFS redirecting traffic on the virtual IP to the
 appropriate backend NFS servers, and redeploying NFS servers when they
 fail.
 
+By default, the *ingress* service follows the same placement as the NFS
+Ganesha daemons (the optional ``<placement>`` argument).  To schedule
+keepalived and HAProxy on a different set of hosts, pass
+``--ingress-placement`` with a separate placement string.  For example,
+to run three NFS daemons on ``host1`` and ``host2`` while colocating
+ingress on three dedicated nodes::
+
+    ceph nfs cluster create mynfs "2 host1 host2" --ingress --virtual_ip 192.168.1.100/24 --ingress-placement "3 host3 host4 host5"
+
+If ``--ingress-placement`` is omitted, both services share the NFS
+placement.
+
 An optional ``--ingress-mode`` parameter can be provided to choose
 how the *ingress* service is configured:
 
@@ -277,6 +292,275 @@ This removes the user defined configuration.
    for the new config blocks to be effective.
 
 
+Cluster QoS management
+======================
+
+NFS Ganesha supports cluster-wide and per-export Quality of Service (QoS) for
+bandwidth and IOPS (operations per second).
+
+.. note:: Cluster-level QoS changes take effect after the NFS service is
+   restarted. The ``ceph nfs cluster qos enable`` and ``ceph nfs cluster qos
+   disable`` commands (for both bandwidth control and IOPS control), as well as
+   ``ceph nfs cluster qos set``, restart all NFS Ganesha daemons in the
+   cluster automatically via ``ceph orch restart nfs.<cluster_id>``. Plan for
+   a brief service interruption when running these commands on a live cluster.
+
+``qos_type`` values
+-------------------
+
+All ``qos enable`` commands require a ``qos_type`` argument. Valid values are:
+
+* ``PerShare`` — limits apply per NFS export (share).
+* ``PerClient`` — limits apply per NFS client.
+* ``PerShare_PerClient`` — limits apply per export and per client.
+
+Parameter constraints
+---------------------
+
+Bandwidth parameters (``max_*_bw``) accept human-readable values with the
+following units: ``KiB``, ``MiB``, ``GiB``, ``KB``, ``MB`` and ``GB``
+(for example, ``100MB`` or ``128KiB``). The valid range is
+128 KiB/s to 100 GiB/s.
+
+IOPS parameters (``max_*_iops``) must be integers in the range 10 to 1638400.
+
+The cluster QoS message interval (``cqos_msg_interval``) can be set with
+``ceph nfs cluster qos set``. The valid range is 100 to 300 milliseconds.
+
+Deploy-time QoS via service spec
+--------------------------------
+
+When deploying an NFS cluster with cephadm, cluster-level QoS can be configured
+at creation time using the ``cluster_qos_config`` field in the NFS service
+spec, or via a command of the form ceph nfs cluster create -i foo.yml with a YAML input file.
+
+``cluster_qos_config`` is a dictionary. At least one of
+``enable_bw_control`` or ``enable_iops_control`` must be ``true``. Supported
+keys:
+
+* ``enable_qos`` (bool, default ``true``)
+* ``qos_type`` (required when QoS is enabled): ``PerShare``, ``PerClient``, or
+  ``PerShare_PerClient``
+* ``enable_bw_control`` (bool)
+* ``combined_rw_bw_control`` (bool)
+* ``enable_iops_control`` (bool)
+* ``max_export_write_bw``, ``max_export_read_bw``, ``max_client_write_bw``,
+  ``max_client_read_bw`` (string bandwidth values)
+* ``max_export_combined_bw``, ``max_client_combined_bw`` (string bandwidth
+  values)
+* ``max_export_iops``, ``max_client_iops`` (integer)
+* ``cqos_msg_interval`` (integer, 100–300 milliseconds)
+
+The NFS service spec also accepts ``cluster_qos_port`` (default ``31311``) to specify
+the cluster QoS messaging port used by Ganesha daemons.
+
+Example service spec with cluster QoS:
+
+.. code-block:: yaml
+
+    service_type: nfs
+    service_id: mynfs
+    placement:
+      hosts:
+        - host1
+    spec:
+      port: 2049
+      cluster_qos_port: 31311
+      cluster_qos_config:
+        qos_type: PerShare
+        enable_bw_control: true
+        combined_rw_bw_control: false
+        max_export_write_bw: 100MB
+        max_export_read_bw: 100MB
+
+Example ``ceph nfs cluster create`` input file:
+
+.. code-block:: yaml
+
+    cluster_qos_config:
+      qos_type: PerShare
+      enable_bw_control: true
+      max_export_write_bw: 100MB
+      max_export_read_bw: 100MB
+
+.. code:: bash
+
+    $ ceph nfs cluster create mynfs "host1" -i cluster_qos.yaml
+
+
+Enable QoS bandwidth control for an NFS Ganesha cluster
+-------------------------------------------------------
+
+.. code:: bash
+
+    $ ceph nfs cluster qos enable bandwidth_control <cluster_id> <qos_type:PerShare|PerClient|PerShare_PerClient> [--combined-rw-bw-ctrl] [--max_export_write_bw <value>] [--max_export_read_bw <value>] [--max_client_write_bw <value>] [--max_client_read_bw <value>] [--max_export_combined_bw <value>] [--max_client_combined_bw <value>]
+
+This command enables or updates Quality of Service (QoS) bandwidth control for
+an NFS Ganesha cluster, where
+
+``<cluster_id>`` is the NFS Ganesha cluster ID.
+
+``<qos_type>`` is the type of bandwidth control: ``PerShare``, ``PerClient``, or
+``PerShare_PerClient``.
+
+If ``PerShare`` ``qos_type`` is selected, then the cluster-level QoS config is
+applicable to all exports on that NFS Ganesha cluster. It requires
+``max_export_write_bw`` and ``max_export_read_bw`` parameters if
+``--combined-rw-bw-ctrl`` is not set, otherwise ``max_export_combined_bw`` is
+required.
+
+If ``PerClient`` ``qos_type`` is selected, then the cluster-level QoS config is
+applicable to all clients accessing exports on that cluster. It requires
+``max_client_write_bw`` and ``max_client_read_bw`` parameters if
+``--combined-rw-bw-ctrl`` is not set, otherwise ``max_client_combined_bw`` is
+required.
+
+If ``PerShare_PerClient`` ``qos_type`` is selected, then the cluster-level
+config applies to all exports and all clients on that NFS Ganesha cluster.
+It requires ``max_export_write_bw``, ``max_export_read_bw``,
+``max_client_write_bw``, and ``max_client_read_bw`` parameters if
+``--combined-rw-bw-ctrl`` is not set, otherwise ``max_export_combined_bw`` and
+``max_client_combined_bw`` are required.
+
+``--combined-rw-bw-ctrl`` enables combined read and write bandwidth. When set,
+only the combined bandwidth parameters allowed for the selected ``qos_type``
+may be specified.
+
+``--max_export_write_bw`` is the maximum write bandwidth for each export.
+
+``--max_export_read_bw`` is the maximum read bandwidth for each export.
+
+``--max_client_write_bw`` is the maximum write bandwidth for each client.
+
+``--max_client_read_bw`` is the maximum read bandwidth for each client.
+
+``--max_export_combined_bw`` is the maximum combined read/write bandwidth for each export.
+
+``--max_client_combined_bw`` is the maximum combined read/write bandwidth for each client.
+
+The bandwidth value can be specified using any supported bandwidth unit: bytes/s,
+KB/s, KiB/s, MB/s, MiB/s, GB/s, or GiB/s.
+
+For example::
+
+    $ ceph nfs cluster qos enable bandwidth_control nfs_clust PerShare --max_export_write_bw 100MB --max_export_read_bw 100MB
+
+.. note:: If this command is used to update ``qos_type``, update all exports
+   with the required parameters as well.
+
+By default, exports inherit the cluster-level QoS setting when no
+``QOS_BLOCK`` is present in the export block.
+
+Disable QoS bandwidth control for NFS Ganesha cluster
+-----------------------------------------------------
+
+.. code:: bash
+
+    $ ceph nfs cluster qos disable bandwidth_control <cluster_id>
+
+This command disables bandwidth control QoS at the cluster level. If
+cluster-level bandwidth control is disabled, export-level bandwidth control
+has no effect even when enabled on an export.
+
+For example::
+
+    $ ceph nfs cluster qos disable bandwidth_control nfs_clust
+
+Enable QoS IOPS control for NFS Ganesha cluster
+-----------------------------------------------
+
+.. code:: bash
+
+   $ ceph nfs cluster qos enable ops_control <cluster_id> <qos_type:PerShare|PerClient|PerShare_PerClient> [--max_export_iops <int>] [--max_client_iops <int>]
+
+This command enables or updates IOPS control for an NFS cluster.
+
+``<cluster_id>`` is the NFS Ganesha cluster ID.
+
+``<qos_type>`` is the type of ops control: ``PerShare``, ``PerClient``, or
+``PerShare_PerClient``.
+
+If ``PerShare`` ``qos_type`` is selected, the cluster-level QoS config applies
+to all exports on that NFS Ganesha cluster and requires ``--max_export_iops``.
+
+If ``PerClient`` ``qos_type`` is selected, the cluster-level QoS config
+applies to all clients accessing exports on that cluster and requires
+``--max_client_iops``.
+
+If ``PerShare_PerClient`` ``qos_type`` is selected, the cluster-level config
+applies to all exports and all clients on that NFS Ganesha cluster and
+requires both ``--max_export_iops`` and ``--max_client_iops``.
+
+``--max_export_iops`` is the IOPS limit per export.
+
+``--max_client_iops`` is the IOPS limit per client.
+
+For example::
+
+    $ ceph nfs cluster qos enable ops_control nfs_clust PerShare --max_export_iops 1000
+
+.. note:: If this command is used to update ``qos_type``, update all exports
+   with the required parameters as well.
+
+Disable QoS IOPS control for NFS Ganesha cluster
+------------------------------------------------
+
+.. code:: bash
+
+   $ ceph nfs cluster qos disable ops_control <cluster_id>
+
+This command disables IOPS control for an NFS Ganesha cluster. After disabling
+ops control at the cluster level, export-level IOPS control has no effect even
+when enabled on an export.
+
+For example::
+
+    $ ceph nfs cluster qos disable ops_control nfs_clust
+
+Set cluster QoS message interval
+--------------------------------
+
+.. code:: bash
+
+   $ ceph nfs cluster qos set <cluster_id> <msg_interval>
+
+This command sets ``cqos_msg_interval``, the message interval (in
+milliseconds) used for cluster QoS synchronization among NFS Ganesha hosts.
+The valid range is 100 to 300. Cluster-level QoS must already be configured
+(using ``enable bandwidth_control`` or ``enable ops_control``) before this
+command can be used.
+
+For example::
+
+    $ ceph nfs cluster qos set nfs_clust 200
+
+Get QoS configuration for NFS Ganesha cluster
+---------------------------------------------
+
+.. code:: bash
+
+   $ ceph nfs cluster qos get <cluster_id>
+
+This command displays the cluster-level QoS configuration. Use ``ceph -f
+json`` (or ``json-pretty``, ``yaml``, etc.) to control output formatting.
+
+For example::
+
+    $ ceph nfs cluster qos get nfs_clust
+     {
+       "combined_rw_bw_control": false,
+       "enable_bw_control": true,
+       "enable_iops_control": true,
+       "enable_qos": true,
+       "max_export_iops": 1000,
+       "max_export_read_bw": "100.0MB",
+       "max_export_write_bw": "100.0MB",
+       "qos_type": "PerShare"
+     }
+
+When ``cqos_msg_interval`` has been set, it also appears in the output.
+
+
 Export Management
 =================
 
@@ -475,6 +759,147 @@ This displays export block for a cluster based on pseudo root name, where:
 
 ``<pseudo_path>`` is the pseudo root path (must be an absolute path).
 
+Enable QoS bandwidth control for a specific export
+--------------------------------------------------
+
+.. code:: bash
+
+    $ ceph nfs export qos enable bandwidth_control <cluster_id> <pseudo_path> [--combined-rw-bw-ctrl] [--max_export_write_bw <value>] [--max_export_read_bw <value>] [--max_client_write_bw <value>] [--max_client_read_bw <value>] [--max_export_combined_bw <value>] [--max_client_combined_bw <value>] [--skip-notify-nfs-server]
+
+This command enables or updates QoS bandwidth control for an export. Enable
+cluster-level bandwidth control with ``qos_type`` ``PerShare`` or
+``PerShare_PerClient`` before enabling export-level bandwidth control. This
+creates a ``QOS_BLOCK`` in the export block, where
+
+``<cluster_id>`` is the NFS Ganesha cluster ID.
+
+``<pseudo_path>`` is the pseudo-root path (must be an absolute path).
+
+``--combined-rw-bw-ctrl`` enables combined read and write bandwidth. When set,
+only the combined bandwidth parameters allowed for the cluster ``qos_type`` may
+be specified.
+
+``--max_export_write_bw`` is the maximum write bandwidth for each export.
+
+``--max_export_read_bw`` is the maximum read bandwidth for each export.
+
+``--max_client_write_bw`` is the maximum write bandwidth for each client.
+
+``--max_client_read_bw`` is the maximum read bandwidth for each client.
+
+``--max_export_combined_bw`` is the maximum combined read/write bandwidth for each export.
+
+``--max_client_combined_bw`` is the maximum combined read/write bandwidth for each client.
+
+``--skip-notify-nfs-server`` skips notifying running NFS Ganesha daemons after
+the change (useful for batch updates).
+
+The bandwidth value can be specified using any supported bandwidth unit: bytes/s,
+KB/s, KiB/s, MB/s, MiB/s, GB/s, or GiB/s.
+
+For example::
+
+   $ ceph nfs export qos enable bandwidth_control nfs_clust /export1 --combined-rw-bw-ctrl --max_export_combined_bw 200MB
+
+.. note:: Export-level bandwidth control cannot be enabled if the cluster-level
+   ``qos_type`` is ``PerClient``.
+
+Disable QoS bandwidth control for a specific export
+---------------------------------------------------
+
+.. code:: bash
+
+   $ ceph nfs export qos disable bandwidth_control <cluster_id> <pseudo_path> [--skip-notify-nfs-server]
+
+This disables export-level bandwidth control. After disabling, the export no
+longer has export-specific bandwidth limits. If the export has no
+``QOS_BLOCK``, it inherits cluster-level bandwidth control again.
+
+For example::
+
+   $ ceph nfs export qos disable bandwidth_control nfs_clust /export1
+
+.. note:: To restore cluster-level QoS defaults for an export, use
+   ``ceph nfs export apply <cluster_id>`` with an export definition that does
+   not include a ``QOS_BLOCK``.
+
+Enable QoS IOPS control for a specific export
+---------------------------------------------
+
+.. code:: bash
+
+   $ ceph nfs export qos enable ops_control <cluster_id> <pseudo_path> [--max_export_iops <int>] [--max_client_iops <int>] [--skip-notify-nfs-server]
+
+This enables IOPS control for a specified export. The same command can be used
+to update an existing IOPS limit. Enable cluster-level IOPS control with ``qos_type``
+``PerShare`` or ``PerShare_PerClient`` before enabling export-level IOPS control.
+
+``<cluster_id>`` is the NFS Ganesha cluster ID.
+
+``<pseudo_path>`` is the pseudo-root path (must be an absolute path).
+
+``--max_export_iops`` is the IOPS limit for the export.
+
+``--max_client_iops`` is the IOPS limit per client of the export.
+
+``--skip-notify-nfs-server`` skips notifying running NFS Ganesha daemons after
+the change.
+
+For example::
+
+   $ ceph nfs export qos enable ops_control nfs_clust /export1 --max_export_iops 2000
+
+.. note:: Export-level IOPS control cannot be enabled if the cluster-level
+   ``qos_type`` is ``PerClient``.
+
+Disable QoS IOPS control for a specific export
+----------------------------------------------
+
+.. code:: bash
+
+   $ ceph nfs export qos disable ops_control <cluster_id> <pseudo_path> [--skip-notify-nfs-server]
+
+This command disables export-level IOPS control. After disabling, the export no
+longer has export-specific IOPS limits.
+
+For example::
+
+   $ ceph nfs export qos disable ops_control nfs_clust /export1
+
+Get QoS configuration for export
+--------------------------------
+
+.. code:: bash
+
+    $ ceph nfs export qos get <cluster_id> <pseudo_path>
+
+This command displays the export-level QoS configuration. Use ``ceph -f
+json`` (or ``json-pretty``, ``yaml``, ``xml``, ``xml-pretty``) to control output formatting.
+When cluster-level QoS is configured, fields prefixed with ``global_`` show
+the cluster defaults (``global_enable_qos``, ``global_enable_bw_control``,
+``global_enable_iops_control``). Export-specific fields (without the
+``global_`` prefix) are present only when a ``QOS_BLOCK`` exists on the
+export. If the export has no ``QOS_BLOCK``, an empty object ``{}`` is
+returned.
+
+For example::
+
+   $ ceph nfs export qos get nfs_clust /export1
+     {
+       "global_enable_bw_control": true,
+       "global_enable_iops_control": true,
+       "global_enable_qos": true,
+       "combined_rw_bw_control": true,
+       "enable_bw_control": true,
+       "enable_iops_control": true,
+       "enable_qos": true,
+       "max_export_combined_bw": "200.0MB",
+       "max_export_iops": 2000
+     }
+
+Export QoS can also be set via ``ceph nfs export apply`` by including a
+``qos_block`` key in the export JSON, or a ``QOS_BLOCK`` section in a Ganesha
+EXPORT config fragment.
 
 Create or update export via JSON specification
 ----------------------------------------------

doc/mgr/orchestrator.rst

@@ -113,10 +113,19 @@ Creating/growing/shrinking/removing services:
    ceph orch apply mds <fs_name> [--placement=<placement>] [--dry-run]
    ceph orch apply rgw <name> [--realm=<realm>] [--zone=<zone>] [--port=<port>] [--ssl] [--placement=<placement>] [--dry-run]
    ceph orch apply nfs <name> <pool> [--namespace=<namespace>] [--placement=<placement>] [--dry-run]
-   ceph orch rm <service_name> [--force]
+   ceph orch rm <service_name> [--force] [--force-delete-data]
 
 where ``placement`` is a :ref:`orchestrator-cli-placement-spec`.
 
+For ``ceph orch rm``, ``--force`` may be required in some cases (for example when
+removing an OSD service that would leave OSDs behind).
+
+The ``--force-delete-data`` flag requires that ``--force`` is also passed.
+This directs cephadm to delete on-disk data for certain daemon types instead
+of moving it to ``<fsid>/removed/`` on the host. These daemon types include
+``mon``, ``osd``, and ``prometheus``. This helps avoid filling up the
+underlying filesystem over time.
+
 e.g., ``ceph orch apply mds myfs --placement="3 host1 host2 host3"``
 
 Service Commands:

doc/mgr/prometheus.rst

@@ -24,6 +24,19 @@ Enable the ``prometheus`` module by running the below command :
 
    ceph mgr module enable prometheus
 
+ceph-exporter
+=============
+
+``ceph-exporter`` works alongside the Prometheus manager module. The two
+components have distinct responsibilities:
+
+- The **Prometheus manager module** exposes all cluster-level metrics by
+  default other than Ceph daemon performance counters. However, these metrics
+  may be exported by the Prometheus manager module by setting the module option
+  :confval:`mgr/prometheus/exclude_perf_counter` to `false`.
+- The **ceph-exporter daemon** exposes only Ceph daemon performance counters
+  as Prometheus metrics, running on each host in the cluster.
+
 Configuration
 -------------
 

doc/mgr/smb.rst

@@ -55,7 +55,7 @@ Create Cluster
 
 .. prompt:: bash #
 
-   ceph smb cluster create <cluster_id> {user|active-directory} [--domain-realm=<domain_realm>] [--domain-join-user-pass=<domain_join_user_pass>] [--define-user-pass=<define_user_pass>] [--custom-dns=<custom_dns>] [--placement=<placement>] [--clustering=<clustering>] [--password-filter=<password_filter>] [--password-filter-out=<password_filter_out>]
+   ceph smb cluster create <cluster_id> {user|active-directory} [--domain-realm=<domain_realm>] [--domain-join-user-pass=<domain_join_user_pass>] [--define-user-pass=<define_user_pass>] [--custom-dns=<custom_dns>] [--placement=<placement>] [--clustering=<clustering>] [--client-compat={default|macos}] [--password-filter=<password_filter>] [--password-filter-out=<password_filter_out>]
 
 Create a new logical cluster, identified by the cluster ID value. The cluster
 create command must specify the authentication mode the cluster will use. This
@@ -100,6 +100,11 @@ clustering
     enables clustering regardless of the placement count. A value of ``never``
     disables clustering regardless of the placement count. If unspecified,
     ``default`` is assumed.
+client_compat
+    Optional. One of ``default`` or ``macos``. Controls client-specific SMB
+    features and optimizations. The ``default`` mode provides standard SMB
+    behavior with broad compatibility. The ``macos`` mode enables macOS-specific
+    optimized settings for macOS clients. If unspecified, ``default`` is assumed.
 public_addrs
     Optional. A string in the form of <ipaddress/prefixlength>[%<destination address>].
     Supported only when using Samba's clustering. Assign "virtual" IP addresses
@@ -165,6 +170,15 @@ previous example. Set three CTDB public address values and a custom placement:
         --public-address=192.168.76.112/24 \
         --placement="3 label:smb"
 
+Create a cluster for macOS clients with user authentication:
+
+.. prompt:: bash #
+
+    ceph smb cluster create mac_cluster user \
+        --define-user-pass=macuser%Passw0rd1 \
+        --client-compat=macos \
+        --placement="label:smb"
+
 
 Update Cluster QoS
 ++++++++++++++++++
@@ -216,6 +230,53 @@ Disable QoS for all shares in a cluster:
      --write-bw-limit=0
 
 
+
+Update Cluster Client Compatibility
+++++++++++++++++++++++++++++++++++++
+
+.. prompt:: bash #
+
+   ceph smb cluster update client-compat {default|macos} <cluster_id>
+
+Update the client compatibility mode for an SMB cluster. This setting controls whether client-specific SMB features and optimizations are enabled.
+
+The client compatibility mode determines how the Samba server is configured to optimize for specific client types:
+
+- ``default``: Standard SMB behavior without client-specific optimizations. This is the default mode and provides broad compatibility with all SMB clients.
+- ``macos``: Enable macOS-specific features including the Samba's fruit VFS module for proper handling of macOS metadata and optimized settings for macOS clients.
+
+When ``macos`` mode is enabled, the following features are automatically configured:
+
+- Fruit VFS module for proper handling of macOS-specific file attributes
+- Streams_xattr VFS module for extended attribute support
+
+Options:
+
+client_compat
+    One of ``default`` or ``macos``
+cluster_id
+    A short string uniquely identifying the cluster
+
+Examples
+~~~~~~~~
+
+Enable macOS compatibility mode for a cluster:
+
+.. prompt:: bash #
+
+   ceph smb cluster update client-compat macos mycluster
+
+Revert to default (standard) compatibility mode:
+
+.. prompt:: bash #
+
+   ceph smb cluster update client-compat default mycluster
+
+.. note::
+   The ``macos`` compatibility mode is recommended when the primary clients accessing the SMB shares are macOS systems. Otherwise default mode is recommended.
+
+
+
 Remove Cluster
 ++++++++++++++
 
@@ -321,6 +382,51 @@ Create a read-only share at a custom path in the CephFS volume:
         --path=/qbranch/top/secret/plans --readonly
 
 
+Create RGW Share
+++++++++++++++++
+
+.. prompt:: bash #
+
+   ceph smb share create rgw <cluster_id> <share_id> <bucket> [--share-name=<share_name>] [--user-id=<user_id>] [--readonly]
+
+Create a new SMB share, hosted by the named cluster, that maps to a RADOS
+Gateway (RGW) bucket. This allows S3-compatible object storage to be accessed
+via the SMB protocol.
+
+Options:
+
+cluster_id
+    A short string uniquely identifying the cluster
+share_id
+    A short string uniquely identifying the share
+bucket
+    The name of the RGW bucket to be shared
+share_name
+    Optional. The public name of the share, visible to clients. If not provided
+    the ``share_id`` will be used automatically
+user_id
+    Optional. The RGW user ID that owns the bucket. If not provided, the system
+    will attempt to determine the bucket owner automatically
+readonly
+    Creates a read-only share
+
+Examples
+~~~~~~~~
+
+Create a share for an RGW bucket:
+
+.. prompt:: bash #
+
+    ceph smb share create rgw test1 photos my-photos-bucket
+
+Create a share with a custom name and specific user:
+
+.. prompt:: bash #
+
+    ceph smb share create rgw test1 photos my-photos-bucket \
+        --share-name="Photo Archive" --user-id=s3user
+
+
 .. _qos-parameters:
 
 QoS Parameters
@@ -879,6 +985,12 @@ custom_smb_global_options
     indicator that the user is aware that using this option can easily break
     things in ways that the Ceph team can not help with. This special key will
     automatically be removed from the list of options passed to Samba.
+client_compat
+    Optional. One of ``default`` or ``macos``. Controls client-specific SMB
+    features and optimizations. The ``default`` mode provides standard SMB
+    behavior with broad compatibility. The ``macos`` mode enables macOS-specific
+    features including Samba's fruit VFS module for proper handling of macOS and
+    optimized settings for macOS clients. If unspecified, ``default`` is assumed.
 
 .. warning::
    Setting the ``clustering`` option allows an administrator to choose exactly
@@ -977,6 +1089,20 @@ The following is an example of a cluster configured for standalone operation:
       hosts:
         - node6.mycluster.sink.test
 
+The following is an example of a cluster optimized for macOS clients:
+
+.. code-block:: yaml
+
+    resource_type: ceph.smb.cluster
+    cluster_id: macshare
+    auth_mode: user
+    client_compat: macos
+    user_group_settings:
+      - source_type: resource
+        ref: ug1
+    placement:
+      count: 1
+
 An example cluster resource with intent to remove:
 
 .. code-block:: yaml
@@ -1018,7 +1144,8 @@ max_connections
     connections to a specific share. The default value is 0 and it indicates
     that there is no limit on the number of connections
 cephfs
-    Required object. Fields:
+    Object. Configures CephFS-backed storage for the share. Either a ``cephfs``
+    or ``rgw`` object must be specified, but not both. Fields:
 
     volume
         Required string. Name of the cephfs volume to use
@@ -1088,6 +1215,22 @@ cephfs
         name
             String. A value indicating what FSCrypt key to fetch. The specific
             value of the name depends on the scope being used.
+rgw
+    Object. Configures RADOS Gateway (RGW) backed storage for the share. Either
+    a ``cephfs`` or ``rgw`` object must be specified, but not both. This allows
+    S3-compatible object storage to be accessed via the SMB protocol. Fields:
+
+    bucket
+        Required string. The name of the RGW bucket to be shared.
+    user_id
+        Optional string. The RGW user ID that owns the bucket. If not provided,
+        the system will automatically determine the bucket owner and fetch the
+        necessary credentials.
+    credential_ref
+        Optional string. The ``rgw_credential_id`` value of a
+        ``ceph.smb.rgw.credential`` resource that contains RGW access and
+        secret key values needed to use the given bucket.
+
 restrict_access
     Optional boolean, defaulting to false. If true the share will only permit
     access by users explicitly listed in ``login_control``.
@@ -1135,7 +1278,32 @@ custom_smb_share_options
     things in ways that the Ceph team can not help with. This special key will
     automatically be removed from the list of options passed to Samba.
 
-The following is an example of a share with QoS settings including burst
+The following is an example of an RGW-backed share with minimal configuration
+(credentials auto-fetched):
+
+.. code-block:: yaml
+
+    resource_type: ceph.smb.share
+    cluster_id: tango
+    share_id: s3share
+    name: "S3 Storage"
+    rgw:
+      bucket: my-bucket
+
+Another example of an RGW-backed share with explicit user_id:
+
+.. code-block:: yaml
+
+    resource_type: ceph.smb.share
+    cluster_id: tango
+    share_id: s3share
+    name: "S3 Storage"
+    rgw:
+      bucket: my-bucket
+      user_id: s3user
+
+
+The following is an example of a CephFS share with QoS settings including burst
 multipliers and human-readable bandwidth limits:
 
 .. code-block:: yaml
@@ -1285,6 +1453,43 @@ Example:
         groups: []
 
 
+RGW Credential Resource
+------------------------
+
+An RGW credential resource stores RADOS Gateway (RGW) access credentials that can be used by RGW-backed shares to authenticate with the object storage system.
+
+A RGW credential resource supports the following fields:
+
+resource_type
+    A literal string ``ceph.smb.rgw.credential``
+rgw_credential_id
+    A short string identifying the RGW credential resource.
+intent
+    One of ``present`` or ``removed``. If not provided, ``present`` is assumed.
+    If ``removed`` all following fields are optional
+user_id
+    Required string. The RGW user ID that owns the credentials
+access_key_id
+    Required string. The RGW access key for authentication
+secret_access_key
+    Required string. The RGW secret key for authentication
+linked_to_cluster:
+    Optional. A string containing a cluster ID. If set, the resource may only
+    be used with the linked cluster and will automatically be removed when the
+    linked cluster is removed.
+
+
+Example:
+
+.. code-block:: yaml
+
+    resource_type: ceph.smb.rgw.credential
+    rgw_credential_id: s3user 
+    user_id: s3user
+    access_key: AKIAIOSFODNN7EXAMPLE
+    secret_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
+
+
 TLS Credential Resource
 ------------------------
 
@@ -1362,14 +1567,122 @@ fsid
 mon_host
     String. The ``mon_host`` string (as sourced from a ceph.conf file)
 cephfs_user
-    Object. Fields:
+    Optional object. Required if the cluster will host CephFS-backed shares.
+    Fields:
 
     name
-        String. A ceph user name indicating the cephx user that will
+        String. A Ceph user name indicating the CephX user that will
         access the CephFS volume(s) on the external cluster
     key
-        String. The Base64 encoded key value corresponding to the cephx
+        String. The Base64 encoded key value corresponding to the CephX
         user name provided
+rgw_user
+    Optional object. Required if the cluster will host RGW-backed shares.
+    Fields:
+
+    name
+        String. A Ceph user name indicating the CephX user that will
+        access the RGW bucket(s) on the external cluster
+    key
+        String. The Base64 encoded key value corresponding to the CephX
+        user name provided
+
+.. note::
+   At least one of ``cephfs_user`` or ``rgw_user`` must be configured.
+   Configure only the user(s) needed for your share types:
+
+   - CephFS-only clusters: Configure only ``cephfs_user``
+   - RGW-only clusters: Configure only ``rgw_user``
+   - Mixed clusters: Configure both ``cephfs_user`` and ``rgw_user``
+
+Examples
+~~~~~~~~
+
+External cluster with CephFS support only:
+
+.. code-block:: yaml
+
+    resource_type: ceph.smb.ext.cluster
+    external_ceph_cluster_id: external-cephfs
+    cluster:
+      fsid: "12345678-1234-1234-1234-123456789abc"
+      mon_host: "10.0.1.10:6789,10.0.1.11:6789"
+      cephfs_user:
+        name: "client.external-cephfs"
+        key: "AQC1234567890abcdefghijklmnopqrstuvwxyz=="
+
+External cluster with RGW support only:
+
+.. code-block:: yaml
+
+    resource_type: ceph.smb.ext.cluster
+    external_ceph_cluster_id: external-rgw
+    cluster:
+      fsid: "12345678-1234-1234-1234-123456789abc"
+      mon_host: "10.0.1.10:6789,10.0.1.11:6789"
+      rgw_user:
+        name: "client.external-rgw"
+        key: "AQD9876543210zyxwvutsrqponmlkjihgfedcba=="
+
+External cluster with both CephFS and RGW support:
+
+.. code-block:: yaml
+
+    resource_type: ceph.smb.ext.cluster
+    external_ceph_cluster_id: external-mixed
+    cluster:
+      fsid: "12345678-1234-1234-1234-123456789abc"
+      mon_host: "10.0.1.10:6789,10.0.1.11:6789"
+      cephfs_user:
+        name: "client.external-cephfs"
+        key: "AQC1234567890abcdefghijklmnopqrstuvwxyz=="
+      rgw_user:
+        name: "client.external-rgw"
+        key: "AQD9876543210zyxwvutsrqponmlkjihgfedcba=="
+
+
+.. important::
+   **RGW Shares on External Clusters Require Manual Credentials**
+
+   When creating RGW shares on external clusters, you **must** manually define
+   RGW credentials using the ``ceph.smb.rgw.credential`` resource. Unlike local
+   clusters where credentials can be auto-fetched, external clusters cannot
+   automatically retrieve S3 access keys.
+
+   Example configuration with manual RGW credentials:
+
+   .. code-block:: yaml
+
+       resources:
+         # Define the external cluster with rgw_user
+         - resource_type: ceph.smb.ext.cluster
+           external_ceph_cluster_id: external-rgw
+           cluster:
+             fsid: "12345678-1234-1234-1234-123456789abc"
+             mon_host: "10.0.1.10:6789,10.0.1.11:6789"
+             rgw_user:
+               name: "client.external-rgw"
+               key: "AQD9876543210zyxwvutsrqponmlkjihgfedcba=="
+
+         # Define RGW credentials manually (REQUIRED for external clusters)
+         - resource_type: ceph.smb.rgw.credential
+           rgw_credential_id: my-s3-creds
+           user_id: s3-user
+           access_key_id: AKIAIOSFODNN7EXAMPLE
+           secret_access_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
+
+         # RGW share referencing the manual credentials
+         - resource_type: ceph.smb.share
+           cluster_id: my-cluster
+           share_id: s3-share
+           name: "S3 Share"
+           rgw:
+             bucket: my-bucket
+             credential_ref: my-s3-creds
+
+   The ``rgw_user`` in the external cluster definition provides the CephX
+   credentials for accessing the RGW service, while the ``ceph.smb.rgw.credential``
+   resource provides the S3 access key and secret key for bucket operations.
 
 
 A Declarative Configuration Example
@@ -1483,10 +1796,11 @@ cluster has been configured for at least one share. The ``placement`` field of
 the cluster resource is passed onto the orchestration layer and is used to
 determine on what nodes of the Ceph cluster Samba containers will be run.
 
-At this time Samba services can only listen on port 445. Due to this
-restriction only one Samba server, as part of one cluster, may run on a single
-Ceph node at a time. Ensure that the placement specs on each cluster do not
-overlap.
+The Samba containers may run on the same hosts if, and only if, the services
+use different IP addresses and/or ports. If the placement spec allows more than
+one container to run on the same host, use the ``bind_addrs`` field, the
+``custom_ports`` field, or some combination, in the cluster resource to ensure
+that the Samba server instances do not conflict.
 
 The ``smb`` clusters are fully isolated from each other. This means that, as
 long as you have sufficient resources in your Ceph cluster, you can run multiple