Skip to content

Commit ddcc38c

Browse files
authored
More read-only-allow-delete docs (#45320)
Adds to the `index.blocks.read_only_allow_delete` docs the information that this block may be added or removed automatically, and rewords the breaking-changes docs to mention the blocks explicitly and to recommend using a different block. Relates #42559
1 parent 9f62c04 commit ddcc38c

File tree

3 files changed

+18
-15
lines changed

3 files changed

+18
-15
lines changed

docs/reference/index-modules.asciidoc

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -166,8 +166,10 @@ specific index module:
166166
allow writes and metadata changes.
167167

168168
`index.blocks.read_only_allow_delete`::
169-
Identical to `index.blocks.read_only` but allows deleting the index to free
170-
up resources.
169+
170+
Similar to `index.blocks.read_only` but also allows deleting the index to
171+
free up resources. The <<disk-allocator,disk-based shard allocator>> may
172+
add and remove this block automatically.
171173

172174
`index.blocks.read`::
173175

docs/reference/migration/migrate_7_4.asciidoc

Lines changed: 14 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -99,14 +99,17 @@ wait for the rerouting process to completely finish you should add the
9999
[float]
100100
==== Auto-release of read-only-allow-delete block
101101

102-
If a node exceeds the flood-stage disk watermark then we add a block to all of
103-
its indices to prevent further writes as a last-ditch attempt to prevent the
104-
node completely exhausting its disk space. In earlier versions this block would
105-
remain in place until manually removed, causing confusion for users who
106-
currently have ample disk space and are not aware that they nearly ran out at
107-
some point in the past. From 7.4 onwards the block is automatically removed
108-
when a node drops below the high watermark again, with the expectation that the
109-
high watermark is some distance below the flood-stage watermark and therefore
110-
the disk space problem is truly resolved. This behaviour can be disabled by
111-
setting the system property `es.disk.auto_release_flood_stage_block` to
112-
`false`.
102+
If a node exceeds the flood-stage disk watermark then {es} adds the
103+
`index.blocks.read_only_allow_delete` block to all of its indices to prevent
104+
further writes, as a last-resort attempt to prevent the node completely
105+
exhausting its disk space. In earlier versions this block would remain in place
106+
until manually removed, causing confusion for users who currently have ample
107+
disk space and who are not aware that they nearly ran out at some point in the
108+
past. From 7.4 onwards the block is automatically removed when the node drops
109+
below the high watermark again, with the expectation that the high watermark is
110+
some distance below the flood-stage watermark and therefore the disk space
111+
problem is truly resolved. Since this block may be automatically removed, you
112+
can no longer rely on adding this block manually to prevent writes to an index.
113+
You should use the `index.blocks.read_only` block instead. This behaviour can
114+
be disabled by setting the system property
115+
`es.disk.auto_release_flood_stage_block` to `false`.

docs/reference/modules/cluster/disk_allocator.asciidoc

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -42,8 +42,6 @@ shards allocated on the node that has at least one disk exceeding the flood
4242
stage. This is a last resort to prevent nodes from running out of disk space.
4343
The index block is automatically released once the disk utilization falls below
4444
the high watermark.
45-
The automatic release can however be disabled in 7.x through a system property
46-
`es.disk.auto_release_flood_stage_block`
4745

4846
NOTE: You can not mix the usage of percentage values and byte values within
4947
these settings. Either all are set to percentage values, or all are set to byte

0 commit comments

Comments
 (0)