mirror of
https://github.com/minio/docs.git
synced 2025-07-28 19:42:10 +03:00
DOCS-911: Improving erasure coding core concepts (#929)
Closes #911 --------- Co-authored-by: Daryl White <53910321+djwfyi@users.noreply.github.com> Co-authored-by: Andrea Longo <feorlen@users.noreply.github.com>
This commit is contained in:
Ravind Kumar
GitHub
@ -209,6 +209,10 @@ Glossary
|
||||
|
||||
See also: :term:`JBOD`.
|
||||
|
||||
read quorum
|
||||
The minimum number of object shards necessary to reconstruct the full object for read operations.
|
||||
See :ref `minio-ec-basics` for more information.
|
||||
|
||||
replication
|
||||
mirror
|
||||
The replication of a :ref:`bucket <minio-bucket-replication>` or entire :ref:`site <minio-site-replication-overview>` to another location.
|
||||
@ -233,7 +237,10 @@ Glossary
|
||||
For more detailed logging information, see :term:`audit logs`.
|
||||
|
||||
server pool
|
||||
pool
|
||||
A set of ``minio server`` nodes which combine their drives and resources to support object storage and retrieval requests.
|
||||
|
||||
For more information, see :ref:`minio-intro-server-pool`.
|
||||
|
||||
service account
|
||||
Renamed to :term:`access keys`.
|
||||
@ -303,6 +310,10 @@ Glossary
|
||||
A :ref:`webhook <minio-bucket-notifications-publish-webhook>` is a method for altering the behavior of a web page or web application with a custom callback.
|
||||
The format is typically :abbr:`JSON (JavaScript Object Notation)` sent as an HTTP POST request.
|
||||
|
||||
write quorum
|
||||
The minimum number of object shards MinIO must successfully write to an :ref:`erasure set <minio-ec-erasure-set>` for write operations.
|
||||
See :ref:`minio-ec-basics` for more information
|
||||
|
||||
WORM
|
||||
Write Once Read Many (WORM) is a data retention methodology that functions as part of object locking.
|
||||
Many requests can retrieve can view a WORM-locked object (``read many``), but no write requests can change the object (``write once``).
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
Before Width: | Height: | Size: 129 KiB After Width: | Height: | Size: 195 KiB |
@ -19,15 +19,15 @@
|
||||
inkscape:pagecheckerboard="0"
|
||||
inkscape:deskcolor="#505050"
|
||||
showgrid="false"
|
||||
inkscape:zoom="3.9314988"
|
||||
inkscape:cx="316.29159"
|
||||
inkscape:cy="102.37826"
|
||||
inkscape:zoom="5.6568542"
|
||||
inkscape:cx="346.39394"
|
||||
inkscape:cy="160.7784"
|
||||
inkscape:window-width="3840"
|
||||
inkscape:window-height="2123"
|
||||
inkscape:window-x="3840"
|
||||
inkscape:window-x="0"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="a" />
|
||||
inkscape:current-layer="g8506" />
|
||||
<defs
|
||||
id="defs8048">
|
||||
<style
|
||||
@ -1104,43 +1104,6 @@
|
||||
id="path15302" />
|
||||
</g>
|
||||
</g>
|
||||
<g
|
||||
id="g8506">
|
||||
<path
|
||||
id="rect8498"
|
||||
class="i"
|
||||
style="fill:none;stroke:#cf2144;stroke-miterlimit:10"
|
||||
d="m 499.63,264.44 h 104.98001 v 39.33 H 499.63 Z" />
|
||||
<g
|
||||
aria-label="NODE ..."
|
||||
transform="translate(532.38 287.91)"
|
||||
id="text8504"
|
||||
class="x"
|
||||
style="font-weight:700;font-size:10px;font-family:Inter-Bold, Inter;font-variation-settings:'slnt' 0, 'wght' 700">
|
||||
<path
|
||||
d="M 7.23,0 H 5.31 L 2.2,-5.4 H 2.16 q 0.02,0.51 0.04,1.02 0.03,0.51 0.05,1.02 V 0 H 0.9 v -7.14 h 1.91 l 3.1,5.35 H 5.94 Q 5.93,-2.29 5.91,-2.78 5.89,-3.27 5.87,-3.76 v -3.38 h 1.36 z"
|
||||
id="path15278" />
|
||||
<path
|
||||
d="m 15.509997,-3.58 q 0,1.11 -0.37,1.94 -0.36,0.82 -1.11,1.28 -0.75,0.46 -1.92,0.46 -1.16,0 -1.92,-0.46 -0.7499997,-0.46 -1.1199997,-1.29 -0.36,-0.83 -0.36,-1.94 0,-1.11 0.36,-1.93 0.37,-0.82 1.1199997,-1.27 0.76,-0.46 1.93,-0.46 1.16,0 1.91,0.46 0.75,0.45 1.11,1.28 0.37,0.82 0.37,1.93 z m -5.21,0 q 0,1.12 0.43,1.77 0.43,0.64 1.38,0.64 0.97,0 1.39,-0.64 0.42,-0.65 0.42,-1.77 0,-1.13 -0.42,-1.77 -0.42,-0.64 -1.38,-0.64 -0.96,0 -1.39,0.64 -0.43,0.64 -0.43,1.77 z"
|
||||
id="path15280" />
|
||||
<path
|
||||
d="m 22.909993,-3.64 q 0,1.81 -1.03,2.73 -1.02,0.91 -2.87,0.91 h -2.02 v -7.14 h 2.24 q 1.12,0 1.94,0.4 0.83,0.4 1.28,1.18 0.46,0.77 0.46,1.92 z m -1.57,0.04 q 0,-1.19 -0.52,-1.74 -0.52,-0.56 -1.51,-0.56 h -0.81 v 4.65 h 0.65 q 2.19,0 2.19,-2.35 z"
|
||||
id="path15282" />
|
||||
<path
|
||||
d="m 28.49999,0 h -4.11 v -7.14 h 4.11 v 1.24 h -2.6 v 1.57 h 2.42 v 1.24 h -2.42 v 1.84 h 2.6 z"
|
||||
id="path15284" />
|
||||
<path
|
||||
d="m 32.259987,-0.7 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
id="path15286" />
|
||||
<path
|
||||
d="m 35.109986,-0.7 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
id="path15288" />
|
||||
<path
|
||||
d="m 37.41,-0.7 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
style="letter-spacing:-0.03em"
|
||||
id="path15290" />
|
||||
</g>
|
||||
</g>
|
||||
<path
|
||||
id="rect8508"
|
||||
class="t"
|
||||
@ -1164,10 +1127,6 @@
|
||||
class="m"
|
||||
d="M487.73,232.19v-10.72h2.27v8.85h4.6v1.87h-6.86Z"
|
||||
id="path8516" />
|
||||
<path
|
||||
class="m"
|
||||
d="M504.12,221.48v10.72h-2.27v-8.57h-.06l-2.46,1.54v-2.01l2.65-1.68h2.13Z"
|
||||
id="path8518" />
|
||||
</g>
|
||||
<g
|
||||
id="g8552">
|
||||
@ -1658,6 +1617,55 @@
|
||||
</g>
|
||||
<g
|
||||
id="g8776">
|
||||
<g
|
||||
id="g8506">
|
||||
<path
|
||||
id="rect8498"
|
||||
class="i"
|
||||
style="fill:none;stroke:#cf2144;stroke-miterlimit:10"
|
||||
d="m 499.63,264.44 h 104.98001 v 39.33 H 499.63 Z" />
|
||||
<g
|
||||
aria-label="NODE ..."
|
||||
transform="translate(532.38 287.91)"
|
||||
id="text8504"
|
||||
class="x"
|
||||
style="font-weight:700;font-size:10px;font-family:Inter-Bold, Inter;font-variation-settings:'slnt' 0, 'wght' 700">
|
||||
<path
|
||||
d="M 7.23,0 H 5.31 L 2.2,-5.4 H 2.16 q 0.02,0.51 0.04,1.02 0.03,0.51 0.05,1.02 V 0 H 0.9 v -7.14 h 1.91 l 3.1,5.35 H 5.94 Q 5.93,-2.29 5.91,-2.78 5.89,-3.27 5.87,-3.76 v -3.38 h 1.36 z"
|
||||
id="path15278" />
|
||||
<path
|
||||
d="m 15.509997,-3.58 q 0,1.11 -0.37,1.94 -0.36,0.82 -1.11,1.28 -0.75,0.46 -1.92,0.46 -1.16,0 -1.92,-0.46 -0.7499997,-0.46 -1.1199997,-1.29 -0.36,-0.83 -0.36,-1.94 0,-1.11 0.36,-1.93 0.37,-0.82 1.1199997,-1.27 0.76,-0.46 1.93,-0.46 1.16,0 1.91,0.46 0.75,0.45 1.11,1.28 0.37,0.82 0.37,1.93 z m -5.21,0 q 0,1.12 0.43,1.77 0.43,0.64 1.38,0.64 0.97,0 1.39,-0.64 0.42,-0.65 0.42,-1.77 0,-1.13 -0.42,-1.77 -0.42,-0.64 -1.38,-0.64 -0.96,0 -1.39,0.64 -0.43,0.64 -0.43,1.77 z"
|
||||
id="path15280" />
|
||||
<path
|
||||
d="m 22.909993,-3.64 q 0,1.81 -1.03,2.73 -1.02,0.91 -2.87,0.91 h -2.02 v -7.14 h 2.24 q 1.12,0 1.94,0.4 0.83,0.4 1.28,1.18 0.46,0.77 0.46,1.92 z m -1.57,0.04 q 0,-1.19 -0.52,-1.74 -0.52,-0.56 -1.51,-0.56 h -0.81 v 4.65 h 0.65 q 2.19,0 2.19,-2.35 z"
|
||||
id="path15282" />
|
||||
<path
|
||||
d="m 28.49999,0 h -4.11 v -7.14 h 4.11 v 1.24 h -2.6 v 1.57 h 2.42 v 1.24 h -2.42 v 1.84 h 2.6 z"
|
||||
id="path15284" />
|
||||
<path
|
||||
d="m 32.259987,-0.7 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
id="path15286" />
|
||||
<path
|
||||
d="m 35.109986,-0.7 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
id="path15288" />
|
||||
<path
|
||||
d="m 37.41,-0.7 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
style="letter-spacing:-0.03em"
|
||||
id="path15290" />
|
||||
</g>
|
||||
<path
|
||||
d="m 497.93982,231.36 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
id="path15286-3"
|
||||
style="font-weight:700;font-size:10px;font-family:Inter-Bold, Inter;font-variation-settings:'slnt' 0, 'wght' 700;stroke:none;stroke-opacity:1;fill:#ffffff;fill-opacity:1" />
|
||||
<path
|
||||
d="m 500.25948,231.36 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
id="path15288-6"
|
||||
style="font-weight:700;font-size:10px;font-family:Inter-Bold, Inter;font-variation-settings:'slnt' 0, 'wght' 700;fill:#ffffff;fill-opacity:1" />
|
||||
<path
|
||||
d="m 502.73627,231.36 q 0,-0.46 0.25,-0.64 0.25,-0.19 0.61,-0.19 0.35,0 0.6,0.19 0.25,0.18 0.25,0.64 0,0.44 -0.25,0.64 -0.25,0.19 -0.6,0.19 -0.36,0 -0.61,-0.19 -0.25,-0.2 -0.25,-0.64 z"
|
||||
style="font-weight:700;font-size:10px;font-family:Inter-Bold, Inter;font-variation-settings:'slnt' 0, 'wght' 700;letter-spacing:-0.03em;fill:#ffffff;fill-opacity:1"
|
||||
id="path15290-7" />
|
||||
</g>
|
||||
<path
|
||||
id="line8746"
|
||||
class="e"
|
||||
|
||||
|
Before Width: | Height: | Size: 104 KiB After Width: | Height: | Size: 106 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 68 KiB |
@ -26,12 +26,12 @@
|
||||
inkscape:deskcolor="#505050"
|
||||
showgrid="false"
|
||||
inkscape:zoom="2.8087655"
|
||||
inkscape:cx="395.72545"
|
||||
inkscape:cx="390.74106"
|
||||
inkscape:cy="169.64748"
|
||||
inkscape:window-width="3840"
|
||||
inkscape:window-height="2303"
|
||||
inkscape:window-x="3840"
|
||||
inkscape:window-y="2160"
|
||||
inkscape:window-height="2123"
|
||||
inkscape:window-x="0"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="Layer_1" />
|
||||
<style
|
||||
@ -1341,6 +1341,44 @@
|
||||
id="path26543" />
|
||||
</g>
|
||||
</g>
|
||||
</g><g
|
||||
id="g26539-3"
|
||||
transform="translate(81.75951,0.646741)">
|
||||
<path
|
||||
class="st8"
|
||||
d="m 347.6,336.4 h -15.1 c -1.8,0 -3.3,-1.5 -3.3,-3.3 v -18.6 c 0,-1.8 1.5,-3.3 3.3,-3.3 h 15.1 c 1.8,0 3.3,1.5 3.3,3.3 v 18.6 c 0,1.9 -1.5,3.3 -3.3,3.3 z"
|
||||
id="path26531-6"
|
||||
style="fill:#122745" />
|
||||
<g
|
||||
id="g26537-7">
|
||||
<g
|
||||
id="g26535-5">
|
||||
<path
|
||||
class="st12"
|
||||
d="m 339.6,326.6 h -2.3 v -7.1 h 2.4 c 0.7,0 1.3,0.1 1.8,0.4 0.5,0.3 0.9,0.7 1.1,1.2 0.3,0.5 0.4,1.2 0.4,1.9 0,0.7 -0.1,1.4 -0.4,1.9 -0.3,0.5 -0.7,0.9 -1.2,1.2 -0.5,0.3 -1,0.5 -1.8,0.5 z m -1.2,-1 h 1.2 c 0.5,0 1,-0.1 1.3,-0.3 0.4,-0.2 0.6,-0.5 0.8,-0.9 0.2,-0.4 0.3,-0.9 0.3,-1.4 0,-0.6 -0.1,-1 -0.3,-1.4 -0.2,-0.4 -0.4,-0.7 -0.8,-0.9 -0.4,-0.2 -0.8,-0.3 -1.3,-0.3 h -1.2 z"
|
||||
id="path26533-3"
|
||||
style="fill:#ffffff" />
|
||||
</g>
|
||||
</g>
|
||||
</g><g
|
||||
id="g26549-5"
|
||||
transform="translate(83.403482,0.646741)">
|
||||
<path
|
||||
class="st8"
|
||||
d="M 388.1,336.4 H 373 c -1.8,0 -3.3,-1.5 -3.3,-3.3 v -18.6 c 0,-1.8 1.5,-3.3 3.3,-3.3 h 15.1 c 1.8,0 3.3,1.5 3.3,3.3 v 18.6 c -0.1,1.9 -1.5,3.3 -3.3,3.3 z"
|
||||
id="path26541-6"
|
||||
style="fill:#122745" />
|
||||
<g
|
||||
id="g26547-2">
|
||||
<g
|
||||
id="g26545-9">
|
||||
<path
|
||||
class="st12"
|
||||
d="m 380.1,326.6 h -2.3 v -7.1 h 2.4 c 0.7,0 1.3,0.1 1.8,0.4 0.5,0.3 0.9,0.7 1.1,1.2 0.3,0.5 0.4,1.2 0.4,1.9 0,0.7 -0.1,1.4 -0.4,1.9 -0.3,0.5 -0.7,0.9 -1.2,1.2 -0.5,0.3 -1.1,0.5 -1.8,0.5 z m -1.2,-1 h 1.2 c 0.5,0 1,-0.1 1.3,-0.3 0.4,-0.2 0.6,-0.5 0.8,-0.9 0.2,-0.4 0.3,-0.9 0.3,-1.4 0,-0.6 -0.1,-1 -0.3,-1.4 -0.2,-0.4 -0.4,-0.7 -0.8,-0.9 -0.4,-0.2 -0.8,-0.3 -1.3,-0.3 h -1.2 z"
|
||||
id="path26543-1"
|
||||
style="fill:#ffffff" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g
|
||||
id="g26561">
|
||||
@ -1443,65 +1481,9 @@
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g
|
||||
id="g26619">
|
||||
<path
|
||||
class="st7"
|
||||
d="M432.4,338.7h-19c-1.8,0-3.3-1.5-3.3-3.3v-23.2c0-1.8,1.5-3.3,3.3-3.3h19c1.8,0,3.3,1.5,3.3,3.3v23.2 C435.6,337.3,434.2,338.7,432.4,338.7z"
|
||||
id="path26609" />
|
||||
<path
|
||||
class="st11"
|
||||
d="M430.4,336.4h-15.1c-1.8,0-3.3-1.5-3.3-3.3v-18.6c0-1.8,1.5-3.3,3.3-3.3h15.1c1.8,0,3.3,1.5,3.3,3.3v18.6 C433.7,335,432.2,336.4,430.4,336.4z"
|
||||
id="path26611" />
|
||||
<g
|
||||
id="g26617">
|
||||
<g
|
||||
id="g26615">
|
||||
<path
|
||||
class="st12"
|
||||
d="M420.5,326.6v-7.1h2.5c0.6,0,1,0.1,1.4,0.3c0.4,0.2,0.6,0.5,0.8,0.8c0.2,0.3,0.3,0.7,0.3,1.2 c0,0.4-0.1,0.8-0.3,1.2s-0.5,0.6-0.8,0.8s-0.8,0.3-1.4,0.3h-1.7v-0.9h1.6c0.3,0,0.6-0.1,0.8-0.2s0.4-0.3,0.5-0.5 c0.1-0.2,0.2-0.4,0.2-0.7c0-0.3-0.1-0.5-0.2-0.7c-0.1-0.2-0.3-0.4-0.5-0.5c-0.2-0.1-0.5-0.2-0.9-0.2h-1.3v6.2H420.5z"
|
||||
id="path26613" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g
|
||||
id="g26631">
|
||||
<path
|
||||
class="st7"
|
||||
d="M473.4,338.7h-19c-1.8,0-3.3-1.5-3.3-3.3v-23.2c0-1.8,1.5-3.3,3.3-3.3h19c1.8,0,3.3,1.5,3.3,3.3v23.2 C476.7,337.3,475.2,338.7,473.4,338.7z"
|
||||
id="path26621" />
|
||||
<path
|
||||
class="st11"
|
||||
d="M471.5,336.4h-15.1c-1.8,0-3.3-1.5-3.3-3.3v-18.6c0-1.8,1.5-3.3,3.3-3.3h15.1c1.8,0,3.3,1.5,3.3,3.3v18.6 C474.7,335,473.2,336.4,471.5,336.4z"
|
||||
id="path26623" />
|
||||
<g
|
||||
id="g26629">
|
||||
<g
|
||||
id="g26627">
|
||||
<path
|
||||
class="st12"
|
||||
d="M461.6,326.6v-7.1h2.5c0.6,0,1,0.1,1.4,0.3c0.4,0.2,0.6,0.5,0.8,0.8c0.2,0.3,0.3,0.7,0.3,1.2 c0,0.4-0.1,0.8-0.3,1.2s-0.5,0.6-0.8,0.8s-0.8,0.3-1.4,0.3h-1.7v-0.9h1.6c0.3,0,0.6-0.1,0.8-0.2s0.4-0.3,0.5-0.5 c0.1-0.2,0.2-0.4,0.2-0.7c0-0.3-0.1-0.5-0.2-0.7c-0.1-0.2-0.3-0.4-0.5-0.5c-0.2-0.1-0.5-0.2-0.9-0.2h-1.3v6.2H461.6z"
|
||||
id="path26625" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g
|
||||
id="g26641">
|
||||
<path
|
||||
class="st11"
|
||||
d="M471.5,336.4h-15.1c-1.8,0-3.3-1.5-3.3-3.3v-18.6c0-1.8,1.5-3.3,3.3-3.3h15.1c1.8,0,3.3,1.5,3.3,3.3v18.6 C474.7,335,473.2,336.4,471.5,336.4z"
|
||||
id="path26633" />
|
||||
<g
|
||||
id="g26639">
|
||||
<g
|
||||
id="g26637">
|
||||
<path
|
||||
class="st12"
|
||||
d="M461.6,326.6v-7.1h2.5c0.6,0,1,0.1,1.4,0.3c0.4,0.2,0.6,0.5,0.8,0.8c0.2,0.3,0.3,0.7,0.3,1.2 c0,0.4-0.1,0.8-0.3,1.2s-0.5,0.6-0.8,0.8s-0.8,0.3-1.4,0.3h-1.7v-0.9h1.6c0.3,0,0.6-0.1,0.8-0.2s0.4-0.3,0.5-0.5 c0.1-0.2,0.2-0.4,0.2-0.7c0-0.3-0.1-0.5-0.2-0.7c-0.1-0.2-0.3-0.4-0.5-0.5c-0.2-0.1-0.5-0.2-0.9-0.2h-1.3v6.2H461.6z"
|
||||
id="path26635" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
|
||||
|
||||
|
||||
<g
|
||||
id="g26651">
|
||||
<path
|
||||
|
||||
|
Before Width: | Height: | Size: 99 KiB After Width: | Height: | Size: 98 KiB |
File diff suppressed because it is too large
Load Diff
|
Before Width: | Height: | Size: 134 KiB After Width: | Height: | Size: 145 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 115 KiB |
1
source/images/erasure/erasure-coding-erasure-set.svg
Normal file
1
source/images/erasure/erasure-coding-erasure-set.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 71 KiB |
1
source/images/erasure/erasure-coding-possible-parity.svg
Normal file
1
source/images/erasure/erasure-coding-possible-parity.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 123 KiB |
1
source/images/erasure/erasure-coding-shard-healing.svg
Normal file
1
source/images/erasure/erasure-coding-shard-healing.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 118 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 116 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 66 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 73 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 72 KiB |
1
source/images/erasure/erasure-coding-shard.svg
Normal file
1
source/images/erasure/erasure-coding-shard.svg
Normal file
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 62 KiB |
@ -48,7 +48,7 @@ MinIO provides best performance when using locally-attached storage, such as NVM
|
||||
Each SSD connects by SAS to a PCI-E-attached storage controller operating in HBA mode
|
||||
|
||||
MinIO automatically groups drives in the pool into :ref:`erasure sets <minio-ec-erasure-set>`.
|
||||
Erasure sets are the foundational component of MinIO :ref:`availability and resiliency <minio_availability-resiliency>`.
|
||||
Erasure sets are the foundational component of MinIO :ref:`availability and resiliency <minio-availability-resiliency>`.
|
||||
MinIO stripes erasure sets symmetrically across the nodes in the pool to maintain even distribution of erasure set drives.
|
||||
MinIO then partitions objects into data and parity shards based on the deployment :ref:`parity <minio-ec-parity>` and distributes them across an erasure set.
|
||||
|
||||
@ -56,10 +56,11 @@ MinIO automatically groups drives in the pool into :ref:`erasure sets <minio-ec-
|
||||
|
||||
.. figure:: /images/architecture/architecture-erasure-set-shard.svg
|
||||
:figwidth: 100%
|
||||
:alt: Diagram of object being sharded into four data and four parity blocks, distributed across eight drives
|
||||
:alt: Diagram of object being sharded into eight data and eight parity blocks, distributed across sixteen drives
|
||||
:align: center
|
||||
|
||||
With the default parity of ``EC:4``, MinIO shards the object into 4 data and 4 parity blocks, distributing them across the drives in the erasure set.
|
||||
With the maximum parity of ``EC:8``, MinIO shards the object into 8 data and 8 parity blocks, distributing them across the drives in the erasure set.
|
||||
All erasure sets in this pool have the same stripe size and shard distribution.
|
||||
|
||||
MinIO uses a deterministic hashing algorithm based on object name and path to select the erasure set for a given object.
|
||||
For each unique object namespace ``BUCKET/PREFIX/[PREFIX/...]/OBJECT.EXTENSION``, MinIO always selects the same erasure set for read/write operations.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
.. _minio_availability-resiliency:
|
||||
.. _minio-availability-resiliency:
|
||||
|
||||
===========================
|
||||
Availability and Resiliency
|
||||
|
||||
@ -10,62 +10,129 @@ Erasure Coding
|
||||
:local:
|
||||
:depth: 2
|
||||
|
||||
MinIO Erasure Coding is a data redundancy and availability feature that allows MinIO deployments to automatically reconstruct objects on-the-fly despite the loss of multiple drives or nodes in the cluster.
|
||||
Erasure Coding provides object-level healing with significantly less overhead than adjacent technologies such as RAID or replication.
|
||||
.. meta::
|
||||
:keywords: erasure coding, healing, availability, resiliency
|
||||
:description: Information on MinIO Erasure Coding
|
||||
|
||||
MinIO partitions each new object into data and parity shards, where parity shards support reconstruction of missing or corrupted data shards.
|
||||
MinIO writes these shards to a single :ref:`erasure set <minio-ec-erasure-set>` in the deployment.
|
||||
MinIO can use either data or parity shards to reconstruct an object, as long as the erasure set has :ref:`read quorum <minio-read-quorum>`.
|
||||
For example, MinIO can use parity shards local to the node receiving a request instead of specifically filtering only those nodes or drives containing data shards.
|
||||
MinIO implements Erasure Coding as a core component in providing data redundancy and availability.
|
||||
This page provides an introduction to MinIO Erasure Coding.
|
||||
|
||||
Since erasure set drives are striped across the server pool, a given node contains only a portion of data or parity shards for each object.
|
||||
MinIO can therefore tolerate the loss of multiple drives or nodes in the deployment depending on the configured parity and deployment topology.
|
||||
See :ref:`minio-availability-resiliency` and :ref:`minio-architecture` for more information on how MinIO uses erasure coding in production deployments.
|
||||
|
||||
.. image:: /images/erasure-code.jpg
|
||||
:width: 600px
|
||||
:alt: MinIO Erasure Coding example
|
||||
:align: center
|
||||
.. admonition:: MinIO SUBNET Support for Planning and Configuration of Erasure Coding
|
||||
:class: note
|
||||
|
||||
At maximum parity, MinIO can tolerate the loss of up to half the drives per erasure set (:math:`(N / 2) - 1`) and still perform read and write operations.
|
||||
MinIO defaults to 4 parity shards per object with tolerance for the loss of 4 drives per erasure set.
|
||||
For more complete information on selecting erasure code parity, see :ref:`minio-ec-parity`.
|
||||
|
||||
Use the MinIO `Erasure Code Calculator <https://min.io/product/erasure-code-calculator?ref=docs>`__ when planning and designing your MinIO deployment to explore the effect of erasure code settings on your intended topology.
|
||||
|subnet| provides 24/7 direct-to-engineering consultation during planning, implementation, and active stages of your production deployments.
|
||||
SUBNET customers should open an issue to have MinIO engineering review the architecture and deployment strategies against your goals to ensure long-term success of your workloads.
|
||||
|
||||
.. _minio-ec-basics:
|
||||
.. _minio-ec-erasure-set:
|
||||
|
||||
Erasure Sets
|
||||
------------
|
||||
Erasure Coding Basics
|
||||
---------------------
|
||||
|
||||
An *Erasure Set* is a group of drives onto which MinIO writes erasure coded objects.
|
||||
MinIO randomly and uniformly distributes the data and parity shards of a given object across the erasure set drives, where a given drive has no more than one block of either type per object (no overlap).
|
||||
|
||||
MinIO automatically calculates the number and size of Erasure Sets ("stripe size") based on the total number of nodes and drives in the :ref:`Server Pool <minio-intro-server-pool>`, where the minimum stripe size is 2 and the maximum stripe size is 16.
|
||||
All erasure sets in a given pool have the same stripe size, and MinIO never modifies nor allows modification of stripe size after initial configuration.
|
||||
The algorithm for selecting stripe size takes into account the total number of nodes in the deployment, such that the selected stripe allows for uniform distribution of erasure set drives across all nodes in the pool.
|
||||
.. note::
|
||||
|
||||
The diagrams and content in this section present a simplified view of MinIO erasure coding operations and are not intended to represent the complexities of MinIO's full erasure coding implementation.
|
||||
|
||||
MinIO groups drives in each :term:`server pool` into one or more **Erasure Sets** of the same size.
|
||||
.. figure:: /images/erasure/erasure-coding-erasure-set.svg
|
||||
:figwidth: 100%
|
||||
:align: center
|
||||
:alt: Diagram of erasure set covering 4 nodes and 16 drives
|
||||
|
||||
The above example deployment consists of 4 nodes with 4 drives each.
|
||||
MinIO initializes with a single erasure set consisting of all 16 drives across all four nodes.
|
||||
|
||||
MinIO determines the optimal number and size of erasure sets when initializing a :term:`server pool`.
|
||||
You cannot modify these settings after this initial setup.
|
||||
|
||||
For each write operation, MinIO partitions the object into **data** and **parity** shards.
|
||||
Erasure set stripe size dictates the maximum possible :ref:`parity <minio-ec-parity>` of the deployment.
|
||||
The formula for determining the number of data and parity shards to generate is:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
N (ERASURE SET SIZE) = K (DATA) + M (PARITY)
|
||||
|
||||
.. figure:: /images/erasure/erasure-coding-possible-parity.svg
|
||||
:figwidth: 100%
|
||||
:align: center
|
||||
:alt: Diagram of possible erasure set parity settings
|
||||
|
||||
The above example deployment has an erasure set of 16 drives.
|
||||
This can support parity between ``EC:0`` and 1/2 the erasure set drives, or ``EC:8``.
|
||||
|
||||
You can set the parity value between 0 and 1/2 the Erasure Set size.
|
||||
.. figure:: /images/erasure/erasure-coding-erasure-set-shard-distribution.svg
|
||||
:figwidth: 100%
|
||||
:align: center
|
||||
:alt: Diagram of an object being sharded using MinIO's Reed-Solomon Erasure Coding algorithm.
|
||||
|
||||
MinIO uses a Reed-Solomon erasure coding implementation and partitions the object for distribution across an erasure set.
|
||||
The example deployment above has an erasure set size of 16 and a parity of ``EC:4``
|
||||
|
||||
Objects written with a given parity settings do not automatically update if you change the parity values later.
|
||||
|
||||
MinIO requires a minimum of ``K`` shards of any type to **read** an object.
|
||||
The value ``K`` here constitutes the **read quorum** for the deployment.
|
||||
The erasure set must therefore have at least ``K`` healthy drives in the erasure set to support read operations.
|
||||
|
||||
.. figure:: /images/erasure/erasure-coding-shard-read-quorum.svg
|
||||
:figwidth: 100%
|
||||
:align: center
|
||||
:alt: Diagram of a 4-node 16-drive deployment with one node offline.
|
||||
|
||||
This deployment has one offline node, resulting in only 12 remaining healthy drives.
|
||||
The object was written with ``EC:4`` with a read quorum of ``K=12``.
|
||||
This object therefore maintains read quorum and MinIO can reconstruct it for read operations.
|
||||
|
||||
MinIO cannot reconstruct an object that has lost read quorum.
|
||||
Such objects may be recovered through other means such as :ref:`replication resynchronization <minio-bucket-replication-resynchronize>`.
|
||||
|
||||
MinIO requires a minimum of ``K`` erasure set drives to **write** an object.
|
||||
The value ``K`` here constitutes the **write quorum** for the deployment.
|
||||
The erasure set must therefore have at least ``K`` available drives online to support write operations.
|
||||
|
||||
.. figure:: /images/erasure/erasure-coding-shard-write-quorum.svg
|
||||
:figwidth: 100%
|
||||
:align: center
|
||||
:alt: Diagram of a 4-node 16-drive deployment where one node is offline.
|
||||
|
||||
This deployment has one offline node, resulting in only 12 remaining healthy drives.
|
||||
A client writes an object with ``EC:4`` parity settings where the erasure set has a write quorum of ``K=12``.
|
||||
This erasure set maintains write quorum and MinIO can use it for write operations.
|
||||
|
||||
If Parity ``EC:M`` is exactly 1/2 the erasure set size, **write quorum** is ``K+1``
|
||||
This prevents a split-brain type scenario, such as one where a network issue isolates exactly half the erasure set drives from the other.
|
||||
|
||||
.. figure:: /images/erasure/erasure-coding-shard-split-brain.svg
|
||||
:figwidth: 100%
|
||||
:align: center
|
||||
:alt: Diagram of an erasure set with where Parity ``EC:M`` is 1/2 the set size
|
||||
|
||||
This deployment has two nodes offline due to a transient network failure.
|
||||
A client writes an object with ``EC:8`` parity settings where the erasure set has a write quorum of ``K=9``.
|
||||
This erasure set has lost write quorum and MinIO cannot use it for write operations.
|
||||
|
||||
The ``K+1`` logic ensures that a client could not potentially write the same object twice - once to each "half" of the erasure set.
|
||||
|
||||
For an object maintaining **read quorum**, MinIO can use any data or parity shard to heal damaged shards.
|
||||
.. figure:: /images/erasure/erasure-coding-shard-healing.svg
|
||||
:figwidth: 100%
|
||||
:align: center
|
||||
:alt: Diagram of MinIO using parity shards to heal lost data shards on a node.
|
||||
|
||||
An object with ``EC:4`` lost four data shards out of 12 due to drive failures.
|
||||
Since the object has maintained **read quorum**, MinIO can heal those lost data shards using the available parity shards.
|
||||
|
||||
Erasure set stripe size dictates the maximum possible :ref:`parity <minio-ec-parity>` of the deployment.
|
||||
Use the MinIO `Erasure Coding Calculator <https://min.io/product/erasure-code-calculator>`__ to explore the possible erasure set size and distributions for your planned topology.
|
||||
MinIO strongly recommends architecture reviews via |SUBNET| as part of your provisioning and deployment process to ensure long term success and stability.
|
||||
As a general guide, plan your topologies to have an even number of nodes and drives where both the nodes and drives have a common denominator of 16.
|
||||
Where possible, use an even number of nodes and drives per node to simplify topology planning and conceptualization of drive/erasure-set distribution.
|
||||
|
||||
.. _minio-ec-parity:
|
||||
|
||||
Erasure Code Parity (``EC:N``)
|
||||
------------------------------
|
||||
|
||||
MinIO uses a Reed-Solomon algorithm to split objects into data and parity shards based on the :ref:`Erasure Set <minio-ec-erasure-set>` size in the deployment.
|
||||
For a given erasure set of size ``M``, MinIO splits objects into ``N`` parity shards and ``M-N`` data shards.
|
||||
|
||||
MinIO uses the ``EC:N`` notation to refer to the number of parity shards (``N``) in the deployment.
|
||||
MinIO defaults to ``EC:4`` or 4 parity shards per object.
|
||||
MinIO uses the same ``EC:N`` value for all erasure sets and :ref:`server pools <minio-intro-server-pool>` in the deployment.
|
||||
|
||||
.. _minio-read-quorum:
|
||||
.. _minio-write-quorum:
|
||||
|
||||
MinIO can tolerate the loss of up to ``N`` drives per erasure set and continue performing read and write operations ("quorum").
|
||||
If ``N`` is equal to exactly 1/2 the drives in the erasure set, MinIO write quorum requires :math:`N + 1` drives to avoid data inconsistency ("split-brain").
|
||||
Erasure Parity and Storage Efficiency
|
||||
-------------------------------------
|
||||
|
||||
Setting the parity for a deployment is a balance between availability and total usable storage.
|
||||
Higher parity values increase resiliency to drive or node failure at the cost of usable storage, while lower parity provides maximum storage with reduced tolerance for drive/node failures.
|
||||
@ -102,94 +169,14 @@ The following table lists the outcome of varying erasure code parity levels on a
|
||||
- 8
|
||||
- 9
|
||||
|
||||
.. _minio-ec-storage-class:
|
||||
Bitrot Protection
|
||||
-----------------
|
||||
|
||||
Storage Classes
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
MinIO supports redundancy storage classes with Erasure Coding to allow applications to specify per-object :ref:`parity <minio-ec-parity>`.
|
||||
Each storage class specifies a ``EC:N`` parity setting to apply to objects created with that class.
|
||||
|
||||
MinIO storage classes for erasure coding are *distinct* from Amazon Web Services :s3-docs:`storage classes <storage-class-intro.html>` used for tiering.
|
||||
MinIO erasure coding storage classes define *parity settings per object*, while AWS storage classes define *storage tiers per object*.
|
||||
|
||||
.. note::
|
||||
For transitioning objects between storage classes for tiering purposes in MinIO, refer to the documentation on :ref:`lifecycle management <minio-lifecycle-management-tiering>`.
|
||||
|
||||
MinIO provides the following two storage classes:
|
||||
|
||||
.. tab-set::
|
||||
|
||||
.. tab-item:: STANDARD
|
||||
|
||||
The ``STANDARD`` storage class is the default class for all objects.
|
||||
MinIO sets the ``STANDARD`` parity based on the number of volumes in the Erasure Set:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:widths: 30 70
|
||||
:width: 100%
|
||||
|
||||
* - Erasure Set Size
|
||||
- Default Parity (EC:N)
|
||||
|
||||
* - 5 or Fewer
|
||||
- EC:2
|
||||
|
||||
* - 6 - 7
|
||||
- EC:3
|
||||
|
||||
* - 8 or more
|
||||
- EC:4
|
||||
|
||||
You can override the default ``STANDARD`` parity using either:
|
||||
|
||||
- The :envvar:`MINIO_STORAGE_CLASS_STANDARD` environment variable, *or*
|
||||
- The :mc:`mc admin config` command to modify the ``storage_class.standard`` configuration setting.
|
||||
|
||||
The maximum value is half of the total drives in the :ref:`Erasure Set <minio-ec-erasure-set>`.
|
||||
The minimum value is ``2``.
|
||||
|
||||
``STANDARD`` parity *must* be greater than or equal to ``REDUCED_REDUNDANCY``.
|
||||
If ``REDUCED_REDUNDANCY`` is unset, ``STANDARD`` parity *must* be greater than 2.
|
||||
|
||||
.. tab-item:: REDUCED_REDUNDANCY
|
||||
|
||||
The ``REDUCED_REDUNDANCY`` storage class allows creating objects with lower parity than ``STANDARD``.
|
||||
``REDUCED_REDUNDANCY`` requires *at least* 5 drives in the MinIO deployment.
|
||||
|
||||
MinIO sets the ``REDUCED_REDUNDANCY`` parity to ``EC:2`` by default.
|
||||
You can override ``REDUCED_REDUNDANCY`` storage class parity using either:
|
||||
|
||||
- The :envvar:`MINIO_STORAGE_CLASS_RRS` environment variable, *or*
|
||||
- The :mc:`mc admin config` command to modify the ``storage_class.rrs`` configuration setting.
|
||||
|
||||
``REDUCED_REDUNDANCY`` parity *must* be less than or equal to ``STANDARD``.
|
||||
|
||||
MinIO references the ``x-amz-storage-class`` header in request metadata for determining which storage class to assign an object.
|
||||
The specific syntax or method for setting headers depends on your preferred method for interfacing with the MinIO server.
|
||||
|
||||
- For the :mc:`mc` command line tool, certain commands include a specific option for setting the storage class.
|
||||
For example, the :mc:`mc cp` command has the :mc-cmd:`~mc cp storage-class` option for specifying the storage class to assign to the object being copied.
|
||||
|
||||
- For MinIO SDKs, the ``S3Client`` object has specific methods for setting request headers.
|
||||
For example, the ``minio-go`` SDK ``S3Client.PutObject`` method takes a ``PutObjectOptions`` data structure as a parameter.
|
||||
The ``PutObjectOptions`` data structure includes the ``StorageClass`` option for specifying the storage class to assign to the object being created.
|
||||
|
||||
|
||||
.. _minio-ec-bitrot-protection:
|
||||
|
||||
Bit Rot Protection
|
||||
------------------
|
||||
|
||||
.. TODO- ReWrite w/ more detail.
|
||||
|
||||
Silent data corruption or bit rot is a serious problem faced by data drives resulting in data getting corrupted without the user’s knowledge.
|
||||
The corruption of data occurs when the electrical charge on a portion of the drive disperses or changes with no notification to or input from the user.
|
||||
Many events can lead to such a silent corruption of stored data.
|
||||
For example, ageing drives, current spikes, bugs in drive firmware, phantom writes, misdirected reads/writes, driver errors, accidental overwrites, or a random cosmic ray can each lead to a bit change.
|
||||
Whatever the cause, the result is the same - compromised data.
|
||||
`Bit rot <https://en.wikipedia.org/wiki/Data_degradation>__` is silent data corruption from random changes at the storage media level.
|
||||
For data drives, it is typically the result of decay of the electrical charge or magnetic orientation that represents the data.
|
||||
These sources can range from the small current spike during a power outage to a random cosmic ray resulting in flipped bits.
|
||||
The resulting "bit rot" can cause subtle errors or corruption on the data medium without triggering monitoring tools or hardware.
|
||||
|
||||
MinIO’s optimized implementation of the :minio-git:`HighwayHash algorithm <highwayhash/blob/master/README.md>` ensures that it captures and heals corrupted objects on the fly.
|
||||
Integrity is ensured from end to end by computing a hash on READ and verifying it on WRITE from the application, across the network, and to the memory or drive.
|
||||
The implementation is designed for speed and can achieve hashing speeds over 10 GB/sec on a single core on Intel CPUs.
|
||||
The implementation is designed for speed and can achieve hashing speeds over 10 GB/sec on a single core on Intel CPUs.
|
||||
@ -528,41 +528,62 @@ Key Management Service and Encryption
|
||||
Storage Class
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
These environment variables configure the :ref:`parity <minio-ec-parity>`
|
||||
to use for objects written to the MinIO cluster.
|
||||
These environment variables configure the :ref:`parity <minio-ec-parity>` to use for objects written to the MinIO cluster.
|
||||
|
||||
MinIO Storage Classes are distinct from AWS Storage Classes, where the latter
|
||||
refers to the specific storage tier on which to store a given object.
|
||||
MinIO Storage Classes are distinct from AWS Storage Classes, where the latter refers to the specific storage tier on which to store a given object.
|
||||
|
||||
.. envvar:: MINIO_STORAGE_CLASS_STANDARD
|
||||
|
||||
The number of :ref:`parity blocks <minio-ec-parity>` to create for
|
||||
objects with the standard (default) storage class. MinIO uses the
|
||||
``EC:N`` notation to refer to the number of parity blocks (``N``).
|
||||
This environment variable only applies to deployments with
|
||||
:ref:`Erasure Coding <minio-erasure-coding>` enabled.
|
||||
The :ref:`parity level <minio-ec-parity>` for the deployment.
|
||||
MinIO shards objects written with the default ``STANDARD`` storage class using this parity value.
|
||||
|
||||
The minimum value at startup is ``0``.
|
||||
0 parity setups have no erasure coding protections and rely entirely on the storage controller or resource for availability / resiliency.
|
||||
MinIO references the ``x-amz-storage-class`` header in request metadata for determining which storage class to assign an object.
|
||||
The specific syntax or method for setting headers depends on your preferred method for interfacing with the MinIO server.
|
||||
|
||||
The maximum value is 1/2 the erasure set stripe size.
|
||||
Specify the value using ``EC:M`` notation, where ``M`` refers to the number of parity blocks to create for the object.
|
||||
|
||||
The following table lists the default values based on the :ref:`erasure set size <minio-ec-erasure-set>` of the initial server pool in the deployment:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:widths: 30 70
|
||||
:width: 100%
|
||||
|
||||
* - Erasure Set Size
|
||||
- Default Parity (EC:N)
|
||||
|
||||
* - 4-5
|
||||
- EC:2
|
||||
|
||||
* - 6 - 7
|
||||
- EC:3
|
||||
|
||||
* - 8 - 16
|
||||
- EC:4
|
||||
|
||||
The minimum supported value is ``0``, which indicates no erasure coding protections.
|
||||
These deployments rely entirely on the storage controller or resource for availability / resiliency.
|
||||
|
||||
The maximum value depends on the erasure set size of the initial server pool in the deployment, where the upper bound is :math:`\frac{\text{ERASURE_SET_SIZE}}{\text{2}}`.
|
||||
For example, a deployment with erasure set stripe size of 16 has a maximum standard parity of 8.
|
||||
|
||||
You can change the Standard parity after startup to a value between ``1`` and :math:`\tfrac{1}{2}\ (ERASURE_SET_SIZE)`.
|
||||
You can change this value after startup to any value between ``0`` and the upper bound for the erasure set size.
|
||||
MinIO only applies the changed parity to newly written objects.
|
||||
Existing objects retain the parity value in place at the time of their creation.
|
||||
|
||||
Defaults to ``4``.
|
||||
|
||||
.. envvar:: MINIO_STORAGE_CLASS_RRS
|
||||
|
||||
The number of :ref:`parity blocks <minio-ec-parity>` to create for objects
|
||||
with the reduced redundancy storage class. MinIO uses the ``EC:N``
|
||||
notation to refer to the number of parity blocks (``N``). This environment
|
||||
variable only applies to deployments with :ref:`Erasure Coding
|
||||
<minio-erasure-coding>` enabled.
|
||||
The :ref:`parity level <minio-ec-parity>` for objects written with the ``REDUCED`` storage class.
|
||||
|
||||
Defaults to ``2``.
|
||||
MinIO references the ``x-amz-storage-class`` header in request metadata for determining which storage class to assign an object.
|
||||
The specific syntax or method for setting headers depends on your preferred method for interfacing with the MinIO server.
|
||||
|
||||
Specify the value using ``EC:M`` notation, where ``M`` refers to the number of parity blocks to create for the object.
|
||||
|
||||
This value **must be** less than or equal to :envvar:`MINIO_STORAGE_CLASS_STANDARD`.
|
||||
|
||||
You cannot set this value for deployments with an erasure set size less than 5.
|
||||
Defaults to ``EC:2``.
|
||||
|
||||
.. envvar:: MINIO_STORAGE_CLASS_COMMENT
|
||||
|
||||
|
||||
Reference in New Issue
Block a user