From 19ee803038a035ad933d93d00076aeead527f689 Mon Sep 17 00:00:00 2001 From: Patrick McFadin Date: Wed, 10 Jun 2026 10:59:01 -0700 Subject: [PATCH] CASSANDRA-21342: Long-tail xref follow-up (cassandra-4.0 subset) Subset of the trunk long-tail xref follow-up (commit cc97ee5332) applicable to cassandra-4.0. Three files have broken patterns that still apply on this branch after PR #4807's forward-merge: the architecture index, finding_nodes, and use_tools self-page xrefs. Six edits total. Mechanical retargets only; no prose was rewritten. Edits omitted (trunk-only): * Twenty files introduced in 5.0 or later (developing/cql/, reference/ cql-commands/, managing/operating/, etc). * use_tools.adoc edits 4 and 5 (different line state on 4.x; packet-capture anchor section structure differs). patch by Patrick McFadin; reviewed by Mick Semb Wever for CASSANDRA-21342 --- doc/modules/cassandra/pages/architecture/index.adoc | 2 +- .../cassandra/pages/troubleshooting/finding_nodes.adoc | 4 ++-- doc/modules/cassandra/pages/troubleshooting/use_tools.adoc | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/modules/cassandra/pages/architecture/index.adoc b/doc/modules/cassandra/pages/architecture/index.adoc index c4bef05cfd..30f4ee7e4f 100644 --- a/doc/modules/cassandra/pages/architecture/index.adoc +++ b/doc/modules/cassandra/pages/architecture/index.adoc @@ -6,4 +6,4 @@ This section describes the general architecture of Apache Cassandra. * xref:architecture/dynamo.adoc[Dynamo] * xref:architecture/storage_engine.adoc[Storage Engine] * xref:architecture/guarantees.adoc[Guarantees] -* xref:architecture/snitch.adoc[Snitches] +* xref:cassandra:managing/operating/snitch.adoc[Snitches] diff --git a/doc/modules/cassandra/pages/troubleshooting/finding_nodes.adoc b/doc/modules/cassandra/pages/troubleshooting/finding_nodes.adoc index 522bbb92af..f1b3ab810e 100644 --- a/doc/modules/cassandra/pages/troubleshooting/finding_nodes.adoc +++ b/doc/modules/cassandra/pages/troubleshooting/finding_nodes.adoc @@ -128,6 +128,6 @@ exhaust significant CPU capacitity with a "single" query. Once you have narrowed down the problem as much as possible (datacenter, rack , node), login to one of the nodes using SSH and proceed to debug -using xref:reading_logs.adoc[`logs`], xref:use_nodetooladoc[`nodetool`], and -xref:use_tools.adoc[`os tools`]. +using xref:cassandra:troubleshooting/reading_logs.adoc[`logs`], xref:cassandra:troubleshooting/use_nodetool.adoc[`nodetool`], and +xref:cassandra:troubleshooting/use_tools.adoc[`os tools`]. If you are not able to login you may still have access to `logs` and `nodetool` remotely. diff --git a/doc/modules/cassandra/pages/troubleshooting/use_tools.adoc b/doc/modules/cassandra/pages/troubleshooting/use_tools.adoc index b9ec42acd3..b3f5b6fb02 100644 --- a/doc/modules/cassandra/pages/troubleshooting/use_tools.adoc +++ b/doc/modules/cassandra/pages/troubleshooting/use_tools.adoc @@ -208,7 +208,7 @@ when it syncs the commit log. This typically enters into the very high percentiles of write latency. Note that to get detailed latency breakdowns you will need a more -advanced tool such as xref:use_tools.adoc#bcc-tools[`bcc-tools`]. +advanced tool such as xref:cassandra:troubleshooting/use_tools.adoc#use-bcc-tools[`bcc-tools`]. === OS page Cache Usage @@ -232,8 +232,8 @@ Cassandra performance can suffer significantly. This is why Cassandra starts with a reasonably small amount of memory reserved for the heap. If you suspect that you are missing the OS page cache frequently you can -use advanced tools like xref:use_tools.adoc#use-bcc-tools[cachestat] or -xref:use_tools.adoc#use-vmtouch[vmtouch] to dive deeper. +use advanced tools like xref:cassandra:troubleshooting/use_tools.adoc#use-bcc-tools[cachestat] or +xref:cassandra:troubleshooting/use_tools.adoc#use-vmtouch[vmtouch] to dive deeper. === Network Latency and Reliability