# Hesela storage glossary (full text)

> Full text of the 655 glossary terms and 56 derived datasets on hesela.dev. Short index: https://hesela.dev/llms.txt. Machine-readable JSON: https://hesela.dev/data/index.json.

## Datasets

### Backblaze hard drive AFR by capacity group, 2022 to 2025

URL: https://hesela.dev/datasets/backblaze-2022-2025-afr-by-capacity/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2022-2025-afr-by-capacity.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2022-2025-afr-by-capacity.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2022-2025-afr-by-capacity.svg
Rows: 25
License: Derivative table computed from the Backblaze Drive Stats daily files for 2022 to 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 25-row aggregate, not the daily SMART archive, and that archive is not for sale.

Yearly annualized failure rate of Backblaze's hard drives by nominal capacity group, computed from the raw daily Drive Stats files for 2022 to 2025 (sixteen quarterly zips) with the drive-day exposure of each group and exact 95% Poisson intervals. Sample: drives of 3 TB or more, 388,670,883 drive days and 16,051 failures over the four years. In 2025 the 20 to 22 TB group was at 0.51% on 16.0% of drive days, 16 to 18 TB at 1.03%, 12 to 14 TB at 1.84% and 8 to 10 TB at 2.19%. One fleet, and capacity groups mix models and ages, so the file does not show an effect of size.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- year (integer): Calendar year, 2022 to 2025 (all four quarterly files of the year).
- capacity_group (string): All hard drives of 3 TB or more, or a nominal capacity group from round(capacity_bytes / 1e12): 3 to 6 TB, 8 to 10 TB, 12 to 14 TB, 16 to 18 TB, 20 to 22 TB, 24 TB and above. A group with no drive days in a year has no row.
- drive_days (integer): Daily rows (drive days) of the group in the year. This is the exposure.
- share_of_year_drive_days_percent (number): The group share of the All drive days in that year, one decimal.
- failures (integer): Rows with failure = 1 in the year.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here, with 365 days in every year.
- afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval, in percent.
- afr_high95 (number): Upper bound of the same interval, in percent.

Citations:
- [bb-data-Q12022] Backblaze Hard Drive Test Data, data_Q1_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2022.zip (accessed 2026-10-11)
- [bb-data-Q22022] Backblaze Hard Drive Test Data, data_Q2_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2022.zip (accessed 2026-10-11)
- [bb-data-Q32022] Backblaze Hard Drive Test Data, data_Q3_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2022.zip (accessed 2026-10-11)
- [bb-data-Q42022] Backblaze Hard Drive Test Data, data_Q4_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2022.zip (accessed 2026-10-11)
- [bb-data-Q12023] Backblaze Hard Drive Test Data, data_Q1_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2023.zip (accessed 2026-10-11)
- [bb-data-Q22023] Backblaze Hard Drive Test Data, data_Q2_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2023.zip (accessed 2026-10-11)
- [bb-data-Q32023] Backblaze Hard Drive Test Data, data_Q3_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2023.zip (accessed 2026-10-11)
- [bb-data-Q42023] Backblaze Hard Drive Test Data, data_Q4_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2023.zip (accessed 2026-10-11)
- [bb-data-Q12024] Backblaze Hard Drive Test Data, data_Q1_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2024.zip (accessed 2026-10-11)
- [bb-data-Q22024] Backblaze Hard Drive Test Data, data_Q2_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2024.zip (accessed 2026-10-11)
- [bb-data-Q32024] Backblaze Hard Drive Test Data, data_Q3_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2024.zip (accessed 2026-10-11)
- [bb-data-Q42024] Backblaze Hard Drive Test Data, data_Q4_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2024.zip (accessed 2026-10-11)
- [bb-data-Q12025] Backblaze Hard Drive Test Data, data_Q1_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2025.zip (accessed 2026-10-11)
- [bb-data-Q22025] Backblaze Hard Drive Test Data, data_Q2_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2025.zip (accessed 2026-10-11)
- [bb-data-Q32025] Backblaze Hard Drive Test Data, data_Q3_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2025.zip (accessed 2026-10-11)
- [bb-data-Q42025] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-11)
- [bb-terms] Backblaze Hard Drive Test Data page and use terms. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-11)
- [bb-2025] Backblaze Drive Stats for 2025 (published annual table: 115,638,676 drive days, 4,317 failures, 1.36%). https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/ (accessed 2026-10-11)
- [garwood] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3-4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-11)

### Backblaze hard drive AFR by manufacturer, 2022 to 2025

URL: https://hesela.dev/datasets/backblaze-2022-2025-afr-by-manufacturer/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2022-2025-afr-by-manufacturer.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2022-2025-afr-by-manufacturer.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2022-2025-afr-by-manufacturer.svg
Rows: 23
License: Derivative table computed from the Backblaze Drive Stats daily files for 2022 to 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 23-row aggregate, not the daily SMART archive, and that archive is not for sale.

Yearly annualized failure rate of Backblaze's hard drives for Seagate, HGST, Toshiba and WDC, computed from the raw daily Drive Stats files for 2022 to 2025 (sixteen quarterly zips) with exact 95% Poisson intervals. Sample: drives of 3 TB or more, 388,670,883 drive days and 16,051 failures over the four years. Pooled AFR was 1.39% in 2022, 1.70% in 2023, 1.59% in 2024 and 1.36% in 2025. HGST went from 0.63% in 2022 to 3.01% in 2024 and 2.89% in 2025. One fleet, and the file does not say why rates moved.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- year (integer): Calendar year, 2022 to 2025 (all four quarterly files of the year).
- manufacturer (string): Seagate, HGST, Toshiba, WDC or Other, from the model-name prefix (ST; HGST, HUH, HMS; TOSHIBA; WDC, WUH, WD). Other is the legacy model Hitachi HDS5C4040ALE630 and holds a few thousand drive days. All is every hard drive of 3 TB or more.
- drive_days (integer): Daily rows (drive days) of the group in the year. This is the exposure.
- share_of_year_drive_days_percent (number): The group share of the All drive days in that year, one decimal.
- failures (integer): Rows with failure = 1 in the year.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here, with 365 days in every year.
- afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval, in percent.
- afr_high95 (number): Upper bound of the same interval, in percent.

Citations:
- [bb-data-Q12022] Backblaze Hard Drive Test Data, data_Q1_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2022.zip (accessed 2026-10-11)
- [bb-data-Q22022] Backblaze Hard Drive Test Data, data_Q2_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2022.zip (accessed 2026-10-11)
- [bb-data-Q32022] Backblaze Hard Drive Test Data, data_Q3_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2022.zip (accessed 2026-10-11)
- [bb-data-Q42022] Backblaze Hard Drive Test Data, data_Q4_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2022.zip (accessed 2026-10-11)
- [bb-data-Q12023] Backblaze Hard Drive Test Data, data_Q1_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2023.zip (accessed 2026-10-11)
- [bb-data-Q22023] Backblaze Hard Drive Test Data, data_Q2_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2023.zip (accessed 2026-10-11)
- [bb-data-Q32023] Backblaze Hard Drive Test Data, data_Q3_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2023.zip (accessed 2026-10-11)
- [bb-data-Q42023] Backblaze Hard Drive Test Data, data_Q4_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2023.zip (accessed 2026-10-11)
- [bb-data-Q12024] Backblaze Hard Drive Test Data, data_Q1_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2024.zip (accessed 2026-10-11)
- [bb-data-Q22024] Backblaze Hard Drive Test Data, data_Q2_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2024.zip (accessed 2026-10-11)
- [bb-data-Q32024] Backblaze Hard Drive Test Data, data_Q3_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2024.zip (accessed 2026-10-11)
- [bb-data-Q42024] Backblaze Hard Drive Test Data, data_Q4_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2024.zip (accessed 2026-10-11)
- [bb-data-Q12025] Backblaze Hard Drive Test Data, data_Q1_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2025.zip (accessed 2026-10-11)
- [bb-data-Q22025] Backblaze Hard Drive Test Data, data_Q2_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2025.zip (accessed 2026-10-11)
- [bb-data-Q32025] Backblaze Hard Drive Test Data, data_Q3_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2025.zip (accessed 2026-10-11)
- [bb-data-Q42025] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-11)
- [bb-terms] Backblaze Hard Drive Test Data page and use terms. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-11)
- [bb-2025] Backblaze Drive Stats for 2025 (published annual table: 115,638,676 drive days, 4,317 failures, 1.36%). https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/ (accessed 2026-10-11)
- [garwood] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3-4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-11)

### Backblaze hard drive models, yearly AFR and exposure, 2022 to 2025

URL: https://hesela.dev/datasets/backblaze-2022-2025-model-history/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2022-2025-model-history.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2022-2025-model-history.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2022-2025-model-history.svg
Rows: 88
License: Derivative table computed from the Backblaze Drive Stats daily files for 2022 to 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 88-row aggregate, not the daily SMART archive, and that archive is not for sale.

Yearly drive days, failures and annualized failure rate with exact 95% Poisson intervals for the 22 Backblaze hard-drive models that had at least 100,000 drive days in every year from 2022 to 2025, computed from the raw daily Drive Stats files (sixteen quarterly zips). Sample: 88 model-years. Some models stay flat, such as the Toshiba MG07ACA14TA at 1.01% to 1.15%, while others move a lot: HGST HUH721212ALN604 went from 0.74% in 2022 to 5.64% in 2024, and Toshiba MG08ACA16TEY from 1.58% in 2024 to 6.30% in 2025. One fleet, and the file does not show why a rate moved.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- model (string): Model string exactly as in the Backblaze daily files.
- capacity_tb (integer): Nominal capacity in terabytes, round(capacity_bytes / 1e12).
- year (integer): Calendar year, 2022 to 2025 (all four quarterly files of the year).
- drive_days (integer): Daily rows (drive days) of the model in the year. This is the exposure.
- drives_dec31 (integer): Rows of the model in the last daily file of Q4 of that year (drives present on December 31).
- failures (integer): Rows with failure = 1 in the year.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here, with 365 days in every year.
- afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval, in percent.
- afr_high95 (number): Upper bound of the same interval, in percent.

Citations:
- [bb-data-Q12022] Backblaze Hard Drive Test Data, data_Q1_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2022.zip (accessed 2026-10-11)
- [bb-data-Q22022] Backblaze Hard Drive Test Data, data_Q2_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2022.zip (accessed 2026-10-11)
- [bb-data-Q32022] Backblaze Hard Drive Test Data, data_Q3_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2022.zip (accessed 2026-10-11)
- [bb-data-Q42022] Backblaze Hard Drive Test Data, data_Q4_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2022.zip (accessed 2026-10-11)
- [bb-data-Q12023] Backblaze Hard Drive Test Data, data_Q1_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2023.zip (accessed 2026-10-11)
- [bb-data-Q22023] Backblaze Hard Drive Test Data, data_Q2_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2023.zip (accessed 2026-10-11)
- [bb-data-Q32023] Backblaze Hard Drive Test Data, data_Q3_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2023.zip (accessed 2026-10-11)
- [bb-data-Q42023] Backblaze Hard Drive Test Data, data_Q4_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2023.zip (accessed 2026-10-11)
- [bb-data-Q12024] Backblaze Hard Drive Test Data, data_Q1_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2024.zip (accessed 2026-10-11)
- [bb-data-Q22024] Backblaze Hard Drive Test Data, data_Q2_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2024.zip (accessed 2026-10-11)
- [bb-data-Q32024] Backblaze Hard Drive Test Data, data_Q3_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2024.zip (accessed 2026-10-11)
- [bb-data-Q42024] Backblaze Hard Drive Test Data, data_Q4_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2024.zip (accessed 2026-10-11)
- [bb-data-Q12025] Backblaze Hard Drive Test Data, data_Q1_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2025.zip (accessed 2026-10-11)
- [bb-data-Q22025] Backblaze Hard Drive Test Data, data_Q2_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2025.zip (accessed 2026-10-11)
- [bb-data-Q32025] Backblaze Hard Drive Test Data, data_Q3_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2025.zip (accessed 2026-10-11)
- [bb-data-Q42025] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-11)
- [bb-terms] Backblaze Hard Drive Test Data page and use terms. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-11)
- [bb-2025] Backblaze Drive Stats for 2025 (published annual table: 115,638,676 drive days, 4,317 failures, 1.36%). https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/ (accessed 2026-10-11)
- [garwood] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3-4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-11)

### Backblaze hard drive models added and retired, 2022 to 2025

URL: https://hesela.dev/datasets/backblaze-2022-2025-model-turnover/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2022-2025-model-turnover.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2022-2025-model-turnover.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2022-2025-model-turnover.svg
Rows: 66
License: Derivative table computed from the Backblaze Drive Stats daily files for 2022 to 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 66-row aggregate, not the daily SMART archive, and that archive is not for sale.

Which hard-drive models Backblaze added or retired between January 1, 2022 and December 31, 2025, from the raw daily Drive Stats files (sixteen quarterly zips). Sample: all 66 model strings of drives of 3 TB or more, 388,670,883 drive days and 16,051 failures, with drives on December 31 of each year, exposure, failures and the 2022 to 2025 AFR with exact 95% Poisson intervals per model. Models added after 2022 Q1 held 79,349 of the 334,844 drives on December 31, 2025. One fleet, and model strings are used as they appear in the files.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- model (string): Model string exactly as in the Backblaze daily files. Strings that differ only in spacing, such as "WDC WUH721414ALE6L4" with two spaces, are separate rows.
- capacity_tb (integer): Nominal capacity in terabytes, round(capacity_bytes / 1e12).
- status (string): continuous: seen in 2022 Q1 and in 2025 Q4. added: first seen after 2022 Q1 and still there in 2025 Q4. retired: seen in 2022 Q1 and not in 2025 Q4. added and retired: neither.
- first_quarter (string): First of the 16 quarters (2022 Q1 to 2025 Q4) in which the model has any drive day.
- last_quarter (string): Last of the 16 quarters in which the model has any drive day.
- quarters_present (integer): Number of the 16 quarters with any drive day.
- drives_end_2022 (integer): Rows of the model in the last daily file of Q4 2022, that is drives present on December 31, 2022.
- drives_end_2023 (integer): Same for December 31, 2023.
- drives_end_2024 (integer): Same for December 31, 2024.
- drives_end_2025 (integer): Same for December 31, 2025.
- drive_days (integer): Daily rows of the model from 2022-01-01 to 2025-12-31. This is the exposure.
- failures (integer): Rows with failure = 1 in the window.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals, over the whole window. Computed here.
- afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval, in percent.
- afr_high95 (number): Upper bound of the same interval, in percent.

Citations:
- [bb-data-Q12022] Backblaze Hard Drive Test Data, data_Q1_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2022.zip (accessed 2026-10-11)
- [bb-data-Q22022] Backblaze Hard Drive Test Data, data_Q2_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2022.zip (accessed 2026-10-11)
- [bb-data-Q32022] Backblaze Hard Drive Test Data, data_Q3_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2022.zip (accessed 2026-10-11)
- [bb-data-Q42022] Backblaze Hard Drive Test Data, data_Q4_2022.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2022.zip (accessed 2026-10-11)
- [bb-data-Q12023] Backblaze Hard Drive Test Data, data_Q1_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2023.zip (accessed 2026-10-11)
- [bb-data-Q22023] Backblaze Hard Drive Test Data, data_Q2_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2023.zip (accessed 2026-10-11)
- [bb-data-Q32023] Backblaze Hard Drive Test Data, data_Q3_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2023.zip (accessed 2026-10-11)
- [bb-data-Q42023] Backblaze Hard Drive Test Data, data_Q4_2023.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2023.zip (accessed 2026-10-11)
- [bb-data-Q12024] Backblaze Hard Drive Test Data, data_Q1_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2024.zip (accessed 2026-10-11)
- [bb-data-Q22024] Backblaze Hard Drive Test Data, data_Q2_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2024.zip (accessed 2026-10-11)
- [bb-data-Q32024] Backblaze Hard Drive Test Data, data_Q3_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2024.zip (accessed 2026-10-11)
- [bb-data-Q42024] Backblaze Hard Drive Test Data, data_Q4_2024.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2024.zip (accessed 2026-10-11)
- [bb-data-Q12025] Backblaze Hard Drive Test Data, data_Q1_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2025.zip (accessed 2026-10-11)
- [bb-data-Q22025] Backblaze Hard Drive Test Data, data_Q2_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2025.zip (accessed 2026-10-11)
- [bb-data-Q32025] Backblaze Hard Drive Test Data, data_Q3_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2025.zip (accessed 2026-10-11)
- [bb-data-Q42025] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-11)
- [bb-terms] Backblaze Hard Drive Test Data page and use terms. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-11)
- [bb-2025] Backblaze Drive Stats for 2025 (published annual table: 115,638,676 drive days, 4,317 failures, 1.36%). https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/ (accessed 2026-10-11)
- [garwood] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3-4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-11)

### Backblaze SSD models in 2025: drive days, failures and the AFR upper bound

URL: https://hesela.dev/datasets/backblaze-2025-boot-ssd-afr/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2025-boot-ssd-afr.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2025-boot-ssd-afr.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2025-boot-ssd-afr.svg
Rows: 21
License: Derivative table computed from the Backblaze Drive Stats daily files for 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 21-row aggregate, not the daily SMART archive, and that archive is not for sale.

Exposure and failures for the SSD models in Backblaze's raw Drive Stats files for 2025 (January 1 to December 31, 2025). Sample: 20 SSD models, 1,075,258 drive days, 2,972 drives on December 31, and zero failures. With no failures the file gives each model's exact 95% upper bound on the annualized failure rate: 0.13% for all SSD models pooled, and 0.34% to 4.30% for the models with 10,000 or more drive days. One fleet, mostly boot drives, so it does not describe SSDs in general.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- model (string): Model string exactly as in the Backblaze daily files. SSD models were picked by name patterns listed in the step 1 script. The Dell BOSS virtual disk is not included.
- capacity_gb (integer): Nominal capacity in gigabytes (capacity_bytes / 1e9, rounded). Empty on the pooled row.
- drive_days_q1 (integer): Daily rows of the model from 2025-01-01 to 2025-03-31.
- drive_days_q2 (integer): Daily rows from 2025-04-01 to 2025-06-30.
- drive_days_q3 (integer): Daily rows from 2025-07-01 to 2025-09-30.
- drive_days_q4 (integer): Daily rows from 2025-10-01 to 2025-12-31.
- drive_days (integer): Sum of the four quarters. This is the exposure.
- drives_2025_12_31 (integer): Drives in the 2025-12-31 file that have a power-on-hours value.
- median_age_years_2025_12_31 (number): Median smart_9_raw of those drives divided by 8766, two decimals. Power-on hours as reported.
- failures (integer): Rows with failure = 1 in 2025. Zero for every model.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here.
- afr_high95 (number): Upper end of the exact two-sided 95% Poisson interval for zero failures, -ln(0.025) / (drive_days / 365) * 100, two decimals. The lower end is 0.

Citations:
- [bb-data-Q1] Backblaze Hard Drive Test Data, data_Q1_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2025.zip (accessed 2026-10-10)
- [bb-data-Q2] Backblaze Hard Drive Test Data, data_Q2_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2025.zip (accessed 2026-10-10)
- [bb-data-Q3] Backblaze Hard Drive Test Data, data_Q3_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2025.zip (accessed 2026-10-10)
- [bb-data-Q4] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-10)
- [bb-terms] Backblaze Hard Drive Test Data page and use terms. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-10)

### Backblaze hard drive AFR by month and capacity class, 2025

URL: https://hesela.dev/datasets/backblaze-2025-monthly-afr/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2025-monthly-afr.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2025-monthly-afr.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2025-monthly-afr.svg
Rows: 52
License: Derivative table computed from the Backblaze Drive Stats daily files for 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 52-row aggregate, not the daily SMART archive, and that archive is not for sale.

Month-by-month annualized failure rate of Backblaze's hard drives in 2025 (January 1 to December 31), computed from the raw daily Drive Stats files with exact 95% Poisson intervals, for all drives of 3 TB or more and for three capacity classes. Sample: 115,936,784 drive days and 4,327 failures, a 1.36% pooled AFR that matches Backblaze's published annual figure. Monthly AFR runs from 0.54% in December to 1.72% in September. One fleet, one year, and the file does not say why months differ.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- month (string): Calendar month 2025-01 to 2025-12, or "2025 total" for the sum of the twelve months.
- size_class (string): All hard drives of 3 TB or more, or a nominal capacity class: up to 12 TB, 14 to 16 TB, 20 TB and above (round(capacity_bytes / 1e12)).
- drive_days (integer): Daily rows (drive days) of the class in the month. This is the exposure.
- failures (integer): Rows with failure = 1 in the month.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here, with 365 days in every month.
- afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval, in percent.
- afr_high95 (number): Upper bound of the same interval, in percent.

Citations:
- [bb-data-Q1] Backblaze Hard Drive Test Data, data_Q1_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q1_2025.zip (accessed 2026-10-11)
- [bb-data-Q2] Backblaze Hard Drive Test Data, data_Q2_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2025.zip (accessed 2026-10-11)
- [bb-data-Q3] Backblaze Hard Drive Test Data, data_Q3_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q3_2025.zip (accessed 2026-10-11)
- [bb-data-Q4] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily CSV files). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-11)
- [bb-terms] Backblaze Hard Drive Test Data page and use terms. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-11)
- [bb-2025] Backblaze Drive Stats for 2025 (published annual table: 115,638,676 drive days, 4,317 failures, 1.36%). https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/ (accessed 2026-10-11)
- [garwood] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3-4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-11)

### Backblaze pooled AFR by manufacturer and capacity, Q1 versus Q2 2026

URL: https://hesela.dev/datasets/backblaze-2026-afr-by-vendor-and-capacity/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2026-afr-by-vendor-and-capacity.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2026-afr-by-vendor-and-capacity.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2026-afr-by-vendor-and-capacity.svg
Rows: 14
License: Derivative table transcribed from Backblaze Drive Stats reports for Q1 2026 and Q2 2026. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a small derived aggregate of that comparison, not Backblaze's daily SMART archive, and that archive is not for sale.

Pooled annualized failure rates for Backblaze's published Q1 2026 (January 1 to March 31) and Q2 2026 (April 1 to June 30) model tables, grouped by manufacturer (4 groups) and nominal capacity (10 groups). Pooled over 33 model rows: 30,203,180 drive days and 1,030 failures in Q1, 31,553,350 drive days and 1,498 failures in Q2. Pooled AFR rose in all four manufacturer groups and in 8 of 9 capacity groups present in both quarters. Vendor claim data from Backblaze's own fleet; the grouping and pooling are computed here.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- group_type (string): Grouping used: manufacturer or capacity_tb.
- group (string): Manufacturer label as published (HGST, Seagate, Toshiba, WDC) or nominal capacity in terabytes.
- q1_models (integer): Number of model rows in the group in the Q1 2026 (January 1 to March 31) table. Empty if the group has no rows that quarter.
- q1_drive_count (integer): Sum of the published quarter-end drive counts of those models, Q1 2026 (January 1 to March 31).
- q1_drive_days (integer): Sum of published drive days, Q1 2026 (January 1 to March 31).
- q1_failures (integer): Sum of published failures, Q1 2026 (January 1 to March 31).
- q1_afr_percent (number): Pooled AFR in percent, computed as failures / drive days * 365 * 100 and rounded to two decimals, Q1 2026 (January 1 to March 31). Not a published figure.
- q2_models (integer): Number of model rows in the group in the Q2 2026 (April 1 to June 30) table. Empty if the group has no rows that quarter.
- q2_drive_count (integer): Sum of the published quarter-end drive counts of those models, Q2 2026 (April 1 to June 30).
- q2_drive_days (integer): Sum of published drive days, Q2 2026 (April 1 to June 30).
- q2_failures (integer): Sum of published failures, Q2 2026 (April 1 to June 30).
- q2_afr_percent (number): Pooled AFR in percent, computed as failures / drive days * 365 * 100 and rounded to two decimals, Q2 2026 (April 1 to June 30). Not a published figure.

Citations:
- [bb-q1-2026-report] Backblaze Drive Stats for Q1 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q1-2026/ (accessed 2026-10-09)
- [bb-q2-2026-report] Backblaze Drive Stats for Q2 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/ (accessed 2026-10-09)
- [bb-drive-stats-data] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-09)
- [hesela-afr-shift] Backblaze drive model AFR, Q1 versus Q2 2026 (model rows used here). https://hesela.dev/datasets/backblaze-q1-q2-2026-afr-shift/ (accessed 2026-10-10)

### Backblaze model AFR with 95% intervals, Q1 and Q2 2026

URL: https://hesela.dev/datasets/backblaze-2026-afr-confidence-intervals/
Download (CSV): https://hesela.dev/data/datasets/backblaze-2026-afr-confidence-intervals.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-2026-afr-confidence-intervals.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-2026-afr-confidence-intervals.svg
Rows: 33
License: Derivative table transcribed from Backblaze Drive Stats reports for Q1 2026 and Q2 2026. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a small derived table with computed intervals, not Backblaze's daily SMART archive, and that archive is not for sale.

Published Q1 and Q2 2026 Backblaze AFRs for 33 hard-drive models, each with an exact 95% Poisson interval computed from the published failures and drive days. Sample: Q1 2026 (January 1 to March 31) 30,203,180 drive days and 1,030 failures; Q2 2026 (April 1 to June 30) 31,553,350 drive days and 1,498 failures. Of 31 models in both quarters, the intervals do not overlap for 4 and overlap for 27. The Poisson assumption is a modelling choice made here, not something Backblaze publishes.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- mfg (string): Manufacturer label as published by Backblaze.
- model (string): Drive model identifier as published.
- size_tb (integer): Nominal capacity in terabytes as published.
- q1_drive_days (integer): Drive days in Q1 2026 (January 1 to March 31), as published. Empty if the model is not in that table.
- q1_failures (integer): Failures in Q1 2026 (January 1 to March 31), as published.
- q1_afr_percent (number): AFR in percent for Q1 2026 (January 1 to March 31), copied as published.
- q1_afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval for the AFR, in percent, computed here from failures and drive days, Q1 2026 (January 1 to March 31).
- q1_afr_high95 (number): Upper bound of the same interval, in percent, Q1 2026 (January 1 to March 31).
- q2_drive_days (integer): Drive days in Q2 2026 (April 1 to June 30), as published. Empty if the model is not in that table.
- q2_failures (integer): Failures in Q2 2026 (April 1 to June 30), as published.
- q2_afr_percent (number): AFR in percent for Q2 2026 (April 1 to June 30), copied as published.
- q2_afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval for the AFR, in percent, computed here from failures and drive days, Q2 2026 (April 1 to June 30).
- q2_afr_high95 (number): Upper bound of the same interval, in percent, Q2 2026 (April 1 to June 30).
- intervals_overlap (string): yes if the Q1 and Q2 95% intervals share any value, no if they do not. Empty if the model is missing from either quarter. Computed here.

Citations:
- [bb-q1-2026-report] Backblaze Drive Stats for Q1 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q1-2026/ (accessed 2026-10-09)
- [bb-q2-2026-report] Backblaze Drive Stats for Q2 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/ (accessed 2026-10-09)
- [bb-drive-stats-data] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-09)
- [garwood-1936] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3/4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-10)

### Backblaze Q2 2026 hard drive AFR by model

URL: https://hesela.dev/datasets/backblaze-hdd-afr/
Download (CSV): https://hesela.dev/data/datasets/backblaze-hdd-afr.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-hdd-afr.json
Rows: 31
License: Derivative table transcribed from Backblaze Drive Stats for Q2 2026. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. The Q2 2026 report restates citation, sole responsibility, and the ban on selling the data, and does not restate the derivative-works permission. This CSV is not Backblaze's daily SMART archive, and that archive is not for sale.

Backblaze's published Q2 2026 quarterly hard-drive annualized failure rate was 1.73% (vendor claim): 1,498 failures across 31,553,350 drive days on 354,415 drives. This download is the 31-model table for April 1 through June 30, 2026 inclusive (drive count above 100 and drive days above 10,000), not the daily SMART archive.

Source accessed: 2026-10-07

Source: https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- mfg (string): Manufacturer label as published by Backblaze: HGST, Seagate, Toshiba, or WDC.
- model (string): Drive model identifier as published.
- size_tb (integer): Nominal capacity in terabytes as published.
- drive_count (integer): Drives of this model in the quarterly cohort.
- avg_age_months (number): Average age in months as published. Not an input to the AFR column.
- drive_days (integer): Drive-days observed for this model in the quarter.
- failures (integer): Drives that failed in the quarter, as published.
- afr_percent (number): Annualized failure rate in percent, copied as published rather than refit.

Citations:
- [bb-q2-2026-report] Backblaze Drive Stats for Q2 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/ (accessed 2026-10-07)
- [bb-drive-stats-data] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-07)
- [bb-q2-2026-press] Backblaze Publishes Q2 2026 Drive Stats: Quarterly Failure Rate Rises to 1.73%. https://ir.backblaze.com/news/news-details/2026/Backblaze-Publishes-Q2-2026-Drive-Stats-Quarterly-Failure-Rate-Rises-to-1-73/default.aspx (accessed 2026-10-07)
- [bb-q2-2026-zip] Drive Stats daily SMART archive for 2026 Q2 (data_Q2_2026.zip). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q2_2026.zip (accessed 2026-10-07)

### Backblaze drive model AFR, Q1 versus Q2 2026

URL: https://hesela.dev/datasets/backblaze-q1-q2-2026-afr-shift/
Download (CSV): https://hesela.dev/data/datasets/backblaze-q1-q2-2026-afr-shift.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-q1-q2-2026-afr-shift.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-q1-q2-2026-afr-shift.svg
Rows: 33
License: Derivative table transcribed from Backblaze Drive Stats reports for Q1 2026 and Q2 2026. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a small derived comparison, not Backblaze's daily SMART archive, and that archive is not for sale.

Side-by-side published annualized failure rates for 33 hard-drive models in Backblaze's Q1 2026 (January 1 to March 31) and Q2 2026 (April 1 to June 30) Drive Stats model tables. 31 models appear in both. Fleet AFR in the published totals rows rose from 1.24% (1,030 failures, 30,203,180 drive days) to 1.73% (1,498 failures, 31,553,350 drive days). Vendor claim; Backblaze's own fleet, not an industry sample.

Source accessed: 2026-10-09

Source: https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- mfg (string): Manufacturer label as published by Backblaze: HGST, Seagate, Toshiba, or WDC.
- model (string): Drive model identifier as published.
- size_tb (integer): Nominal capacity in terabytes as published.
- q1_drive_count (integer): Drives of this model in the Q1 2026 table. Empty if the model is not in that table.
- q1_drive_days (integer): Drive days observed in Q1 2026 (January 1 to March 31, 2026). Empty if not in the table.
- q1_failures (integer): Failures in Q1 2026 as published. Empty if not in the table.
- q1_afr_percent (number): Q1 2026 AFR in percent, copied as published, not refit. Empty if not in the table.
- q2_drive_count (integer): Drives of this model in the Q2 2026 table. Empty if the model is not in that table.
- q2_drive_days (integer): Drive days observed in Q2 2026 (April 1 to June 30, 2026). Empty if not in the table.
- q2_failures (integer): Failures in Q2 2026 as published. Empty if not in the table.
- q2_afr_percent (number): Q2 2026 AFR in percent, copied as published, not refit. Empty if not in the table.

Citations:
- [bb-q1-2026-report] Backblaze Drive Stats for Q1 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q1-2026/ (accessed 2026-10-09)
- [bb-q2-2026-report] Backblaze Drive Stats for Q2 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/ (accessed 2026-10-09)
- [bb-drive-stats-data] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-09)

### Backblaze AFR by drive power-on age, Q4 2025

URL: https://hesela.dev/datasets/backblaze-q4-2025-afr-by-age/
Download (CSV): https://hesela.dev/data/datasets/backblaze-q4-2025-afr-by-age.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-q4-2025-afr-by-age.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-q4-2025-afr-by-age.svg
Rows: 32
License: Derivative table computed from the Backblaze Drive Stats daily files for Q4 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 32-row aggregate, not the daily SMART archive, and that archive is not for sale.

Annualized failure rate by drive power-on age, computed from Backblaze's raw daily Drive Stats files for Q4 2025 (October 1 to December 31, 2025) with the exposure counted per age bucket. Sample: hard drives of 3 TB or more with a power-on-hours value, 30,575,671 drive days and 926 failures (1.11% pooled AFR). The rate is 0.36% at 1 to under 2 years, 2.59% at 6 to under 7 and 7.08% at 7 to under 8, from 44 failures in 0.7% of drive days. Association only, one fleet and one quarter, with model mix that changes by age.

Correction: Capacity labels corrected on 2026-10-11: the former '20 TB and above' group includes 18 TB drives and is now 'over 16 TB'; '14 to 16 TB' is now 'over 12 to 16 TB'. Same group membership, counts, AFRs and intervals. Re-extracted from all 92 daily files.

Updated: 2026-10-11

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Audit: https://hesela.dev/data/methods/backblaze-q4-2025-age-audit.json

Generator: https://hesela.dev/data/methods/audit_backblaze_age.py

Columns:
- size_class (string): All hard drives of 3 TB or more, or a nominal capacity class: up to 12 TB, over 12 to 16 TB, over 16 TB.
- age_years (string): Power-on age bucket in years, from smart_9_raw hours divided by 8766 on each drive day. The last bucket is 8 or more.
- drive_days (integer): Daily rows (drive days) of the class that fell in the bucket between 2025-10-01 and 2025-12-31. This is the exposure.
- share_of_class_drive_days_percent (number): The bucket's share of the class's drive days with an age, one decimal.
- failures (integer): Rows with failure = 1 in the bucket.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here.
- afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval, in percent. Computed here.
- afr_high95 (number): Upper bound of the same interval, in percent.

Limits:
- Missing SMART 9 excludes 106 drive-days and 19 of 945 capacity-eligible failure rows; missingness is not shown to be random.
- Age buckets are descriptive, not lifetime estimates; age, model mix and retirement selection are not separated.
- Capacity >=3e12 is the inherited selection rule, not a universal classifier of HDDs versus SSDs. SMART counters are not validated against vendor encodings or reset histories.

Citations:
- [bb-data] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily files, 92 CSVs). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-10)
- [bb-page] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-10)
- [garwood-1936] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3/4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-10)

### Power-on age of failed drives versus the fleet, Backblaze Q4 2025

URL: https://hesela.dev/datasets/backblaze-q4-2025-drive-age-at-failure/
Download (CSV): https://hesela.dev/data/datasets/backblaze-q4-2025-drive-age-at-failure.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-q4-2025-drive-age-at-failure.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-q4-2025-drive-age-at-failure.svg
Rows: 35
License: Derivative table computed from the Backblaze Drive Stats daily files for Q4 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 35-row aggregate, not the daily SMART archive, and that archive is not for sale.

Per-model power-on age of the hard drives that failed in Backblaze's Q4 2025 (October 1 to December 31, 2025) against the age of the fleet on December 31, computed from Backblaze's raw daily Drive Stats files. Sample: 34 hard-drive models, 334,392 drives on December 31, 30,534,025 drive days, 943 failures (1.13% pooled AFR), of which 924 carry a power-on-hours value. Pooled medians are 4.65 years for failed drives and 3.38 years for the fleet, but within single models the two medians are close.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- model (string): Drive model string as it appears in the daily files. The last row is the pooled row for all included models.
- size_tb (integer): Largest capacity_bytes seen for the model, in terabytes (10^12 bytes), rounded. Empty on the pooled row.
- drives_2025_12_31 (integer): Rows for the model in the 2025-12-31 daily file, the quarter-end drive count.
- drive_days (integer): Daily rows for the model from 2025-10-01 to 2025-12-31.
- failures (integer): Rows with failure = 1 in that period.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here from the daily files.
- failures_with_age (integer): Failed drives whose smart_9_raw (power-on hours) was filled in on the failure day. Always at most failures.
- fleet_median_age_years (number): Median smart_9_raw on 2025-12-31 over the model's drives, divided by 8766 hours per year.
- failed_median_age_years (number): Median smart_9_raw of the failed drives on their failure day, divided by 8766. Empty when no failed drive has the value.

Citations:
- [bb-data] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily files, 92 CSVs). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-10)
- [bb-page] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-10)
- [bb-2025] Backblaze Drive Stats for 2025 (published Q4 2025 AFRs used as a cross-check). https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/ (accessed 2026-10-10)

### Which models make up the 6+ year AFR buckets, Backblaze Q4 2025

URL: https://hesela.dev/datasets/backblaze-q4-2025-old-age-by-model/
Download (CSV): https://hesela.dev/data/datasets/backblaze-q4-2025-old-age-by-model.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-q4-2025-old-age-by-model.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-q4-2025-old-age-by-model.svg
Rows: 36
License: Derivative table computed from the Backblaze Drive Stats daily files for Q4 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 36-row aggregate, not the daily SMART archive, and that archive is not for sale.

Splits the older power-on age buckets (6 to under 7, 7 to under 8, 8 or more years) of Backblaze's Q4 2025 fleet (October 1 to December 31, 2025) by drive model, from the raw daily Drive Stats files. Sample: hard drives of 3 TB or more with a power-on-hours value; 1,424,836, 226,691 and 1,383,760 drive days in the three buckets, with 101, 44 and 70 failures. In the 7 to under 8 year bucket (7.08% AFR), two models hold 27 plus 13 of the 44 failures: HGST HUH728080ALE600 and Toshiba MG07ACA14TA. Association only, one fleet and one quarter.

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Columns:
- age_years (string): Power-on age bucket in years, from smart_9_raw hours divided by 8766 on each drive day: 6 to under 7, 7 to under 8, or 8 or more.
- model (string): Drive model string as it appears in the daily files, or the ALL row that closes each bucket and equals the sum of its model rows.
- drives (integer): Distinct serial numbers of the model seen in the bucket between 2025-10-01 and 2025-12-31. A drive that crosses a bucket boundary in the quarter counts in both buckets; the ALL row adds the model rows.
- drive_days (integer): Daily rows of the model that fell in the bucket. This is the exposure.
- share_of_bucket_drive_days_percent (number): The model's share of the bucket's drive days, one decimal.
- failures (integer): Rows with failure = 1 for the model in the bucket.
- share_of_bucket_failures_percent (number): The model's share of the bucket's failures, one decimal.
- afr_percent (number): failures / drive_days * 365 * 100, two decimals. Computed here.
- afr_low95 (number): Lower bound of the exact two-sided 95% Poisson (Garwood) interval, in percent.
- afr_high95 (number): Upper bound of the same interval, in percent. Very wide for models with few drive days.

Citations:
- [bb-data] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily files, 92 CSVs). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-10)
- [bb-page] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-10)
- [garwood-1936] Garwood, F. (1936). Fiducial limits for the Poisson distribution. Biometrika 28(3/4), 437-442. https://doi.org/10.1093/biomet/28.3-4.437 (accessed 2026-10-10)
- [hesela-afr-by-age] Backblaze AFR by drive power-on age, Q4 2025 (the buckets split here). https://hesela.dev/datasets/backblaze-q4-2025-afr-by-age/ (accessed 2026-10-10)

### SMART 5, 187, 188, 197 and 198 in failed versus surviving drives, Backblaze Q4 2025

URL: https://hesela.dev/datasets/backblaze-q4-2025-smart-at-failure/
Download (CSV): https://hesela.dev/data/datasets/backblaze-q4-2025-smart-at-failure.csv
Metadata (JSON): https://hesela.dev/data/datasets/backblaze-q4-2025-smart-at-failure.json
Chart (SVG): https://hesela.dev/data/datasets/backblaze-q4-2025-smart-at-failure.svg
Rows: 24
License: Derivative table computed from the Backblaze Drive Stats daily files for Q4 2025. Cite Backblaze if you use it. You are solely responsible for how you use it. Backblaze's dataset page allows sale of derivative works and forbids selling the Drive Stats data itself. This CSV is a 24-row aggregate, not the daily SMART archive, and that archive is not for sale.

Failure-day SMART association in Backblaze Q4 2025: 690 of 926 failed drives reporting at least one selected attribute have a positive raw value (74.5%), versus 8.1% in the December 31 nonfailed snapshot. Of 236 failed rows with reported values but no positive, 66 have all five zero and 170 have partial coverage; another 19 have none. Capacity filter: at least 3 TB. Not a prediction test.

Updated: 2026-10-11

Source accessed: 2026-10-10

Source: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

License URL: https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Audit: https://hesela.dev/data/methods/backblaze-q4-2025-smart-audit.json

Coverage data: https://hesela.dev/data/methods/backblaze-q4-2025-smart-coverage.csv

Columns:
- manufacturer (string): All, or the manufacturer group inferred from the model string: Seagate (ST...), HGST (HGST, HUH, HMS), Toshiba, WDC (WDC, WUH, WD).
- attribute (string): smart_5_raw (reallocated sectors), smart_187_raw (reported uncorrectable errors), smart_188_raw (command timeout), smart_197_raw (current pending sectors), smart_198_raw (offline uncorrectable), or any_of_five (at least one of the five above zero).
- failed_drives (integer): Unique drives with failure=1 in Q4 2025, capacity_bytes >= 3e12; one failure-day row each. Capacity is a selection rule, not a universal media classifier.
- failed_filled (integer): Failed rows with a finite nonnegative attribute value. For any_of_five, at least one of the five valid values, not necessarily all five.
- failed_above_zero (integer): Failed drives with the raw value above zero.
- failed_percent (number): failed_above_zero / failed_filled * 100, one decimal. Computed here.
- failed_percent_low95 (number): Lower bound of the 95% Wilson score interval for failed_percent. Computed here.
- failed_percent_high95 (number): Upper bound of the same interval.
- survivor_drives (integer): Drives of 3 TB or more in the 2025-12-31 file with failure = 0.
- survivor_filled (integer): December 31 nonfailed rows with a finite nonnegative attribute value; any_of_five requires at least one valid value.
- survivor_above_zero (integer): Survivors with the raw value above zero.
- survivor_percent (number): survivor_above_zero / survivor_filled * 100, one decimal. Computed here.

Limits:
- Failure-day association is not advance prediction, recall, precision or a deployment false-alarm rate.
- Complete-case selection for these five attributes retains only Seagate reporting drives in this quarter; model mix changes with coverage rules.
- Partial records with all observed values zero do not establish that all five attributes are zero; no-value records are distinct.
- The December 31 snapshot excludes other nonfailed drives that left earlier; cohort timing, model mix and replacement policy limit comparison.
- Wilson intervals describe binomial-model uncertainty conditional on available values, not bias from missingness or operational selection.

Citations:
- [bb-data] Backblaze Hard Drive Test Data, data_Q4_2025.zip (daily files, 92 CSVs). https://f001.backblazeb2.com/file/Backblaze-Hard-Drive-Data/data_Q4_2025.zip (accessed 2026-10-10)
- [bb-page] Hard Drive Reliability & Test Data. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (accessed 2026-10-10)
- [wilson-1927] Wilson, E. B. (1927). Probable inference, the law of succession, and statistical inference. Journal of the American Statistical Association 22(158), 209-212. https://doi.org/10.1080/01621459.1927.10502953 (accessed 2026-10-10)
- [audit] Hesela: verified Q4 2025 SMART coverage counts, input/code hashes and limitations. https://hesela.dev/data/methods/backblaze-q4-2025-smart-audit.json (accessed 2026-10-11)
- [hesela] Hesela: SMART zeros, missing attributes and failure-day selection. https://hesela.com/analyses/smart-missing-values-not-zero/ (accessed 2026-10-11)

### Bloom filter allocation: equal memory, different lookup cost

URL: https://hesela.dev/datasets/bloom-filter-allocation/
Download (CSV): https://hesela.dev/data/datasets/bloom-filter-allocation.csv
Metadata (JSON): https://hesela.dev/data/datasets/bloom-filter-allocation.json
Rows: 42
License: CC0-1.0 for Hesela's original implementation and computed rows; cited papers and documentation retain their own rights.

Fourteen deterministic cases compare equal bits per entry with optimized allocation across three invented runs. Expected probes, not measured latency.

Evidence type: analytical-model-evaluation

Method: Assume every absent point lookup considers every run, all filter/index metadata is resident, and each false positive costs one equally weighted probe. Use p=exp(-b*ln(2)^2). Minimize sum(p_i) subject to sum(n_i*b_i)=budget and b_i>=0 using KKT conditions and 100-step bounded bisection. Run sizes: 10000, 100000, 1000000 entries. Average budgets: 0, 1, 2, 4, 8, 10, 12 bits per stored entry. No random sample or device I/O.

Published: 2026-10-12

Updated: 2026-10-14

Generated: 2026-10-14T13:29:01.265Z

Source: https://cs-people.bu.edu/mathan/publications/sigmod17-dayan.pdf

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/bloom-filters-lsm-read-cost/

Code: https://hesela.dev/research/bloom-allocation.mjs

Columns:
- policy (string): equal: identical bits per entry; optimized: minimum sum of model false-positive probabilities.
- budgetBitsPerEntry (number): Total filter budget / total stored entries, bits per entry; not bytes.
- totalEntries (number): Sum of entries across the three invented runs, not distinct live database keys.
- budgetBits (number): Total ideal filter bit budget, excluding headers, indexes and caches.
- run (number): Run number, ascending by entry count; not a RocksDB level identifier.
- entries (number): Assumed stored entry count in this run.
- bitsPerEntry (number): Continuous ideal filter bits / this run's entries; not rounded hash counts.
- filterBits (number): Continuous allocated bits for this run; need not be an integer.
- falsePositiveProbability (number): Probability for a key absent from this run under exp(-bitsPerEntry * ln(2)^2); 1 means no filter.
- expectedProbes (number): Sum of run false-positive probabilities for one absent point lookup, repeated for each case's three rows.

Limits:
- Invented run sizes and deterministic arithmetic, not a measured database population.
- Continuous ideal approximation with optimal hash count, not exact finite Bloom-filter probabilities.
- Only absent point queries: no successful-query early exit, ranges, cache misses, CPU or compaction cost.
- No L0 overlap or key-range pruning model; no claimed RocksDB setting or latency improvement.
- Zero bits means the run is always probed, not that an empty Bloom filter rejects all keys.
- No confidence interval applies to these computed examples; model applicability remains uncertain.
- This is not a replication of Monkey's implementation, experimental workloads or full design-space optimizer.

Citations:
- [bloom] Burton H. Bloom. Space/time trade-offs in hash coding with allowable errors. Communications of the ACM 13(7), 422-426 (1970), method 2. DOI: 10.1145/362686.362692.. https://courses.cs.washington.edu/courses/csep521/21wi/readings/bloom_cacm.pdf (accessed 2026-10-12)
- [monkey] Niv Dayan, Manos Athanassoulis and Stratos Idreos. Monkey: Optimal Navigable Key-Value Store. SIGMOD 2017, 79-94; sections 2, 4.1 and 5. DOI: 10.1145/3035918.3064054.. https://cs-people.bu.edu/mathan/publications/sigmod17-dayan.pdf (accessed 2026-10-12)
- [rocks-bloom] RocksDB project. RocksDB Bloom Filter: statistics, full filters and implementation trade-offs. Documentation reviewed 12 October 2026.. https://github.com/facebook/rocksdb/wiki/RocksDB-Bloom-Filter (accessed 2026-10-12)

### Azure disk-error prediction caught 36.5% of faulty disks at a 0.1% false-positive rate, and random cross-validation said 91.6%

URL: https://hesela.dev/datasets/cloud-disk-error-prediction/
Download (CSV): https://hesela.dev/data/datasets/cloud-disk-error-prediction.csv
Metadata (JSON): https://hesela.dev/data/datasets/cloud-disk-error-prediction.json
Rows: 15
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Xu et al., USENIX ATC 2018, built a disk-error predictor for Azure. At a 0.1% false-positive rate it caught 36.50% of faulty disks on one test set (29.67% to 41.09% across three), against 15.51% to 30.51% for SVM and random forest baselines on SMART data; a random split gave 91.64% on the same data. Rows from Backblaze (2016) show the SMART gap in another fleet.

Updated: 2026-10-13

Source accessed: 2026-10-10

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/conference/atc18/atc18-xu-yong.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/cloud-disk-error-prediction/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/cloud-disk-error-prediction/

Rights evidence (primary publication and listed publisher policy only):
- Improving Service Availability of Cloud Systems by Predicting Disk Error, Xu et al., USENIX ATC 2018 (USENIX PDF, pages 481 to 494). https://www.usenix.org/system/files/conference/atc18/atc18-xu-yong.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- One cloud system of one company, one month of training and one month of testing.
- Labels come from engineers' root-cause analyses and some disks return from repair.
- Only TPR, FPR, and AUC are reported; precision is not.
- The 63000 minutes saved is the authors' own average after deployment.
- The Backblaze rows measure SMART warnings in another fleet, not this model.

Citations:
- [xu-atc18-pdf] Improving Service Availability of Cloud Systems by Predicting Disk Error, Xu et al., USENIX ATC 2018 (USENIX PDF, pages 481 to 494). https://www.usenix.org/system/files/conference/atc18/atc18-xu-yong.pdf (accessed 2026-10-10)
- [backblaze-smart-2016] What SMART Stats Tell Us About Hard Drives, Backblaze, 6 October 2016. https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ (accessed 2026-10-10)

### Datacenter failure tickets are not failed-device counts

URL: https://hesela.dev/datasets/datacenter-hardware-failure-tickets/
Download (CSV): https://hesela.dev/data/datasets/datacenter-hardware-failure-tickets.csv
Metadata (JSON): https://hesela.dev/data/datasets/datacenter-hardware-failure-tickets.json
Rows: 14
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Fourteen reported-value rows from three historical studies, with distinct counting units and source qualifiers. The separate synthetic burst example illustrates adjacent-gap grouping, not an empirical failure rate.

Method: Primary-source review, not a reanalysis of private logs. Wang et al. classify failure operation tickets; Schroeder and Gibson count component replacements; Ford et al. group node-unavailability events. Their populations and outcomes differ. The separate runnable example uses deliberately chosen timestamps and does not reproduce any fleet result.

Correction: Review, 16 October 2026: retained all reported numeric values after checking the full PDFs; clarified counting units, operator-response endpoints and chained failure bursts. The 2%/99% concentration remains source-reported, not independently reconstructed.

Updated: 2026-10-16

Source accessed: 2026-10-16

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://netman.aiops.org/~peidan/ANM2019/9.EventPrediction/ReadingList/2017DSN_What%20Can%20We%20Learn%20from%20Four%20Years%20of%20Data%20Center%20Hardware%20Failures.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/datacenter-hardware-failure-tickets/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/datacenter-hardware-failure-tickets/

Audit: https://hesela.dev/research/failure-bursts/examples.json

Code: https://hesela.dev/research/failure-bursts/generate.py

Rights evidence (primary publication and listed publisher policy only):
- What Can We Learn from Four Years of Data Center Hardware Failures?, Wang, Zhang, and Xu, IEEE/IFIP DSN 2017, pages 25 to 36 (author PDF, copy on the netman.aiops.org reading list). https://netman.aiops.org/~peidan/ANM2018/11.EventPrediction/ReadingList/2017DSN_What%20Can%20We%20Learn%20from%20Four%20Years%20of%20Data%20Center%20Hardware%20Failures.pdf (checked 2026-10-13). The inspected reading-list copy has no explicit reuse notice in its extracted text. No standalone license for the derived CSV or study data was established.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- One company's fleet and ticketing rules; the company is not named in the paper.
- A failure is a ticket and includes SMART and error warnings, so shares are not failure rates per drive.
- The 42.2 day figure is operator response time, not repair time.
- The cause of the November 2015 batch is not known.
- The cross-check rows are other systems with other definitions.
- The 2%/99% statement is source-reported in Wang section III-D, not independently reconstructed from logs.
- Ford's window compares adjacent starts; it is not a fixed total burst duration. Timing alone does not prove common cause.

Citations:
- [wang-dsn17-pdf] Wang, Zhang and Xu. What Can We Learn from Four Years of Data Center Hardware Failures? DSN 2017, sections II, III-D, V and VI (reading-list PDF).. https://netman.aiops.org/~peidan/ANM2019/9.EventPrediction/ReadingList/2017DSN_What%20Can%20We%20Learn%20from%20Four%20Years%20of%20Data%20Center%20Hardware%20Failures.pdf (accessed 2026-10-16)
- [schroeder-fast07-pdf] Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?, Schroeder and Gibson, FAST 2007 (USENIX PDF, section 4 on other components). https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder.pdf (accessed 2026-10-16)
- [ford-osdi10-pdf] Availability in Globally Distributed Storage Systems, Ford et al., USENIX OSDI 2010 (USENIX PDF). https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf (accessed 2026-10-16)

### Deduplication restore locality: a six-request trace

URL: https://hesela.dev/datasets/dedup-restore-locality/
Download (CSV): https://hesela.dev/data/datasets/dedup-restore-locality.csv
Metadata (JSON): https://hesela.dev/data/datasets/dedup-restore-locality.json
Rows: 6
License: CC0-1.0 for Hesela's original model and rows. Cited publications retain their own rights.

Six synthetic cold-cache LRU scenarios isolate repeated container reads from unused fetched bytes. No device timings or real backup records.

Evidence type: synthetic-deterministic-trace

Method: Process each six-request trace in order from an empty LRU container cache. A miss fetches one full 65536-byte container; a hit refreshes recency. Each request emits 4096 bytes. Count misses and multiply by container size, then divide by total emitted bytes. Three cache capacities are evaluated for each of two placements.

Published: 2026-10-11

Updated: 2026-10-14

Generated: 2026-10-14T13:29:09.102Z

Source: https://hesela.com/analyses/deduplication-restore-fragmentation/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/deduplication-restore-fragmentation/

Code: https://hesela.dev/research/dedup-restore.mjs

Columns:
- layout (string): Synthetic placement: clustered or interleaved, not a measured system.
- trace (string): Container IDs for requests to six distinct chunks in fixed logical order.
- cacheContainers (number): LRU cache capacity in whole containers; cache starts empty.
- cacheBytes (number): Capacity in bytes, excluding cache metadata.
- requests (number): Requested equal-size chunks; six in each example.
- uniqueContainers (number): Distinct containers referenced, not total reads.
- chunkBytes (number): Bytes restored per request; illustrative fixed-size input.
- containerBytes (number): Bytes fetched per miss; full-container read assumption.
- containerReads (number): Cache misses, each causing one whole-container fetch.
- cacheHits (number): Requests served from the modeled container cache.
- restoredBytes (number): Total logical output bytes; denominator of read amplification.
- fetchedBytes (number): Total fetched container bytes; includes unused data and rereads.
- readAmplification (number): Fetched bytes / restored bytes, dimensionless; not a time ratio.

Limits:
- Illustrative synthetic inputs, not a sampled population or a reproduction of either paper.
- No timing, compression, metadata I/O, range reads, prefetching, concurrent streams, output writes or operating-system cache.
- The two placements hold content, request order and container inventory constant; there is no simulated ingest or deduplication ratio.
- No implementation of container capping, forward assembly, history-aware rewriting or garbage collection.
- Confidence intervals and observation periods do not apply to deterministic arithmetic.

Citations:
- [lillibridge2013] Mark Lillibridge, Kave Eshghi and Deepavali Bhagwat. Improving Restore Speed for Backup Systems that Use Inline Chunk-Based Deduplication. USENIX FAST 2013, pp. 183-197; sections 2-4.. https://www.usenix.org/system/files/conference/fast13/fast13-final124.pdf (accessed 2026-10-11)
- [fu2014] Min Fu, Dan Feng, Yu Hua, Xubin He, Zuoning Chen, Wen Xia, Fangting Huang and Qing Liu. Accelerating Restore and Garbage Collection in Deduplication-based Backup Systems via Exploiting Historical Information. USENIX ATC 2014, pp. 181-192; sections 3-6.. https://www.usenix.org/system/files/conference/atc14/atc14-paper-fu_min.pdf (accessed 2026-10-11)

### In an 18-month Berkeley study of 368 disks, 7 data disks failed against 13 enclosure backplane failures; disks were 90% of parts but about 4% of errors

URL: https://hesela.dev/datasets/disk-error-behavior-1990s-storage-prototype/
Download (CSV): https://hesela.dev/data/datasets/disk-error-behavior-1990s-storage-prototype.csv
Metadata (JSON): https://hesela.dev/data/datasets/disk-error-behavior-1990s-storage-prototype.json
Rows: 15
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Talagala and Patterson (UC Berkeley, 1999) logged 18 months of a prototype with 368 SCSI data disks. 7 data disks failed (1.9%), against 13 of 46 enclosures, and disks were about 90% of parts but around 4% of errors. Cross-check rows come from Schroeder and Gibson (FAST 2007) and Ford et al. (OSDI 2010).

Updated: 2026-10-13

Source accessed: 2026-10-11

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1999/CSD-99-1042.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/disk-error-behavior-1990s-storage-prototype/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/disk-error-behavior-1990s-storage-prototype/

Rights evidence (primary publication and listed publisher policy only):
- An Analysis of Error Behavior in a Large Storage System, Talagala and Patterson, UC Berkeley technical report UCB/CSD-99-1042, February 1999 (author PDF, 18 pages). https://www2.eecs.berkeley.edu/Pubs/TechRpts/1999/CSD-99-1042.pdf (checked 2026-10-13). The official Berkeley report was retrieved and inspected. No explicit reuse notice was found in its extracted text; this is not evidence of permission or a prohibition.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- One small prototype built from 1996 parts; says little about modern drives.
- Counts are small: 7 disk failures and 1 failure for several other types.
- Failures are replacements over 18 months, not annual rates.
- The error table and the text disagree slightly on data disk errors and machine counts.
- The cross-check rows are other systems with other definitions.

Citations:
- [talagala-ucb99-pdf] An Analysis of Error Behavior in a Large Storage System, Talagala and Patterson, UC Berkeley technical report UCB/CSD-99-1042, February 1999 (author PDF, 18 pages). https://www2.eecs.berkeley.edu/Pubs/TechRpts/1999/CSD-99-1042.pdf (accessed 2026-10-11)
- [schroeder-fast07-pdf] Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?, Schroeder and Gibson, FAST 2007 (USENIX PDF, section 4). https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder.pdf (accessed 2026-10-11)
- [ford-osdi10-pdf] Availability in Globally Distributed Storage Systems, Ford et al., USENIX OSDI 2010 (USENIX PDF, section 3). https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf (accessed 2026-10-11)

### Enterprise SSD replacements ran at 0.22% a year across 1.4 million NetApp drives, with firmware the biggest swing

URL: https://hesela.dev/datasets/enterprise-ssd-replacements/
Download (CSV): https://hesela.dev/data/datasets/enterprise-ssd-replacements.csv
Metadata (JSON): https://hesela.dev/data/datasets/enterprise-ssd-replacements.json
Rows: 17
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Maneas et al., FAST 2020, mined NetApp support messages for about 1.4 million SSDs (3 manufacturers, 18 models, January 2017 to May 2019). The average annual replacement rate was 0.22%, from 0.07% to nearly 1.2% by model. Early firmware versions of some families were replaced 2 to more than 10 times as often as later ones, and the chance of another replacement within a week in a RAID group was 9.39% against 0.0504% in a random week. Cross-check rows come from Google (FAST 2016).

Updated: 2026-10-13

Source accessed: 2026-10-10

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/fast20-maneas.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/enterprise-ssd-replacements/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/enterprise-ssd-replacements/

Rights evidence (primary publication and listed publisher policy only):
- A Study of SSD Reliability in Large Scale Enterprise Storage Deployments, Maneas et al., FAST 2020 (USENIX PDF). https://www.usenix.org/system/files/fast20-maneas.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Replacement is an operator action and about a third of replacements are predictive, so the annual replacement rate is not a data-loss rate.
- The reason is missing for 40% of replacement events and the paper assumes the rest are spread in proportion.
- The firmware effect is within one family; the cause is an explanation in the paper, not a measurement.
- Rated life used is a truncated integer, so many drives show 0.
- The Google rows measure the share of drives removed in 4 years, not an annual rate, and cover another fleet.

Citations:
- [maneas-fast20-pdf] A Study of SSD Reliability in Large Scale Enterprise Storage Deployments, Maneas et al., FAST 2020 (USENIX PDF). https://www.usenix.org/system/files/fast20-maneas.pdf (accessed 2026-10-10)
- [schroeder-fast16-pdf] Flash Reliability in Production: The Expected and the Unexpected, Schroeder, Lagisetty, and Merchant, FAST 2016 (USENIX PDF). https://www.usenix.org/system/files/conference/fast16/fast16-papers-schroeder.pdf (accessed 2026-10-10)

### Perseus fail-slow drives: reported counts and benchmark limits

URL: https://hesela.dev/datasets/fail-slow-drives-software-scheduling/
Download (CSV): https://hesela.dev/data/datasets/fail-slow-drives-software-scheduling.csv
Metadata (JSON): https://hesela.dev/data/datasets/fail-slow-drives-software-scheduling.json
Rows: 15
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Reported Perseus drive counts and benchmark scores, with population limits and a separate comparison to operator incident reports.

Updated: 2026-10-15

Source accessed: 2026-10-15

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/fast23-lu.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/fail-slow-drives-software-scheduling/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/fail-slow-drives-software-scheduling/

Rights evidence (primary publication and listed publisher policy only):
- Perseus: A Fail-Slow Detection Framework for Cloud Storage Systems, Lu, Xu, Zhang, Zhu, Zhu, Wang, Zhu, Xue, Shu, Li, and Wu, USENIX FAST 2023 (USENIX PDF, sections 5 and 6). https://www.usenix.org/system/files/fast23-lu.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- One operator's drives and scheduling software.
- 216 of the 252 software-caused drives were in two open-channel SSD clusters, so the 80% share is concentrated.
- Only 15 of the 63 hardware cases have a vendor root cause.
- Precision and recall are on a benchmark built mostly from drives the detector flagged.
- The cross-check rows are incident reports from other institutions with other definitions.
- The node-wise reference can miss a shared-path slowdown affecting all peers; matching drive models and similar workloads are assumptions, not guarantees for other fleets.

Citations:
- [lu-fast23-pdf] Perseus: A Fail-Slow Detection Framework for Cloud Storage Systems, Lu, Xu, Zhang, Zhu, Zhu, Wang, Zhu, Xue, Shu, Li, and Wu, USENIX FAST 2023 (USENIX PDF, sections 5 and 6). https://www.usenix.org/system/files/fast23-lu.pdf (accessed 2026-10-15)
- [gunawi-fast18-pdf] Fail-Slow at Scale: Evidence of Hardware Performance Faults in Large Production Systems, Gunawi et al., USENIX FAST 2018 (USENIX PDF, sections 2 to 3). https://www.usenix.org/system/files/conference/fast18/fast18-gunawi.pdf (accessed 2026-10-11)

### IOPS, bandwidth, queue depth and latency: a worked table from Little's law

URL: https://hesela.dev/datasets/fio-iops-bandwidth-latency-calc/
Download (CSV): https://hesela.dev/data/datasets/fio-iops-bandwidth-latency-calc.csv
Metadata (JSON): https://hesela.dev/data/datasets/fio-iops-bandwidth-latency-calc.json
Chart (SVG): https://hesela.dev/data/datasets/fio-iops-bandwidth-latency-calc.svg
Rows: 100
License: The table is arithmetic computed here from Little's law and from the unit conventions of fio. No third-party data or documentation text is copied. Reuse is fine with attribution to this site.

How IOPS, bandwidth, queue depth and mean latency relate, as a worked table of 100 rows: four block sizes (4 KiB to 1 MiB), queue depths of 1 to 128 and mean latencies of 100 microseconds to 10 milliseconds. The rules are IOPS = queue depth / mean latency (Little's law) and bandwidth = IOPS x block size, in decimal MB/s and in MiB/s as fio prints them. Pure arithmetic, no measurement. For example, queue depth 1 at 100 microseconds is 10,000 IOPS and 40.96 MB/s at 4 KiB, and queue depth 32 at 1 millisecond is 32,000 IOPS.

Source accessed: 2026-10-10

Source: https://en.wikipedia.org/wiki/Little%27s_law

License URL: https://en.wikipedia.org/wiki/Wikipedia:Copyrights

Columns:
- block_size_bytes (integer): I/O size in bytes: 4096, 16384, 131072, 1048576. These are the values fio reads from bs=4k, 16k, 128k, 1m with its default kb_base of 1024.
- queue_depth (integer): I/Os in flight, the fio iodepth option, and L in Little's law.
- mean_latency_us (integer): Mean time one I/O spends in the system, in microseconds, and W in Little's law.
- iops (integer): queue_depth / mean_latency_us * 1e6, I/Os per second. Computed here.
- bandwidth_mb_s (number): iops * block_size_bytes / 1e6, two decimals, decimal megabytes per second (the kB/s style fio prints).
- bandwidth_mib_s (number): iops * block_size_bytes / 2^20, two decimals, mebibytes per second (the KiB/s style fio prints).

Citations:
- [little] Little's law, Wikipedia: L = lambda W and the response-time example. https://en.wikipedia.org/wiki/Little%27s_law (accessed 2026-10-11)
- [fio] fio documentation: iodepth, blocksize, kb_base and unit prefixes. https://fio.readthedocs.io/en/latest/fio_doc.html (accessed 2026-10-11)

### SSD mapping-table footprint: exact byte accounting

URL: https://hesela.dev/datasets/ftl-mapping-footprint/
Download (CSV): https://hesela.dev/data/datasets/ftl-mapping-footprint.csv
Metadata (JSON): https://hesela.dev/data/datasets/ftl-mapping-footprint.json
Rows: 12
License: CC0-1.0 for Hesela's original code and computed rows. Source publications retain their own rights.

Twelve constructed flat-map cases distinguish TB from TiB, mapping granularity from host sectors, and cache address coverage from cached user data.

Evidence type: deterministic-arithmetic-examples

Method: C in {10^12, 2^40, 4*2^40} logical bytes; G in {4096,16384} bytes per mapping; E in {4,8} bytes per entry; cache payload B=64*2^20 bytes. Entries=ceil(C/G), full map=entries*E, cached entries=min(floor(B/E),entries), cached address span=min(C,cached entries*G). These are selected assumptions, not measured firmware layouts.

Published: 2026-10-12

Updated: 2026-10-12

Generated: 2026-10-12T05:26:49.492Z

Source: https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal.pdf

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/ssd-mapping-cache-hmb/

Code: https://hesela.dev/research/ftl-mapping.mjs

Columns:
- capacityBytes (number): Assumed logical capacity in bytes; decimal TB and binary TiB remain distinct.
- mappingUnitBytes (number): Logical bytes represented by one mapping; not necessarily a host sector or NAND page.
- entryBytes (number): Assumed flat-map entry payload in bytes; excludes cache tags and other metadata.
- cacheBytes (number): Assumed mapping-entry payload budget in bytes; not a measured HMB allocation.
- entryCount (number): Ceiling of logical capacity divided by mapping-unit size.
- fullMapBytes (number): Exact bytes in the flat mapping payload, excluding all ancillary structures.
- cachedEntries (number): Whole entries that fit, capped at the full map entry count.
- cachedLogicalBytes (number): Maximum logical address span represented by those entries, capped at logical capacity; not cached user data.

Limits:
- All inputs are constructed; no devices, firmware, address traces or HMB allocations were measured.
- Entry payload omits tags, replacement state, directories, validity bits, reverse maps, alignment and recovery metadata.
- No compression or hierarchical/block/hybrid mapping. Four-byte and eight-byte widths are assumptions, not universal encodings.
- Coverage is not hit ratio, RAM recommendation, throughput, latency or power-loss protection.
- Mapping-unit size is independent of host sector and NAND page size in this model.
- Exact integer arithmetic is deterministic; no statistical confidence interval applies.

Citations:
- [agrawal] Nitin Agrawal, Vijayan Prabhakaran, Ted Wobber, John D. Davis, Mark Manasse and Rina Panigrahy. Design Tradeoffs for SSD Performance. USENIX ATC 2008, pp. 57-70, sections 3.1, 3.4 and 4.. https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal.pdf (accessed 2026-10-12)

### HDD rotational latency by spindle speed

URL: https://hesela.dev/datasets/hdd-rotational-latency-calc/
Download (CSV): https://hesela.dev/data/datasets/hdd-rotational-latency-calc.csv
Metadata (JSON): https://hesela.dev/data/datasets/hdd-rotational-latency-calc.json
Chart (SVG): https://hesela.dev/data/datasets/hdd-rotational-latency-calc.svg
Rows: 6
License: CC0-1.0 for the generated rows, which are arithmetic. The cited article keeps its own rights and no text from it is copied.

Maximum and average rotational latency of a hard disk drive for six spindle speeds from 3,600 to 15,000 rpm, computed as 60 / rpm and half of that, and checked against the values printed in the cited Wikipedia article. At 7,200 rpm one revolution takes 8.33 ms and the average wait is 4.17 ms, and at 15,000 rpm they are 4.00 ms and 2.00 ms. Arithmetic from a definition, no measurements and no seek times.

Evidence type: arithmetic from a published definition; no measurements

Method: Rotational latency is the wait for the platter to bring the requested sector under the head. One revolution takes 60 / rpm seconds, which is the maximum wait, and the average wait is half of that. Each row applies those two formulas to one spindle speed, with 1 ms = 1/1000 s. The published column is the average printed in the cited article and is compared with the computed value. The IOPS column is 1000 divided by the average latency in ms and assumes rotation is the only delay. Seek time and data transfer time are separate terms of access time and are not in this table.

Published: 2026-10-12

Updated: 2026-10-12

Source: https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Code: https://hesela.dev/scripts/build-hdd-rotational-latency.py

Columns:
- rpm (integer): Spindle speed in revolutions per minute.
- revolutions_per_second (number): rpm / 60, two decimals.
- max_latency_ms (number): 60000 / rpm: milliseconds for one full revolution, the longest rotational wait, two decimals. Computed here.
- avg_latency_ms (number): max_latency_ms / 2: the average rotational latency, two decimals. Computed here.
- published_avg_latency_ms (number): Average rotational latency as printed in the cited Wikipedia article (table for 4,200 to 15,000 rpm, text for 3,600 rpm). The build checks it equals avg_latency_ms.
- rotation_only_iops_qd1 (number): 1000 / avg_latency_ms: I/Os per second if the average rotational wait were the only delay and one I/O were in flight. A ceiling that ignores seek and transfer, one decimal. Computed here.

Limits:
- Arithmetic from a definition, not measurements of any drive. No confidence interval applies.
- The average assumes the target sector is equally likely to be anywhere on the track. Real workloads, command queuing and drive firmware can change the wait.
- Access time also includes seek time and transfer time. The IOPS column is a ceiling if rotation were the only delay, not a prediction for any drive.
- Spindle speeds are the round values in the cited article. A drive can differ from its nominal speed.

Citations:
- [wp-hddperf] Hard disk drive performance characteristics, Wikipedia: rotational latency section and table of typical figures. https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics (accessed 2026-10-12)

### Key-value separation: cleaning-cost sensitivity

URL: https://hesela.dev/datasets/kv-separation-cleaning/
Download (CSV): https://hesela.dev/data/datasets/kv-separation-cleaning.csv
Metadata (JSON): https://hesela.dev/data/datasets/kv-separation-cleaning.json
Rows: 30
License: CC0-1.0 for Hesela's original code and computed rows. Source papers and documentation retain their own rights.

Thirty deterministic byte-accounting cases compare inline records with separated values, including relocation-driven index writes. Invented inputs, not engine measurements.

Evidence type: analytical-model-evaluation

Method: For equal-sized records, K=16 key bytes, P=16 reference bytes, H=8 log-header bytes; V in {16,128,1024} bytes; C in {4,10} tree output/input-byte factors; selected-region live fraction u in {0,0.25,0.5,0.75,0.9}. Inline=C(K+V); separated=[C(K+P)+K+V+H]/(1-u). Every relocated record induces an index update charged at C. Each ratio uses K+V new logical bytes as denominator. Original steady-state accounting example, not a fit to a paper.

Published: 2026-10-12

Updated: 2026-10-12

Generated: 2026-10-12T03:22:51.748Z

Source: https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/key-value-separation-cleaning-cost/

Code: https://hesela.dev/research/kv-cleaning.mjs

Columns:
- keyBytes (number): Assumed key size, bytes.
- valueBytes (number): Assumed value size, bytes.
- pointerBytes (number): Assumed reference size in the separated tree, bytes.
- logHeaderBytes (number): Assumed extra log header size, bytes.
- treeWriteFactor (number): Tree output bytes per inserted tree-record byte, including initial table writes and rewrites; same for both layouts.
- liveFraction (number): Live-byte fraction of the selected cleaning regions, not whole-database utilization.
- logicalBytes (number): New logical input bytes per key-value insertion: keyBytes + valueBytes.
- relocationFactor (number): Total append-plus-relocation multiplier: 1/(1-liveFraction).
- inlineBytes (number): Modeled tree bytes written per new logical insertion in the inline layout.
- separatedTreeBytes (number): Modeled tree bytes per new insertion including pointer updates for relocated records.
- valueLogBytes (number): Modeled log bytes per new insertion including all repeated copies and headers.
- separatedBytes (number): Separated tree plus log bytes per new insertion; excludes WAL and lower-layer writes.
- inlineWriteRatio (number): inlineBytes / logicalBytes, modeled byte ratio.
- separatedWriteRatio (number): separatedBytes / logicalBytes, modeled byte ratio.
- separatedToInline (number): separatedBytes / inlineBytes; below 1 means fewer modeled writes.
- breakEvenLiveFraction (number|null): Selected-region live fraction at equal cost; null/empty CSV means no nonnegative crossover (separation loses even at zero live bytes).

Limits:
- All inputs are invented and fixed; no devices, traces or database engines were measured.
- Assumes steady-state cleaning with equal record sizes and a fixed live fraction of selected regions.
- Identical C for inline, separated and relocation-driven tree updates isolates layout; a real smaller index can have a different C.
- No WAL, reads, compression, caching, coalescing, metadata beyond H/P, alignment, latency or NAND writes.
- Charging an index update for every relocation does not represent compaction-integrated BlobDB reclamation.
- u=1 cannot reclaim net space and is rejected; u is not storage utilization or a fill-limit recommendation.
- No statistical confidence intervals apply to these deterministic cases; applicability remains uncertain.

Citations:
- [wisckey] Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau and Remzi H. Arpaci-Dusseau. WiscKey: Separating Keys from Values in SSD-conscious Storage. USENIX FAST 2016, pp. 133-148, sections 3.2-3.3 and 4.. https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf (accessed 2026-10-12)
- [hashkv] Helen H. W. Chan, Yongkun Li, Patrick P. C. Lee and Yinlong Xu. HashKV: Enabling Efficient Updates in KV Storage via Hashing. USENIX ATC 2018, pp. 1007-1019, sections 3-4.. https://www.usenix.org/system/files/conference/atc18/atc18-chan.pdf (accessed 2026-10-12)
- [blobdb] RocksDB project. BlobDB: integrated implementation, garbage collection and configuration. Documentation reviewed 12 October 2026; page displays revision date 22 September 2022.. https://github.com/facebook/rocksdb/wiki/BlobDB (accessed 2026-10-12)

### Storage latency: synthetic arrival cohorts

URL: https://hesela.dev/datasets/latency-arrival-cohorts/
Download (CSV): https://hesela.dev/data/datasets/latency-arrival-cohorts.csv
Metadata (JSON): https://hesela.dev/data/datasets/latency-arrival-cohorts.json
Rows: 390
License: CC0-1.0 for Hesela's original synthetic records and calculation code; cited publications retain their own rights.

390 synthetic request records compare independent and completion-driven arrivals during one pause; downloadable timestamps reproduce the p99 calculation.

Evidence type: deterministic-synthetic-example

Method: One FIFO server; 2000 ms half-open arrival window; 10 ms open interval; 1 ms normal service; first service has a 100 ms added pause. Closed loop: one client with 9 ms think time after completion. All cohort requests drain; nearest-rank empirical quantiles.

Published: 2026-10-12

Updated: 2026-10-12

Generated: 2026-10-12T08:21:46.163Z

Source: https://hesela.com/analyses/storage-latency-coordinated-omission/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/storage-latency-coordinated-omission/

Code: https://hesela.dev/research/latency-measurement.mjs

Generator: https://hesela.dev/research/build-latency-measurement.mjs

Columns:
- mode (string): Separate synthetic scenario: open or closed; not a device label.
- index (integer): Zero-based request number within its scenario.
- arrivalMs (integer): Arrival and submission time in ms, inside [0, 2000).
- startMs (integer): FIFO service start in ms; may follow arrival because of queueing.
- completedMs (integer): Completion time in ms; all admitted requests are drained.
- queueMs (integer): startMs minus arrivalMs, in ms.
- responseMs (integer): completedMs minus arrivalMs, in ms; not device service time.

Limits:
- Not hardware data, not a fio run, not a paper reproduction, no device ranking or population inference. No random sampling, timeout, drop, retry, parallelism or cache. No confidence interval is applicable to these deterministic inputs.
- The open and closed cohorts have unequal loads and sizes. Do not pool them as one benchmark or infer a speedup.
- Each request is one row. Request indices restart for each mode; (mode, index) is the unique key.

Citations:
- [schroeder] Schroeder, Wierman and Harchol-Balter. Open Versus Closed: A Cautionary Tale. USENIX NSDI 2006. Workload-model context, not the source of these synthetic records.. https://www.usenix.org/legacy/events/nsdi06/tech/full_papers/schroeder/schroeder_html/index.html (accessed 2026-10-12)
- [hesela] Hesela: Storage latency: when the benchmark stops asking. https://hesela.com/analyses/storage-latency-coordinated-omission/ (accessed 2026-10-12)

### Linux names 4 blk-mq schedulers; I/O priority lists 8 RT levels for bfq and mq-deadline

URL: https://hesela.dev/datasets/linux-blk-mq-iosched/
Download (CSV): https://hesela.dev/data/datasets/linux-blk-mq-iosched.csv
Metadata (JSON): https://hesela.dev/data/datasets/linux-blk-mq-iosched.json
Rows: 8
License: Small derived table. The CSV and this JSON metadata are CC0-1.0. They are not a Linux kernel dump. The opened file block/mq-deadline.c begins with SPDX-License-Identifier: GPL-2.0 and prints Copyright (C) 2016 Jens Axboe. The opened kyber-iosched.rst, switching-sched.rst, and deadline-iosched.rst.txt files contain no SPDX-License-Identifier line, and the opened blk-mq and ioprio HTML pages do not show one, so GPL-2.0 is not read off those documents. COPYING at the kernel tree root states SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note and GNU General Public License version 2 only. Canonical full dumps, linked and not mirrored: mainline 7.3-rc7 (2026-10-12) https://git.kernel.org/torvalds/t/linux-7.3-rc7.tar.gz and stable 7.2.10 (2026-10-11) https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.2.10.tar.xz.

Linux switching-sched names 4 per-device blk-mq schedulers: mq-deadline, none, bfq, and kyber. I/O priority is named for bfq and mq-deadline, with 3 classes, 8 RT class-data levels, and best-effort levels 0 (highest) through 7 (lowest); none and kyber are not named. Kyber has 2 tunables, read and synchronous-write targets in nanoseconds, which are throttle targets rather than a measured latency. The none scheduler does not reorder, and completion order is not guaranteed. No throughput was measured.

Evidence type: kernel-documentation

Method: Rows are printed counts and levels from Linux kernel documentation and from block/mq-deadline.c, opened on 2026-10-12. They are not a trace of devices. switching-sched names four schedulers that can be written to /sys/block/DEV/queue/scheduler, and it shows the active name in brackets. The example cat line is for one device (sda). blk-mq.html says none places requests on whatever software queue the process is running on, without any reordering. The same page says neither the block layer nor the device protocols guarantee the order of completion of requests, and that higher layers such as the filesystem must handle that. That completion sentence is about the block layer, so this record uses it for none, mq-deadline, and kyber alike. It is not a measured completion order. ioprio.html says I/O-priority support is scheduler dependent and currently supported by bfq and mq-deadline. It names three classes, 8 RT class-data levels, and best-effort levels from 0 (highest) to 7 (lowest). none and kyber are not named. Kyber's only two tunables, read_lat_nsec and write_lat_nsec, are target latencies in nanoseconds. Kyber throttles requests in order to meet those targets. The opened kyber text prints no default number. Those targets are not a measured latency. The deadline tunables page defines read_expire as the current time plus read_expire in milliseconds, a start-service target, and defines write_expire the same way for writes. Requests are grouped into batches of one data direction and serviced in increasing sector order. Reads are preferred until writes_starved, whose unit is a number of dispatches, says to dispatch some writes. A fifo_batch value of 1 is the documented first-come first-served case, not a default in this table. Setting front_merges to 0 disables front-merge lookup. block/mq-deadline.c begins with SPDX-License-Identifier: GPL-2.0, sets elevator_name to mq-deadline and elevator_alias to deadline, points at Documentation/block/deadline-iosched.rst, maps IOPRIO_CLASS_RT, IOPRIO_CLASS_BE, and IOPRIO_CLASS_IDLE, and dispatches in priority order while higher-priority requests are pending. Expire defaults and sbitmap magnitudes from that file are not columns. Named fault: treating the bracketed scheduler name, or none's lack of reordering, as a completion-order guarantee. The signal is the bracket in /sys/block/DEV/queue/scheduler and the blk-mq sentence that none does not reorder onto the running process's software queue. The miss is the same page's statement that neither the block layer nor the device protocols guarantee completion order. Named fault: reading read_lat_nsec or write_lat_nsec as achieved latency. The signal is Kyber's two nanosecond throttle targets. The miss is that the opened text has no default and no measured latency. Named fault: applying I/O priority to every scheduler, or stopping at ioprio_set(2), which still says that as at kernel 2.6.17 the only such scheduler is CFQ. The signal is ioprio.html, which names bfq and mq-deadline, 8 RT levels, and best-effort levels 0 through 7. The miss is that none and kyber are not named, and the man page is not a cell in this table. Named fault: reading the four-name cat line as a fleet, a default, or a measured throughput. The signal is one example device. The miss is that bfq is named there and in the I/O-priority rows, while this table does not transcribe bfq's algorithm, and the phrase about improving throughput is not a measured rate.

Published: 2026-10-12

Updated: 2026-10-12

Source accessed: 2026-10-12

Source: https://www.kernel.org/doc/html/latest/block/blk-mq.html

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Columns:
- fact (string): Identifier of one documented quantity. Not a device-sample id.
- applies_to (string): Scheduler names the quantity applies to, separated by semicolons. bfq is included where switching-sched or ioprio names it. none and kyber are not given I/O-priority quantities.
- quantity (integer): Number printed on the cited page, or the count of names that page lists. Not a measured throughput, not an expire default, and not an sbitmap size. Best-effort quantities are priority-level indexes.
- unit (string): Unit of quantity. Kyber's row counts throttle targets whose printed latency unit is nanoseconds.
- citation_id (string): Id of the citation in this file. The note applies only to this row.
- note (string): Scope of the quantity. Present only for facts that are rows in this table. The io_nice formula is quoted and not evaluated.

Limits:
- Population is not applicable. This is not a sample of drives, hosts, or kernels. Sample size is not applicable. There is no observation date range. The scheduler pages were opened on 2026-10-12. On that date kernel.org listed mainline 7.3-rc7 (2026-10-12) and stable 7.2.10 (2026-10-11). Those are release labels, not a test window.
- The switching-sched cat line is an example for the device name sda. It is not a default scheduler, not a population, and not a date range. The sentence that selecting a scheduler can improve throughput is not a measured throughput. No IOPS, MB/s, or latency sample is in this table. The opened scheduler pages do not state a test machine or a drive model.
- bfq is one of the four names and is named for I/O priority. This table does not describe bfq's algorithm. Narrating behavior for only none, mq-deadline, and kyber drops bfq.
- none places requests on the software queue the process is running on without any reordering. That is not a completion-order guarantee. The completion sentence is about the block layer and the device protocols, and this record repeats it for none, mq-deadline, and kyber. It was not measured under each scheduler.
- Kyber read_lat_nsec and write_lat_nsec are target latencies in nanoseconds. The opened kyber page and rst print no default number and no achieved latency. A throttle target is not a measured latency.
- read_expire and write_expire are start-service targets in milliseconds. writes_starved is a number of dispatches. This table does not include compiled expire defaults from mq-deadline.c and does not include an sbitmap magnitude. The deadline page signature is Nov 11 2002, Jens Axboe. The ioprio page signature is March 11 2005, Jens Axboe. Those lines stay on those pages. They are not an observation period. The mq-deadline.c copyright line stays on that file.
- ioprio_set(2) still says that as at kernel 2.6.17 the only I/O-priority scheduler is CFQ, and its example cat line is noop anticipatory deadline [cfq]. That page is not the source of any quantity cell. The kernel ioprio page is. Vendor tuning guides are not cells.

Citations:
- [switching-sched] Switching Scheduler. https://www.kernel.org/doc/Documentation/block/switching-sched.rst (accessed 2026-10-12)
- [blk-mq] Multi-Queue Block IO Queueing Mechanism (blk-mq). https://www.kernel.org/doc/html/latest/block/blk-mq.html (accessed 2026-10-12)
- [ioprio] Block io priorities. https://www.kernel.org/doc/html/latest/block/ioprio.html (accessed 2026-10-12)
- [kyber-iosched] Kyber I/O scheduler tunables. https://www.kernel.org/doc/html/latest/block/kyber-iosched.html (accessed 2026-10-12)
- [kyber-rst] Kyber I/O scheduler tunables (kyber-iosched.rst). https://www.kernel.org/doc/html/latest/_sources/block/kyber-iosched.rst.txt (accessed 2026-10-12)
- [deadline-iosched] Deadline IO scheduler tunables. https://www.kernel.org/doc/html/latest/block/deadline-iosched.html (accessed 2026-10-12)
- [deadline-rst] Deadline IO scheduler tunables (deadline-iosched.rst.txt). https://www.kernel.org/doc/html/latest/_sources/block/deadline-iosched.rst.txt (accessed 2026-10-12)
- [mq-deadline-c] MQ Deadline I/O scheduler (block/mq-deadline.c). https://raw.githubusercontent.com/torvalds/linux/master/block/mq-deadline.c (accessed 2026-10-12)
- [kernel-archives] The Linux Kernel Archives. https://www.kernel.org/ (accessed 2026-10-12)
- [copying] Linux kernel COPYING. https://raw.githubusercontent.com/torvalds/linux/master/COPYING (accessed 2026-10-12)
- [ioprio-set-man] ioprio_set(2) Linux manual page. https://man7.org/linux/man-pages/man2/ioprio_set.2.html (accessed 2026-10-12)

### LRC repair costs: explicit denominators

URL: https://hesela.dev/datasets/lrc-repair-costs/
Download (CSV): https://hesela.dev/data/datasets/lrc-repair-costs.csv
Metadata (JSON): https://hesela.dev/data/datasets/lrc-repair-costs.json
Rows: 5
License: CC0-1.0 for Hesela's original model and generated rows. Cited publications retain their own rights.

Five deterministic whole-fragment examples distinguish data repair, all-fragment averages and parity-inclusive accounting. Not cluster measurements.

Evidence type: deterministic-accounting-model

Method: For each independent single-fragment loss, intact helpers supply whole equal-size fragments. Data and local parity cost k/localGroups reads in the modeled LRC topology; global parity costs k. RS costs k for any fragment. Sum costs across all positions, then divide by total fragments or by k. Uniform role distribution is assumed for node-level interpretation.

Published: 2026-10-11

Updated: 2026-10-11

Generated: 2026-10-11T18:21:35.531Z

Source: https://hesela.com/analyses/lrc-repair-costs-locality/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/lrc-repair-costs-locality/

Code: https://hesela.dev/research/lrc-repair-costs.mjs

Columns:
- label (string): RS uses data+global parity; LRC uses data+local parity+global parity. Not Ceph CLI notation.
- k (number): Number of payload data fragments per stripe.
- localGroups (number): Equal data groups, each with one local parity; zero for the RS baseline.
- globalParities (number): Number of global parity fragments.
- totalFragments (number): Total stored fragments: data plus all parity.
- shardBytes (number): Bytes per equal-size fragment. Illustrative input; 1 MiB = 1048576 bytes.
- storageFactor (number): Stored bytes divided by payload bytes; dimensionless, excluding metadata.
- dataReads (number): Complete helper fragments read for one data-fragment loss.
- localParityReads (number): Complete helper fragments read for one local-parity loss; zero means not applicable in RS.
- globalParityReads (number): Complete helper fragments read to recompute one global parity.
- sumIndependentReads (number): Sum of independent one-fragment repair read counts across every position; not simultaneous losses.
- averageReadsPerLostFragment (number): Sum of independent read counts divided by total stored fragments; uniform lost-role assumption.
- readsPerLostDataEquivalent (number): Same sum divided by payload data fragments; parity repairs amortized over payload.
- dataReadBytes (number): Helper bytes read for one data-fragment loss, excluding the reconstructed write.

Limits:
- Arithmetic examples, not experiments, event probabilities or confidence intervals.
- Not an encoder or decoder; no proof of a concrete finite-field construction or multi-erasure recovery.
- Equal overhead is not equal worst-case erasure tolerance. No current Azure or Ceph configuration is asserted.
- No partial-fragment schemes, shared reads, caching, retries, placement, compression, network topology or reconstructed-write traffic.
- These sums represent separate single-fragment failures across stripe roles, never simultaneous loss of all fragments.

Citations:
- [huang2012] Cheng Huang, Huseyin Simitci, Yikang Xu, Aaron Ogus, Brad Calder, Parikshit Gopalan, Jin Li and Sergey Yekhanin. Erasure Coding in Windows Azure Storage. USENIX ATC 2012, pp. 15-26; sections 2-3.. https://www.usenix.org/system/files/conference/atc12/atc12-final181_0.pdf (accessed 2026-10-11)
- [kolosov2018] Oleg Kolosov, Gala Yadgar, Matan Liram, Itzhak Tamo and Alexander Barg. On Fault Tolerance, Locality, and Optimality in Locally Repairable Codes. USENIX ATC 2018, pp. 865-877; sections 3, 5-6.. https://www.usenix.org/system/files/conference/atc18/atc18-kolosov.pdf (accessed 2026-10-11)
- [ceph-lrc] Ceph: Locally Repairable Erasure Code Plugin (development documentation; parameter names are implementation-specific).. https://docs.ceph.com/en/latest/rados/operations/erasure-code-lrc/ (accessed 2026-10-11)

### LTO generations: native and compressed capacity and throughput, LTO-1 to LTO-10

URL: https://hesela.dev/datasets/lto-generations-capacity/
Download (CSV): https://hesela.dev/data/datasets/lto-generations-capacity.csv
Metadata (JSON): https://hesela.dev/data/datasets/lto-generations-capacity.json
Chart (SVG): https://hesela.dev/data/datasets/lto-generations-capacity.svg
Rows: 11
License: The capacities, ratios, years and speeds are public facts about LTO Ultrium products as published on lto.org and in the Wikipedia article on Linear Tape-Open. No page text is copied. The hours and ratio columns are arithmetic done here. LTO and Ultrium are trademarks of Hewlett Packard Enterprise, IBM and Quantum. Reuse is fine with attribution to the sources named below. This is a small derived table.

Native and advertised compressed capacity, release year and maximum native throughput of LTO Ultrium generations 1 to 10 (11 rows, with the 30 TB and 40 TB LTO-10 cartridges), taken from the LTO Program pages for generations 8, 9 and 10 and the Wikipedia generations table for the rest, plus arithmetic: the hours to write one full cartridge at the maximum native rate and the capacity step from one generation to the next. Native capacity goes from 0.1 TB in LTO-1 to 40 TB in LTO-10, and the 40 TB cartridge takes 27.78 hours to fill at 400 MB/s. Two published speed figures do not match their own arithmetic and are flagged.

Source accessed: 2026-10-10

Source: https://www.lto.org/roadmap/

License URL: https://en.wikipedia.org/wiki/Wikipedia:Copyrights

Columns:
- generation (string): LTO Ultrium generation, LTO-1 to LTO-10. LTO-7 Type M (M8) is an alternate format of an LTO-7 cartridge on LTO-8 drives and is not listed.
- cartridge (string): Cartridge variant: standard, or for LTO-10 the 30 TB and 40 TB cartridges.
- release_year (integer): Year of first availability as given in the Wikipedia generations table (LTO-10 30 TB May 2025, 40 TB January 2026).
- native_capacity_tb (number): Native (uncompressed) capacity in decimal terabytes, as published.
- advertised_compressed_tb (number): Advertised capacity assuming the compression ratio in the next column, as published.
- compression_ratio (number): 2 for LTO-1 to LTO-5 and 2.5 from LTO-6, as published. The build checks native times ratio equals the advertised figure.
- max_native_mb_s (integer): Maximum native data rate in megabytes per second between drive and tape, decimal units.
- hours_to_fill_at_max_native (number): native_capacity_tb * 1e6 / max_native_mb_s / 3600, hours to write one full cartridge at the maximum native rate. Computed here.
- native_capacity_vs_previous (number): native_capacity_tb divided by the native capacity of the previous generation, two decimals. For both LTO-10 rows the previous generation is LTO-9. Computed here.
- source (string): Where the numbers in the row come from.
- note (string): Differences between the sources, without commas.

Citations:
- [lto10] LTO-10: LTO Generation 10 Technology, lto.org. https://www.lto.org/lto-10/ (accessed 2026-10-11)
- [lto9] LTO-9 page, lto.org. https://www.lto.org/lto-9/ (accessed 2026-10-11)
- [lto8] What is LTO-8 technology, lto.org. https://www.lto.org/lto-8/ (accessed 2026-10-11)
- [roadmap] Roadmap, lto.org. https://www.lto.org/roadmap/ (accessed 2026-10-11)
- [wp-lto] Linear Tape-Open, Wikipedia: generations table. https://en.wikipedia.org/wiki/Linear_Tape-Open (accessed 2026-10-11)

### Disk failure prediction: published scores and validation limits

URL: https://hesela.dev/datasets/ml-disk-failure-prediction/
Download (CSV): https://hesela.dev/data/datasets/ml-disk-failure-prediction.csv
Metadata (JSON): https://hesela.dev/data/datasets/ml-disk-failure-prediction.json
Rows: 13
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Lu et al. (FAST 2020) and two SMART-warning sources: 13 reported figures with units, bounds and validation limits. A source extract, not a model reproduction.

Method: The CSV transcribes ten reported Lu et al. (FAST 2020) figures and three SMART-warning rows from Backblaze (2016) and Google (FAST 2007). It is not a replication or a raw drive-level dataset. Section 4 uses random five-fold cross-validation, with an 80/20 tuning split inside training. This is not a demonstrated future-time holdout. The separate cross-site test trained on 62 sites and evaluated two unseen sites of the same operator (Section 5).

Correction: Clarified the validation protocol, missing-bound semantics and units. Removed numeric JSON-LD extrema that previously turned missing upper bounds into zero; row descriptions now retain both reported fields and source qualifiers. CSV fields and all 13 rows are unchanged.

Updated: 2026-10-13

Source accessed: 2026-10-10

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/fast20-lu.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/ml-disk-failure-prediction/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/ml-disk-failure-prediction/

Rights evidence (primary publication and listed publisher policy only):
- Making Disk Failure Predictions SMARTer!, Lu, Luo, Patel, Yao, Tiwari, and Shi, FAST 2020 (USENIX PDF, pages 151 to 167). https://www.usenix.org/system/files/fast20-lu.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower bound or lower end of a range; empty when not supplied. Consult note for strict inequalities; empty never means zero.
- value_high (number): Single reported value, upper bound or upper end of a range; empty for a lower-bound-only row. Consult note for qualifiers such as roughly, up to and less than.
- unit (string): Units include disks, days, MCC score, F-measure, percent of MCC, percent of failed or operational drives, and hours per training run.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Scores are the paper's own, from one operator, about 70 days, and a 10-day horizon.
- This extract does not establish the failed-drive count or a confusion matrix for each evaluation split; do not derive alert counts from MCC alone.
- The printed 2.6 million device hours cannot be reconciled from the disk count and observation window alone; complete observation of every drive is not established.
- Cross-site evaluation within one operator is not evidence of transfer to another operator or a future-time evaluation.
- The Backblaze and Google rows measure SMART warnings, not model performance.

Citations:
- [lu-fast20-pdf] Making Disk Failure Predictions SMARTer!, Lu, Luo, Patel, Yao, Tiwari, and Shi, FAST 2020 (USENIX PDF, pages 151 to 167). https://www.usenix.org/system/files/fast20-lu.pdf (accessed 2026-10-12)
- [backblaze-smart-2016] What SMART Stats Tell Us About Hard Drives, Backblaze, 6 October 2016. https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ (accessed 2026-10-10)
- [pinheiro-usenix-html] Failure Trends in a Large Disk Drive Population, Pinheiro, Weber, and Barroso, FAST 2007 (USENIX HTML proceedings). https://www.usenix.org/legacy/events/fast07/tech/full_papers/pinheiro/pinheiro_html/index.html (accessed 2026-10-09)

### Disk replacement rates and fleet event gaps: reported values

URL: https://hesela.dev/datasets/mttf-vs-field-replacement-rates/
Download (CSV): https://hesela.dev/data/datasets/mttf-vs-field-replacement-rates.csv
Metadata (JSON): https://hesela.dev/data/datasets/mttf-vs-field-replacement-rates.json
Rows: 18
License: Small derived table of figures printed in Schroeder and Gibson (FAST 2007), Pinheiro et al. (FAST 2007), and the Backblaze Q2 2026 Drive Stats post, with credit. Not a Creative Commons license. The USENIX proceedings page says rights to individual papers remain with the author or the author's employer. This file is not a copy of the papers, not the replacement logs, and not the Backblaze dataset. The Backblaze post asks that its raw Drive Stats data be cited and not resold, which this table does not redistribute.

An 18-row extraction of reported replacement rates and fleet event gaps, with source qualifiers and population limits; not a disk-lifetime dataset.

Method: Existing reported-value extraction, unchanged numerically. Interpret low/high cells with the row note; bounds may be strict or approximate. Cluster interarrival times are not individual disk lifetimes. No original logs were reanalysed.

Updated: 2026-10-12

Source accessed: 2026-10-09

Source: https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder_html/index.html

License URL: https://www.usenix.org/legacy/events/fast07/tech/schroeder.html

Companion analysis: https://hesela.com/analyses/mttf-vs-field-replacement-rates/

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- ARR is drives replaced per year, not confirmed failures. The paper cites a vendor figure that 43% of returned disks show no problem.
- ARR per data set cannot be recomputed from the paper's Table 1 because disk counts changed and logs hold other events.
- Time-between-replacement, correlation, and Weibull figures are HPC1 only.
- Several results appear only as charts in the paper and are not in this file.
- Google age groups mix drive models. Backblaze figures are a different era and drive mix, and the opened post does not define a failure. Neither tests the 3.4 times ratio.

Citations:
- [schroeder-usenix-html] Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?, Schroeder and Gibson, FAST 2007 (USENIX HTML proceedings). https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder_html/index.html (accessed 2026-10-09)
- [schroeder-usenix-abstract] Disk Failures in the Real World, USENIX FAST 2007 abstract page. https://www.usenix.org/legacy/events/fast07/tech/schroeder.html (accessed 2026-10-09)
- [pinheiro-usenix-html] Failure Trends in a Large Disk Drive Population, Pinheiro, Weber, and Barroso, FAST 2007 (USENIX HTML proceedings). https://www.usenix.org/legacy/events/fast07/tech/full_papers/pinheiro/pinheiro_html/index.html (accessed 2026-10-09)
- [backblaze-q2-2026] Backblaze Drive Stats for Q2 2026, published September 29, 2026. https://www.backblaze.com/blog/backblaze-drive-stats-for-q2-2026/ (accessed 2026-10-09)

### An example BCH code corrects raw bit error rates up to 1e-3, yet Google's field SSDs had median rates of 6e-10 to 3e-8, and raw rate did not predict uncorrectable errors

URL: https://hesela.dev/datasets/nand-ecc-bch-vs-ldpc/
Download (CSV): https://hesela.dev/data/datasets/nand-ecc-bch-vs-ldpc.csv
Metadata (JSON): https://hesela.dev/data/datasets/nand-ecc-bch-vs-ldpc.json
Rows: 13
License: Small derived table of figures printed in Zhao et al. (FAST 2013), Cai et al. (Proceedings of the IEEE 2017), and Schroeder et al. (FAST 2016), with credit. Not a Creative Commons license. The papers remain with their authors or publishers. This file is not a copy of the papers and not the data.

An example BCH code corrects raw bit error rates up to 1.0e-3 and soft LDPC up to 5.0e-3 (Cai et al., 2017; Zhao et al., FAST 2013 find about 3 times). Google's field median raw bit error rate was 5.8e-10 to over 3e-8, and 2 to 6 per 1,000 drive days had an uncorrectable error (Schroeder et al., FAST 2016).

Source accessed: 2026-10-11

Source: https://www.usenix.org/system/files/conference/fast16/fast16-papers-schroeder.pdf

License URL: https://www.usenix.org/system/files/conference/fast16/fast16-papers-schroeder.pdf

Companion analysis: https://hesela.com/analyses/nand-ecc-bch-vs-ldpc/

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Lower end of a printed range. Empty when the source prints a single value.
- value_high (number): Single printed value, or the upper end of a range. For 'over' or 'below' it is the stated bound.
- unit (string): Unit of the value columns: errors per bit, percent, times, bytes, probability, or per 1,000 drive days.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- The code limits are example codes, not the codes inside any specific drive.
- Field raw bit error rates are medians and percentiles of drive months; the tail inside a drive can be far higher.
- Cai et al. cite Zhao et al., so the design sources are not fully independent.
- The 3 times and 5 times gains use different codes and sensing levels.
- Uncorrectable errors in the field are counted per drive day, not per bit.

Citations:
- [zhao-fast13-pdf] LDPC-in-SSD: Making Advanced Error Correction Codes Work Effectively in Solid State Drives, Zhao, Zhao, Sun, Zhang, Zhang, and Zheng, USENIX FAST 2013, pages 243 to 256 (USENIX PDF). https://www.usenix.org/system/files/conference/fast13/fast13-final125.pdf (accessed 2026-10-11)
- [cai-procieee17-pdf] Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives, Cai, Ghose, Haratsch, Luo, and Mutlu, Proceedings of the IEEE, September 2017 (arXiv 1706.08642, section 6). https://arxiv.org/pdf/1706.08642 (accessed 2026-10-11)
- [schroeder-fast16-pdf] Flash Reliability in Production: The Expected and the Unexpected, Schroeder, Lagisetty, and Merchant, USENIX FAST 2016 (USENIX PDF, sections 3 and 4). https://www.usenix.org/system/files/conference/fast16/fast16-papers-schroeder.pdf (accessed 2026-10-11)

### NAND geometry and timing: historical source values

URL: https://hesela.dev/datasets/nand-erase-block-size-gc-cost/
Download (CSV): https://hesela.dev/data/datasets/nand-erase-block-size-gc-cost.csv
Metadata (JSON): https://hesela.dev/data/datasets/nand-erase-block-size-gc-cost.json
Rows: 19
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Selected chip parameters and simulation results from 2008-2018, with explicit source scope. These are not current SSD specifications or a controlled comparison of NAND generations.

Updated: 2026-10-15

Source accessed: 2026-10-15

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/conference/fast18/fast18-liu.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/nand-erase-block-size-gc-cost/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/nand-erase-block-size-gc-cost/

Rights evidence (primary publication and listed publisher policy only):
- PEN: Design and Evaluation of Partial-Erase for 3D NAND-Based High Density SSDs, Liu, Kotra, et al., USENIX FAST 2018 (USENIX PDF, sections 2 and 6). https://www.usenix.org/system/files/conference/fast18/fast18-liu.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Different years, chips and methods; no current-drive performance or endurance prediction.
- PEN's WAF result concerns its NFTL experiment; it is not a universal page-mapping claim.
- PEN's Table 1 includes erase timings. Access parameters and modeled partial-erase results have different provenance; see section 6.1.
- The two FTL-specific latency reductions are paired results, not a range of uncertainty.
- Grupp's per-bit trends describe the 2012 sample; they are not a present-day warranty conversion.
- The separate Hesela accounting JSON uses chosen inputs, not paper observations.

Citations:
- [agrawal-atc08-pdf] Design Tradeoffs for SSD Performance, Agrawal, Prabhakaran, Wobber, Davis, Manasse, and Panigrahy, USENIX ATC 2008 (USENIX PDF, section 2 and table 1). https://www.usenix.org/legacy/event/usenix08/tech/full_papers/agrawal/agrawal.pdf (accessed 2026-10-15)
- [liu-fast18-pdf] PEN: Design and Evaluation of Partial-Erase for 3D NAND-Based High Density SSDs, Liu, Kotra, et al., USENIX FAST 2018 (USENIX PDF, sections 2 and 6). https://www.usenix.org/system/files/conference/fast18/fast18-liu.pdf (accessed 2026-10-15)
- [grupp-fast12-pdf] Grupp, Davis and Swanson. The Bleak Future of NAND Flash Memory. FAST 2012, updated 8 February 2012, introduction and section 2.. https://www.usenix.org/system/files/conference/fast12/grupp2-8-12.pdf (accessed 2026-10-15)
- [cai-procieee17-pdf] Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives, Cai, Ghose, Haratsch, Luo, and Mutlu, Proceedings of the IEEE, September 2017 (arXiv 1706.08642, section 2). https://arxiv.org/pdf/1706.08642v3 (accessed 2026-10-15)

### Parity declustering: survivor-read accounting

URL: https://hesela.dev/datasets/parity-declustering-load/
Download (CSV): https://hesela.dev/data/datasets/parity-declustering-load.csv
Metadata (JSON): https://hesela.dev/data/datasets/parity-declustering-load.json
Rows: 21
License: CC0-1.0 for Hesela's original model and generated data; cited sources retain their own rights.

Twenty-one exact survivor rows compare fixed and balanced width-four groups with a width-eight control. Synthetic accounting, not storage measurements.

Evidence type: deterministic-accounting-model

Method: Enumerate all 70 four-disk subsets of eight disks for the balanced layout. Repeat each of two disjoint four-disk groups 35 times for the fixed control; repeat the eight-disk group 35 times for the wide control. Each disk holds 35 equal 64 MiB fragments. For each stripe containing failed disk 0, count one read from each intact member. A stripe has exactly one parity fragment; its position is irrelevant to this single-erasure read count.

Published: 2026-10-13

Updated: 2026-10-13

Generated: 2026-10-12T23:22:01.156Z

Source: https://hesela.com/analyses/parity-declustering-rebuild-load/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/parity-declustering-rebuild-load/

Code: https://hesela.dev/research/parity-declustering.mjs

Generator: https://hesela.dev/research/build-parity-declustering.mjs

Columns:
- layout (string): Synthetic stripe-membership layout ID.
- poolDisks (number): Number of disks in the modeled pool, including the failed disk.
- groupWidth (number): Fragments per single-parity stripe, including one parity fragment.
- failedDisk (number): Zero-based disk ID lost in this scenario; always 0 in this export.
- survivorDisk (number): Zero-based surviving disk ID; includes disks doing zero reads.
- lostBlocks (number): Fragments lost on the failed disk; each is independently reconstructed.
- survivorHeldBlocks (number): Fragments held on this survivor before failure, including parity.
- readBlocks (number): Whole helper fragments read from this survivor for complete modeled repair.
- fragmentBytes (number): Bytes per fragment; 67108864 bytes = 64 MiB.
- readBytes (number): readBlocks multiplied by fragmentBytes; excludes reconstructed writes.

Limits:
- This is exhaustive deterministic enumeration, not a random sample, benchmark or field dataset; there is no observation period or statistical confidence interval.
- Eight modeled disks, one known erasure, intact helpers and equal-size fragments; no read failures, duplicate reads, compression, caches or metadata traffic.
- Output writes total 35 fragments in each case but their destination and timing are not modeled.
- The wide control changes parity overhead and payload capacity as well as stripe width. Fixed and balanced width-four cases are the matched comparison.
- Stripe membership is not a full physical layout: no parity rotation, addresses, encoder, queue model or OpenZFS permutation map.
- The model bounds pool size to 16 to prevent uncontrolled combinatorial enumeration. Complete layouts are educational examples, not a production recommendation.

Citations:
- [holland1992] Mark Holland and Garth A. Gibson. Parity Declustering for Continuous Operation in Redundant Disk Arrays. ASPLOS 1992, pp. 23-35; sections 2, 4-8.. https://www.cs.cmu.edu/~riedel/ftp/Declustering/ASPLOS.pdf (accessed 2026-10-13)
- [welch2008] Brent Welch, Marc Unangst, Zainul Abbasi, Garth Gibson, Brian Mueller, Jason Small, Jim Zelenka and Bin Zhou. Scalable Performance of the Panasas Parallel File System. FAST 2008; section 4.2 and Appendix A, experiment 3.. https://www.usenix.org/legacy/event/fast08/tech/full_papers/welch/welch_html/index.html (accessed 2026-10-13)
- [openzfs] OpenZFS: dRAID how-to, Introduction and Rebuilding to a Distributed Spare (living documentation, functionality introduced in 2.1.0).. https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Pool%20Structure/dRAID%20Howto.html (accessed 2026-10-13)

### 355 of 597 public cloud outages have an unknown root cause

URL: https://hesela.dev/datasets/postmortem-unknown-causes/
Download (CSV): https://hesela.dev/data/datasets/postmortem-unknown-causes.csv
Metadata (JSON): https://hesela.dev/data/datasets/postmortem-unknown-causes.json
Rows: 39
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Gunawi et al., SoCC 2016, Table 3, mark 355 of 597 unplanned outages as UNKNOWN. The study covers 32 popular Internet services and 1,247 public reports from January 2009 through December 2015. The paper states that only 40% of those descriptions reveal a root cause and only 24% reveal a fix. Among known root-cause tags, the three largest counts are UPGRADE 54 (16%), NETWORK 52 (15%), and BUGS 51 (15%). STORAGE is 13 occurrences on 4 services (4% of known causes). HARDWARE is 5 occurrences on 4 services (1% of known causes). One outage can carry more than one tag, so the occurrence column is not a partition of the 597 outages. In the yearly column, M means at least 10, not exactly 10.

Correction: 2026-10-12: completed the existing primary citation's author and venue metadata after checking the PDF title page; CSV values, citation IDs, source URL and original access dates are unchanged.

Updated: 2026-10-13

Source accessed: 2026-10-09

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.drj.com/wp-content/uploads/2018/07/socc16-cos.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/postmortem-unknown-causes/#rights-and-reuse

Rights evidence (primary publication and listed publisher policy only):
- Haryadi S. Gunawi, Mingzhe Hao, Riza O. Suminto, Agung Laksono, Anang D. Satria, Jeffry Adityatama and Kurnia J. Eliazar. Why Does the Cloud Stop Computing? Lessons from Hundreds of Service Outages. SoCC 2016. DOI: 10.1145/2987550.2987583.. https://www.drj.com/wp-content/uploads/2018/07/socc16-cos.pdf (checked 2026-10-13). The paper's page 1 notice permits credited abstracting and conditional personal or classroom copying, and states that other copying or redistribution requires permission and/or a fee. It does not establish a license for COSDB or this CSV.

Columns:
- row_kind (string): Which stated cut the row transcribes: population, uptime, table3, impact, or fix.
- measure (string): The paper's name for the row: a study total, an uptime cut, a Table 3 root-cause tag, an impact tag, or a fix tag.
- section (string): Section number as printed. Empty only for UNKNOWN, which has a blank section cell in Table 3. HARDWARE and SERVER are both 5.11.
- outages_count (integer): Unplanned outages (count). Filled only on the population row for the 597 outages. Empty means the paper does not give this row as an outage total.
- reports_count (integer): Public reports (count). Filled only on the population row for the 1247 unique links. Empty otherwise.
- tags_count (integer): Outage metadata tags (count). Filled only on the population row for the 3249 COSDB tags. Empty otherwise. Not a sum of Table 3.
- study_services_count (integer): Services in the study (count). Filled only on the population row for the 32 services in Table 1. Empty otherwise.
- tagged_services_count (integer): Services with this root cause (count). Table 3 column #Sv. Empty when the row is not a Table 3 root cause.
- services_short_of_uptime_count (integer): Services short of the stated uptime (count), from section 3.2. Empty when the row is not an uptime cut.
- occurrences_count (integer): Root-cause occurrences (count). Table 3 column Cnt. Not a partition of the 597 outages. Empty outside Table 3.
- share_percent (integer): Printed share (%). The basis is share_basis, not a single denominator. Empty when the paper prints a dash or does not print a percent. Table 3 UNKNOWN is empty.
- share_basis (string): What share_percent is a percent of, using the paper's wording. Empty when share_percent is empty.
- yearly_marks (string): Table 3 yearly marks for 2009 through 2015, seven tokens separated by periods, copied as printed. M means at least 10, not exactly 10. A dash is the paper's dash, not a zero stored by this file. Empty outside Table 3.
- signal (string): The report wording or column the paper uses to assign this tag or count.
- misses (string): What that signal does not prove, from a sentence in the same paper or from a blank the paper leaves.
- citation_id (string): Id into the citations list. Open that URL for the sentence. Every row cites the SoCC 2016 PDF.

Citations:
- [gunawi-socc16] Haryadi S. Gunawi, Mingzhe Hao, Riza O. Suminto, Agung Laksono, Anang D. Satria, Jeffry Adityatama and Kurnia J. Eliazar. Why Does the Cloud Stop Computing? Lessons from Hundreds of Service Outages. SoCC 2016. DOI: 10.1145/2987550.2987583.. https://www.drj.com/wp-content/uploads/2018/07/socc16-cos.pdf (accessed 2026-10-09)
- [demirbas-2016] Paper Review: Why Does the Cloud Stop Computing? Lessons from Hundreds of Service Outages. https://muratbuffalo.blogspot.com/2016/11/why-does-cloud-stop-computing-lessons.html (accessed 2026-10-09)

### RAID write costs: reads, writes and payload

URL: https://hesela.dev/datasets/raid-write-costs/
Download (CSV): https://hesela.dev/data/datasets/raid-write-costs.csv
Metadata (JSON): https://hesela.dev/data/datasets/raid-write-costs.json
Rows: 56
License: CC0-1.0 for Hesela's original model and generated rows. Cited works retain their own rights.

56 deterministic RAID5/P+Q examples compare read-modify-write and reconstruct-write with explicit byte denominators. No device measurements or timing predictions.

Evidence type: deterministic-accounting-model

Method: Healthy fixed-width parity rows with complete equal-size block replacements and cold cache. k data blocks, p parity blocks, u replacements. RMW reads u+p and writes u+p; reconstruct reads k-u and writes u+p. One transfer of one member block is one operation. Each row is independent. The two strategies have equal operation count when 2u+p=k.

Published: 2026-10-11

Updated: 2026-10-11

Generated: 2026-10-11T20:20:35.124Z

Source: https://hesela.com/analyses/raid-write-penalty-io-not-speed/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/raid-write-penalty-io-not-speed/

Code: https://hesela.dev/research/raid-write-costs.mjs

Columns:
- k (number): Data blocks per parity row.
- p (number): Parity blocks: 1 for RAID5, 2 for P+Q.
- u (number): Complete data blocks replaced together in the same row.
- blockBytes (number): Bytes per equal-size member block; illustrative 4096-byte input.
- strategy (string): Forced rmw or reconstruct; not an observed controller choice.
- reads (number): Member-block reads before parity calculation, with no cache hits.
- writes (number): Changed-data plus parity member-block writes.
- operations (number): Reads plus writes; counts, not seconds.
- hostBytes (number): Replacement payload bytes: u times blockBytes.
- readBytes (number): Member-interface bytes read.
- writeBytes (number): Member-interface bytes written; excludes NAND-internal work.
- operationsPerHostBlock (number): Member-block reads and writes divided by u.
- writeBytesPerHostByte (number): Member write bytes divided by host payload bytes.
- ioBytesPerHostByte (number): Member read plus write bytes divided by host payload bytes.

Limits:
- Synthetic arithmetic, not sampled observations, a benchmark or a paper replication. No confidence interval applies.
- All members are available. This is not an encoder, RAID simulator or degraded-write policy.
- RMW at u=k is forced as a comparison, not recommended or asserted controller behavior.
- Excludes caching, merged commands, journals, flushes, metadata, retries, CPU time and device-internal amplification.
- The 4 KiB block is an equal slice at the same offset across members, not a required configured RAID chunk size.
- Minimum transfer count is not a guaranteed minimum latency or maximum throughput.

Citations:
- [chen1994] Peter M. Chen, Edward K. Lee, Garth A. Gibson, Randy H. Katz and David A. Patterson. RAID: High-Performance, Reliable Secondary Storage. ACM Computing Surveys 26(2), 145-185 (1994). Author manuscript: sections 3.2.5-3.3.2, Table 3 and 4.1.. https://pdl.cmu.edu/PDL-FTP/RAID/computin.pdf (accessed 2026-10-11)
- [williams2006] Dan J. Williams. MD RAID Acceleration: Support for Asynchronous DMA/XOR Engines. Linux Symposium 2006, Volume Two, printed pp. 409-414; sections 3-5. The PDF filename uses different pagination.. https://www.kernel.org/doc/ols/2006/ols2006v2-pages-417-422.pdf (accessed 2026-10-11)
- [linux-cache] Linux kernel documentation: RAID 4/5/6 cache, write-back mode and implementation. Rolling documentation; accessed 11 October 2026.. https://www.kernel.org/doc/html/latest/driver-api/md/raid5-cache.html (accessed 2026-10-11)

### RAID write-hole states: an exhaustive one-bit XOR model

URL: https://hesela.dev/datasets/raid-write-hole-state-model/
Download (CSV): https://hesela.dev/data/datasets/raid-write-hole-state-model.csv
Metadata (JSON): https://hesela.dev/data/datasets/raid-write-hole-state-model.json
Rows: 32
License: CC0-1.0 for Hesela-generated CSV and numerical rows; model code MIT; cited sources retain their own licenses.

32 synthetic states distinguish inconsistent parity, recovery of an untouched missing chunk and preservation of an interrupted update. Not hardware measurements or failure probabilities.

Evidence type: deterministic-algebraic-model

Method: Enumerate eight initial A/B/C bit triples and four independent persistence masks for a single changed A bit and parity. A durable partial-parity record Q=B XOR C is assumed to precede both member updates. Repaired parity is A_after XOR Q. B is absent at reconstruction; A, C and Q survive.

Published: 2026-10-11

Updated: 2026-10-11

Generated: 2026-10-11T03:19:58.346Z

Source: https://hesela.com/analyses/raid-write-hole-bitmap-ppl/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Code: https://hesela.dev/research/raid-write-hole-model.mjs

Columns:
- a_before (integer): Initial bit of updated chunk A. Unit: dimensionless bit or 0/1 indicator.
- b_unchanged (integer): Initial bit of untouched chunk B; B is the missing member during reconstruction. Unit: dimensionless bit or 0/1 indicator.
- c_unchanged (integer): Bit of surviving untouched chunk C. Unit: dimensionless bit or 0/1 indicator.
- a_target (integer): Intended new bit in A, always 1 minus a_before in this enumeration. Unit: dimensionless bit or 0/1 indicator.
- data_persisted (integer): 1 if the A update reached nonvolatile storage before the modeled crash. Unit: dimensionless bit or 0/1 indicator.
- parity_persisted (integer): 1 if the new parity reached nonvolatile storage before the modeled crash. Unit: dimensionless bit or 0/1 indicator.
- a_after (integer): A bit available after the modeled crash. Unit: dimensionless bit or 0/1 indicator.
- parity_after (integer): Possibly stale parity bit available after the modeled crash. Unit: dimensionless bit or 0/1 indicator.
- parity_consistent (integer): 1 if parity_after equals XOR of the three post-crash data bits. Unit: dimensionless bit or 0/1 indicator.
- naive_recovered_b (integer): B reconstructed using a_after, c_unchanged and possibly stale parity. Unit: dimensionless bit or 0/1 indicator.
- naive_b_correct (integer): 1 if naive_recovered_b equals b_unchanged. Unit: dimensionless bit or 0/1 indicator.
- ppl_repaired_parity (integer): XOR of a_after and durably recorded XOR of untouched B and C. Unit: dimensionless bit or 0/1 indicator.
- ppl_recovered_b (integer): B reconstructed using the repaired parity. Unit: dimensionless bit or 0/1 indicator.
- ppl_b_correct (integer): 1 if ppl_recovered_b equals b_unchanged. Unit: dimensionless bit or 0/1 indicator.
- a_target_present (integer): 1 if A contains the intended new bit; independent of B recovery. Unit: dimensionless bit or 0/1 indicator.

Limits:
- Synthetic state enumeration, not a sample of devices; state counts are not event probabilities and no confidence interval is applicable.
- Atomic one-bit member writes; no torn sectors, firmware, journal corruption, concurrency, RAID6 or multiple failures.
- The durable PPL record, its integrity and ordering are assumptions. This is not an implementation or verification of Linux MD recovery.
- Missing B was not being written. Missing A is outside the modeled guarantee; PPL does not generally preserve in-flight writes.
- No upper-layer I/O acknowledgement is modeled. a_target_present is not an application durability guarantee.

Citations:
- [ppl] Linux v6.12: Partial Parity Log. https://github.com/torvalds/linux/blob/v6.12/Documentation/driver-api/md/raid5-ppl.rst (accessed 2026-10-11)
- [journal] Linux v6.12: RAID 4/5/6 cache. https://github.com/torvalds/linux/blob/v6.12/Documentation/driver-api/md/raid5-cache.rst (accessed 2026-10-11)
- [md] Linux v6.12: RAID arrays, dirty/degraded assembly and bitmap metadata. https://github.com/torvalds/linux/blob/v6.12/Documentation/admin-guide/md.rst (accessed 2026-10-11)
- [flush] Linux v6.12: Explicit volatile write back cache control. https://github.com/torvalds/linux/blob/v6.12/Documentation/block/writeback_cache_control.rst (accessed 2026-10-11)

### Replacing disks at 200 reallocated sectors removed 88% of triple-disk RAID failures at one vendor

URL: https://hesela.dev/datasets/raidshield-reallocated-sectors/
Download (CSV): https://hesela.dev/data/datasets/raidshield-reallocated-sectors.csv
Metadata (JSON): https://hesela.dev/data/datasets/raidshield-reallocated-sectors.json
Rows: 17
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Ma et al., FAST 2015, analysed about 1 million SATA disks in 6 models in one vendor's backup systems (logs of 21 to 60 months from June 2008). Replacing a disk once its reallocated-sector count passed 200 avoided about 88% of triple-disk RAID failures, which were 80% of RAID failures, or about 70% of all disk-related incidents. In simulation, thresholds below 200 caught 52% to 70% of failures within 60 days with 0.8% to 4.5% false positives. Cross-check rows come from Google (FAST 2007) and Backblaze (2016).

Updated: 2026-10-13

Source accessed: 2026-10-10

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/conference/fast15/fast15-paper-ma.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/raidshield-reallocated-sectors/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/raidshield-reallocated-sectors/

Rights evidence (primary publication and listed publisher policy only):
- RAIDShield: Characterizing, Monitoring, and Proactively Protecting Against Disk Failures, Ma et al., FAST 2015 (USENIX PDF). https://www.usenix.org/system/files/conference/fast15/fast15-paper-ma.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- The 88% is the vendor's own before and after comparison, normalized to the pre-deployment monthly average. Absolute rates are not published.
- The deployed rule covered 3 of the 6 models. Simulated rates come from one model.
- The paper prints 65% and 2.5% in the introduction and 52% to 70% and 0.8% to 4.5% in the evaluation.
- ARMOR was only simulated.
- The systems are write-heavy backup systems.
- Google and Backblaze rows are different fleets and measures and do not test the 88%.

Citations:
- [ma-fast15-pdf] RAIDShield: Characterizing, Monitoring, and Proactively Protecting Against Disk Failures, Ma et al., FAST 2015 (USENIX PDF). https://www.usenix.org/system/files/conference/fast15/fast15-paper-ma.pdf (accessed 2026-10-10)
- [pinheiro-usenix-html] Failure Trends in a Large Disk Drive Population, Pinheiro, Weber, and Barroso, FAST 2007 (USENIX HTML proceedings). https://www.usenix.org/legacy/events/fast07/tech/full_papers/pinheiro/pinheiro_html/index.html (accessed 2026-10-09)
- [backblaze-smart-2016] What SMART Stats Tell Us About Hard Drives, Backblaze, 6 October 2016. https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ (accessed 2026-10-10)

### RAIDZ expansion: ideal retained parity overhead

URL: https://hesela.dev/datasets/raidz-expansion-overhead/
Download (CSV): https://hesela.dev/data/datasets/raidz-expansion-overhead.csv
Metadata (JSON): https://hesela.dev/data/datasets/raidz-expansion-overhead.json
Rows: 5
License: CC0-1.0 for Hesela's original model and generated data; cited sources retain their own rights.

Five deterministic mixtures of old and new full-width parity geometry for the same 6 TiB payload. Not measured storage capacity or ZFS space-report output.

Evidence type: deterministic-accounting-model

Method: Hold payload D=6 TiB and parity P=2 fixed; old width N=4, new width M=5. Enumerate old payload fractions f=0,0.25,0.5,0.75,1. Compute raw=D*f*N/(N-P)+D*(1-f)*M/(M-P); extra=D*f*P*(M-N)/((N-P)*(M-P)). TiB means 2^40 bytes. CSV rounds numbers to nine decimal places; the in-page table uses these exact half-TiB example values. Each row is an independent hypothetical cohort mixture, not an observed time step.

Published: 2026-10-16

Updated: 2026-10-16

Generated: 2026-10-16T08:41:22.503Z

Source: https://hesela.com/analyses/raidz-expansion-parity-capacity/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/raidz-expansion-parity-capacity/

Code: https://hesela.dev/research/raidz-expansion.mjs

Generator: https://hesela.dev/research/build-raidz-expansion.mjs

Columns:
- oldWidth (number): Original physical width, including parity; 4 in this example.
- newWidth (number): Final physical width, including parity; 5 in this example.
- parity (number): Unchanged parity-fragment count per full row; 2.
- payloadTiB (number): Total payload in TiB (2^40 bytes), excluding parity; 6.
- oldFraction (number): Fraction of payload bytes retaining the old data-to-parity ratio, not pool occupancy.
- oldPayloadTiB (number): Payload at the old ratio, in TiB.
- newPayloadTiB (number): Payload at the new ratio, in TiB.
- oldParityTiB (number): Ideal parity allocated for the old cohort, in TiB.
- newParityTiB (number): Ideal parity allocated for the new cohort, in TiB.
- rawTiB (number): Modeled total payload plus parity, in TiB; not zfs list or zpool list output.
- allNewRawTiB (number): Counterfactual allocation if all payload used the new ratio and old blocks were freed, in TiB.
- retainedExtraTiB (number): Extra allocation relative to that all-new counterfactual, in TiB; not promised reclaimable space.

Limits:
- This is deterministic algebra, not a hardware benchmark, field dataset or replication of FastScale; no observation period, sampling interval or statistical confidence interval applies.
- Assumes full-width equal-size fragments, fixed payload and unchanged parity. Real RAIDZ blocks can use variable widths and incur allocation padding.
- Excludes metadata, compression, deduplication, snapshots, clones, reservations, free-space headroom and filesystem accounting conventions.
- The all-new counterfactual assumes old blocks are freed. Retained snapshot or clone references can make a rewrite consume additional space.
- Multiple historical expansion widths require separate cohort accounting; this export contains only one old and one new geometry.
- No prediction of rewrite duration, error rate, recoverability, actual usable capacity or reported AVAIL.

Citations:
- [attach] OpenZFS 2.3: zpool-attach(8), RAID-Z expansion and space reporting. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-attach.8.html (accessed 2026-10-16)
- [rewrite] OpenZFS zfs-2.3.4: zfs-rewrite(8), snapshot and clone space consequences. https://github.com/openzfs/zfs/blob/zfs-2.3.4/man/man8/zfs-rewrite.8 (accessed 2026-10-16)
- [concepts] OpenZFS zfs-2.3.0: zpoolconcepts(7), RAID-Z virtual devices. https://github.com/openzfs/zfs/blob/zfs-2.3.0/man/man7/zpoolconcepts.7 (accessed 2026-10-16)

### Read-only SSD intervals: when byte WAF is undefined

URL: https://hesela.dev/datasets/read-reclaim-accounting/
Download (CSV): https://hesela.dev/data/datasets/read-reclaim-accounting.csv
Metadata (JSON): https://hesela.dev/data/datasets/read-reclaim-accounting.json
Rows: 4
License: CC0-1.0 for Hesela's original code and constructed examples. Source publications retain their own rights.

Four constructed counter-delta cases preserve zero-host-write intervals, distinguish ratios from rates, and show why sequential windows must be combined before division.

Evidence type: deterministic-arithmetic-examples

Method: Invented consecutive write and read windows, each 3,600 seconds, plus their combined interval and an independent idle case. Byte WAF = nandProgramBytes/hostWriteBytes when hostWriteBytes>0, otherwise null. Program rate = nandProgramBytes/durationSeconds. Combine nonoverlapping sequential windows by adding byte deltas and duration, not averaging ratios.

Published: 2026-10-12

Updated: 2026-10-12

Generated: 2026-10-12T06:22:55.336Z

Source: https://www.snia.org/education/online-dictionary/term/write-amplification-factor

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/ssd-read-reclaim-hidden-writes/

Code: https://hesela.dev/research/read-reclaim-accounting.mjs

Columns:
- scenario (string): Constructed window label; combined-write-and-read overlaps its component rows and must not be added to them.
- hostReadBytes (number): Host-read byte delta in this interval; zero is an explicit observation, not missing data.
- hostWriteBytes (number): Host-written byte delta; denominator of byte WAF.
- nandProgramBytes (number): Assumed physical NAND-program byte delta; not inferred from host counters or attributed entirely to reclaim.
- durationSeconds (number): Interval duration in seconds; positive integer.
- byteWaf (number|null): NAND-programmed bytes divided by host-written bytes; null in JSON and empty in CSV when denominator is zero.
- nandProgramBytesPerSecond (number): Mean physical-program rate, bytes/second, across the whole interval; not peak throughput.
- nandProgramBytesPerHostReadByte (number|null): NAND-programmed bytes/host-read byte; not WAF or causal attribution; null/blank if no host reads.

Limits:
- Constructed counter deltas, not hardware observations, firmware simulation or reproduced paper data.
- NAND programming may include reclaim, garbage collection, metadata and other work; these rows do not separate causes.
- Counter availability, units, scope, resets and saturation must be verified before applying arithmetic to actual telemetry.
- Only nonoverlapping consecutive intervals of the same device and measurement scope can be combined. The combined row is not an additional independent observation.
- No latency, failure probability, read-count threshold or lifetime prediction. Deterministic arithmetic has no sampling confidence interval.

Citations:
- [snia] SNIA dictionary: write amplification factor. Operation-count convention, not the byte convention used in our examples.. https://www.snia.org/education/online-dictionary/term/write-amplification-factor (accessed 2026-10-12)
- [hesela-reclaim] Hesela: SSD read reclaim and read-only accounting. https://hesela.com/analyses/ssd-read-reclaim-hidden-writes/ (accessed 2026-10-12)

### Read repair: three constructed state traces

URL: https://hesela.dev/datasets/read-repair-traces/
Download (CSV): https://hesela.dev/data/datasets/read-repair-traces.csv
Metadata (JSON): https://hesela.dev/data/datasets/read-repair-traces.json
Rows: 9
License: CC0-1.0 for Hesela's original model code and constructed traces; cited documentation retains its own license.

A finite example contrasts a narrow blocking repair, response-only reconciliation and a full-partition read, without running a Cassandra cluster.

Evidence type: constructed-state-traces

Method: Each independent scenario starts with A=(1,1), B=C=(0,0) for rows x and y of one partition after an unsuccessful quorum write reached A only. A read contacts A+B; a second read contacts B+C. Reconciliation chooses the higher generation per queried row. BLOCKING copies those rows to both participants before returning; NONE returns reconciled rows without writing. All repair writes succeed. The third scenario changes the first read from x alone to x+y.

Published: 2026-10-13

Updated: 2026-10-13

Generated: 2026-10-13T02:21:39.965Z

Source: https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/managing/operating/read_repair.adoc

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/replica-repair-coverage/

Code: https://hesela.dev/research/read-repair-traces.mjs

Columns:
- scenario (string): Independent scenario label; not a sampled population.
- mode (string): Model rule: BLOCKING writes selected rows to contacted replicas; NONE does not.
- step (integer): 0 initial state, 1 first read, 2 second read; ordering only, not elapsed time.
- participants (string): Contacted replica names, joined with +; empty at initialization.
- fields (string): Rows selected within one partition, joined with +; empty at initialization.
- returnedX (integer|null): Generation returned for row x; null/empty CSV means not read, never zero.
- returnedY (integer|null): Generation returned for row y; null/empty CSV means not read, never zero.
- A (string): Replica A state after the step, x/y; 0 is the old generation and 1 the new generation, not an application-value ordering.
- B (string): Replica B state after the step, x/y; 0 is the old generation and 1 the new generation, not an application-value ordering.
- C (string): Replica C state after the step, x/y; 0 is the old generation and 1 the new generation, not an application-value ordering.

Limits:
- Constructed finite traces, not Cassandra execution, measured traffic or reproduction of paper data.
- One partition, three full replicas, two ordered generations and two responding replicas per read; no concurrent updates, timestamp ties, expiry, deletion, speculative reads, hints, batch replay or anti-entropy.
- Repair writes are assumed successful. Failures, topology, acknowledgements, persistence and latency are not simulated.
- The chosen contact schedule is possible, not a frequency estimate or exhaustive proof of implementation behavior.
- Changing the first read's scope repairs both rows in this trace only; this does not prove general transaction isolation or recommend a production setting.
- Rows are dependent states in three separate scenarios; no statistical confidence interval is applicable.

Citations:
- [read] Apache Cassandra 5.0.0: Read repair; table-level configuration and partition write atomicity. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/managing/operating/read_repair.adoc (accessed 2026-10-13)

### Eleven nines: what a durability model does not prove

URL: https://hesela.dev/datasets/s3-durability-eleven-nines-derivation/
Download (CSV): https://hesela.dev/data/datasets/s3-durability-eleven-nines-derivation.csv
Metadata (JSON): https://hesela.dev/data/datasets/s3-durability-eleven-nines-derivation.json
Rows: 21
Rights statement: No standalone reuse license has been verified for this mixed-source derived CSV. It combines attributed source figures and labeled arithmetic; it is not an observed loss dataset or a copy of the papers. The sources retain their own rights.

Historical source figures and reproducible fixed-window arithmetic: distinguish Poisson event counts from distinct-shard binomial probabilities, with explicit storage-class scope.

Updated: 2026-10-15

Source accessed: 2026-10-15

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-15

Source: https://www.backblaze.com/blog/cloud-storage-durability/

Rights statement URL (not a license grant): https://hesela.dev/datasets/s3-durability-eleven-nines-derivation/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/s3-durability-eleven-nines-derivation/

Rights evidence (primary publication and listed publisher policy only):
- Amazon S3 FAQs, Durability and Data Protection (AWS, vendor document). https://aws.amazon.com/s3/faqs/ (checked 2026-10-15). Reviewed for factual provenance; this source is not a verified standalone reuse license for Hesela's mixed-source CSV.
- AWS S3 User Guide: storage classes, durability and Availability Zone scope. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html (checked 2026-10-15). Reviewed for factual provenance; this source is not a verified standalone reuse license for Hesela's mixed-source CSV.
- Backblaze Durability Calculates at 99.999999999% And Why It Doesn't Matter, Brian Wilson, Backblaze blog, 17 July 2018 (vendor derivation). https://www.backblaze.com/blog/cloud-storage-durability/ (checked 2026-10-15). Reviewed for factual provenance; this source is not a verified standalone reuse license for Hesela's mixed-source CSV.
- Mean time to meaningless: MTTDL, Markov models, and storage system reliability, Greenan, Plank, and Wylie, USENIX HotStorage 2010 (USENIX PDF, independent academic source). https://www.usenix.org/legacy/event/hotstorage10/tech/full_papers/Greenan.pdf (checked 2026-10-15). Reviewed for factual provenance; this source is not a verified standalone reuse license for Hesela's mixed-source CSV.
- Backblaze erasure-coding durability notebook, pinned revision 37f758d. https://github.com/Backblaze/erasure-coding-durability/blob/37f758d64240cfb42a6d6fd41ff4ca16b8499bb3/calculation.ipynb (checked 2026-10-15). Reviewed for factual provenance; this source is not a verified standalone reuse license for Hesela's mixed-source CSV.

Columns:
- measure (string): The quantity as the source names it, or our derived quantity.
- value_low (number): Retained legacy range column; empty for this point-value extract.
- value_high (number): Point value, not an upper uncertainty bound; see scope and note.
- unit (string): Unit of the value.
- scope (string): Population and context the value applies to; 'Derived by us' marks our arithmetic.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list; several ids are separated by semicolons.

Limits:
- All window calculations assume independent, constant-rate shard failures and independent fixed periods. They do not model overlapping repairs, losses straddling period boundaries, latent corruption, shared dependencies or operational deletion. The fractional annual exponent is a historical approximation, not an event-driven repair simulation. Extra decimal digits reduce rounding error but do not reduce model uncertainty. No empirical confidence interval, provider ranking or guarantee follows.
- The 2018 Backblaze inputs are historical, not current provider measurements.
- The source extract has 21 rows; the separate model CSV has four deterministic parameter scenarios. Neither count is an empirical sample size.
- An expected loss count is not a guaranteed waiting time. Probability of any loss needs assumptions about dependence.
- The AWS storage-class source excludes One Zone classes from the three-zone claim.

Citations:
- [aws-s3-faq] Amazon S3 FAQs, Durability and Data Protection (AWS, vendor document). https://aws.amazon.com/s3/faqs/ (accessed 2026-10-15)
- [aws-s3-userguide] AWS S3 User Guide: storage classes, durability and Availability Zone scope. https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html (accessed 2026-10-15)
- [backblaze-2018] Backblaze Durability Calculates at 99.999999999% And Why It Doesn't Matter, Brian Wilson, Backblaze blog, 17 July 2018 (vendor derivation). https://www.backblaze.com/blog/cloud-storage-durability/ (accessed 2026-10-15)
- [greenan-hotstorage10-pdf] Mean time to meaningless: MTTDL, Markov models, and storage system reliability, Greenan, Plank, and Wylie, USENIX HotStorage 2010 (USENIX PDF, independent academic source). https://www.usenix.org/legacy/event/hotstorage10/tech/full_papers/Greenan.pdf (accessed 2026-10-15)
- [backblaze-notebook] Backblaze erasure-coding durability notebook, pinned revision 37f758d. https://github.com/Backblaze/erasure-coding-durability/blob/37f758d64240cfb42a6d6fd41ff4ca16b8499bb3/calculation.ipynb (accessed 2026-10-15)

### At 128K, one three-node vSAN cluster read 10,366 MB/s on NVMe, 4,566 MB/s on SAS, and 2,776 MB/s on SATA

URL: https://hesela.dev/datasets/sata-sas-nvme-measured-throughput/
Download (CSV): https://hesela.dev/data/datasets/sata-sas-nvme-measured-throughput.csv
Metadata (JSON): https://hesela.dev/data/datasets/sata-sas-nvme-measured-throughput.json
Rows: 11
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

At 128K and 100 percent sequential read, one three-node VMware vSAN cluster reached 10,366 MB/s on KIOXIA CD6 NVMe, 4,566 MB/s on 12 Gbps SAS, and 2,776 MB/s on 6 Gbps SATA. Principled Technologies reported those cluster totals at each configuration's own 100 percent Vdbench IOrate. Hands-on testing ended 21 May 2021, the configurations were finalized on 14 April 2021 or earlier, and the KIOXIA-commissioned report is dated September 2021. The same rows show latency of 13.88 ms on NVMe and 3.51 ms on SATA, so the higher throughput is not a lower-latency result. The 6 Gbps and 12 Gbps figures are the printed link rates and are not converted to MB/s.

Updated: 2026-10-13

Source accessed: 2026-10-11

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.principledtechnologies.com/KIOXIA/RM5-Series-value-SAS-and-CD6-NVMe-mainstream-vs-SATA-Vdbench-science-0921.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/sata-sas-nvme-measured-throughput/#rights-and-reuse

Rights evidence (primary publication and listed publisher policy only):
- The science behind the report: Process more read-heavy I/O with HPE ProLiant DL385 Gen10 Plus servers configured with KIOXIA value SAS and NVMe mainstream SSDs (Principled Technologies, September 2021). https://www.principledtechnologies.com/KIOXIA/RM5-Series-value-SAS-and-CD6-NVMe-mainstream-vs-SATA-Vdbench-science-0921.pdf (checked 2026-10-13). Page 7 contains a warranty and liability disclaimer and identifies KIOXIA as the commissioning company. These statements do not establish a reuse license for this CSV or the benchmark measurements.

Columns:
- figure_kind (string): measured_cluster, vendor_drive_rating, or interface_line_rate. These are different populations and are not interchangeable.
- block_size_as_printed (string): Block size as the source prints it: 32K, 64K, 128K, or 128 KB. Not converted to bytes.
- interface (string): SATA, SAS, NVMe, or PCIe.
- cluster_throughput_mb_s (number): Three-node vSAN cluster throughput in MB/s as Principled Technologies printed it at 100 percent Vdbench IOrate. Blank when the row is not that measurement. The PDF does not define MB.
- cluster_iops (number): Cluster input/output operations per second at the same 100 percent IOrate point. Blank when the row is not that measurement.
- latency_ms (number): Latency in milliseconds at the same 100 percent IOrate point. Blank when the row is not that measurement.
- link_rate_gbps (number): Link rate in Gbps as science PDF Table 4 prints it: 6 for SATA or 12 for SAS. Not converted to MB/s. Blank when the source does not print a Gbps figure.
- vendor_sequential_read_mb_s (number): Single-drive sequential read in MB/s. KIOXIA defines 1 MB as 1,000,000 bytes. A vendor claim, not the vSAN cluster. Blank on cluster rows.
- pcie_transfer_rate_gt_s (number): PCIe transfer rate in gigatransfers per second from KIOXIA FAQ Table 1. An interface rate, not a drive measurement.
- pcie_x1_payload_gb_s (number): PCIe x1 payload throughput in GB/s from KIOXIA FAQ Table 1. Not a Vdbench result.
- pcie_x4_payload_gb_s (number): PCIe x4 payload throughput in GB/s from KIOXIA FAQ Table 1. Not evidence that the tested server used four lanes.
- drive_as_printed (string): Capacity-drive model from science PDF Table 4, or the FAQ series name on the vendor row. Blank on the interface-rate row.
- link_as_printed (string): Interface label copied from the source, including words the numeric columns do not encode.
- population (string): What the row counts: one three-node cluster, one vendor drive rating, or a reprinted interface rate.
- result_date (string): 2021-05-21 is the day Principled Technologies concluded hands-on testing. 2021-04 is the KIOXIA FAQ issue month, not a test day.
- note (string): What the row is not, tied to a sentence in the cited file.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Population: one three-node VMware vSAN cluster per interface, not a sample of clusters. Each node is an HPE ProLiant DL385 Gen10 Plus with one disk group, two 3.84 TB capacity SSDs, and the same 800 GB KIOXIA KCM6XVUL800G NVMe cache, including the SATA configuration. Hands-on testing ended 21 May 2021. Configurations were finalized on 14 April 2021 or earlier. The report is dated September 2021 and was commissioned by KIOXIA. There is no confidence interval.
- Not measured: random I/O, writes, mixed read/write, block sizes other than 32K, 64K, and 128K, 24G SAS, per-drive throughput, and a comparison held to one shared latency. The MB/s cells are each configuration's own 100 percent point on a 10-to-120 percent Vdbench IOrate curve. The other curve points are not in this table.
- The report says vSAN services write I/O from the cache tier and read I/O from the capacity tier. It does not print a cache-hit counter. vSAN failures-to-tolerate and the RAID policy are not stated. The published parameter file repeats /dev/sdg on sd7 and sd9 and /dev/sdh on sd8 and sd10, while the prose says 24 VMs with ten 10 GB data disks, so the file does not show ten distinct LUNs.
- Link rate and measured throughput stay in the units the sources print. 6 Gbps and 12 Gbps are not converted to MB/s. The PCIe 4.0 row is KIOXIA's April 2021 reprint of PCI-SIG rates. Science PDF Table 4 does not state the tested NVMe drive's lane count.
- The 6,200 MB/s row is a KIOXIA vendor claim for one CD6-R drive at 3,840 GB, 128 KB, queue depth 32, with 1 MB defined as 1,000,000 bytes. The FAQ does not print part number KCD6XLUL3T84. The science PDF does not define the Vdbench MB, so the cluster MB/s cells are not divided by 6,200 here.
- Science PDF Table 2 prints hardware cost and IOPS per dollar. Those figures are not rows in this file.

Citations:
- [pt-science-0921] The science behind the report: Process more read-heavy I/O with HPE ProLiant DL385 Gen10 Plus servers configured with KIOXIA value SAS and NVMe mainstream SSDs (Principled Technologies, September 2021). https://www.principledtechnologies.com/KIOXIA/RM5-Series-value-SAS-and-CD6-NVMe-mainstream-vs-SATA-Vdbench-science-0921.pdf (accessed 2026-10-11)
- [pt-report-0921] Process more read-heavy I/O with HPE ProLiant DL385 Gen10 Plus servers configured with KIOXIA value SAS and NVMe mainstream SSDs (Principled Technologies, September 2021). https://www.principledtechnologies.com/KIOXIA/RM5-Series-value-SAS-and-CD6-NVMe-mainstream-vs-SATA-Vdbench-0921.pdf (accessed 2026-10-11)
- [kioxia-faq-2021] What You Need To Know About PCIe 4.0 NVMe SSDs, KIOXIA FAQ, April 2021, Rev. 2.5. https://www.kioxia.com/content/dam/kioxia/shared/business/ssd/asset/KIOXIA_What_You_Need_To_Know_About_PCIe_4_NVMe_SSDs_FAQ.pdf (accessed 2026-10-11)
- [pt-infographic-0921] Principled Technologies Vdbench infographic, September 2021. https://www.principledtechnologies.com/KIOXIA/RM5-Series-value-SAS-and-CD6-NVMe-mainstream-vs-SATA-Vdbench-infographic-0921.pdf (accessed 2026-10-11)

### Sector-error prediction and adaptive scrubbing: reported figures

URL: https://hesela.dev/datasets/sector-error-prediction-scrubbing/
Download (CSV): https://hesela.dev/data/datasets/sector-error-prediction-scrubbing.csv
Metadata (JSON): https://hesela.dev/data/datasets/sector-error-prediction-scrubbing.json
Rows: 14
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Selected published figures for drive-week prediction, simulated detection time and two other fleets; these are different endpoints, not a pooled estimate.

Correction: 2026-10-12: added the FAST 2016 source named in the population limitation, verified against ATC 2017 section 2.2 and reference 22. No CSV values or existing citation IDs changed. 2026-10-15: clarified endpoint and budget denominators; linked separately generated illustrative arithmetic, without changing the 14 CSV rows or schema.

Updated: 2026-10-15

Source accessed: 2026-10-10

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/conference/atc17/atc17-mahdisoltani.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/sector-error-prediction-scrubbing/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/sector-error-prediction-scrubbing/

Audit: https://hesela.dev/research/scrub-budget/results.json

Code: https://hesela.dev/research/scrub-budget/model.py

Rights evidence (primary publication and listed publisher policy only):
- Improving Storage System Reliability with Proactive Error Prediction, Mahdisoltani, Stefanovici, and Schroeder, USENIX ATC 2017 (USENIX PDF). https://www.usenix.org/system/files/conference/atc17/atc17-mahdisoltani.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Two hard disk models were chosen because they are common and have the highest error rates.
- The target is a one-week interval with a sector error, not whole-disk failure.
- The paper reports a 75/25 train/test split without establishing chronological or device-disjoint validation.
- The scrubbing result is a simulation with two scrub speeds.
- The SSD rows come from drives of Google's own FAST 2016 study and are not independent of it.
- A false-positive rate conditions on error-free intervals; accelerated-mode time also includes true-positive intervals. They are not interchangeable.
- A reported 1.7-1.8 MTTD ratio means approximately 41.2-44.4% less mean detection time, not 70-80% less time or a measured reduction in data loss.
- Row ranges can pair model-specific endpoints rather than uncertainty bounds; consult scope and note. The CSV remains unchanged.

Citations:
- [mahdisoltani-atc17-pdf] Improving Storage System Reliability with Proactive Error Prediction, Mahdisoltani, Stefanovici, and Schroeder, USENIX ATC 2017 (USENIX PDF). https://www.usenix.org/system/files/conference/atc17/atc17-mahdisoltani.pdf (accessed 2026-10-15)
- [bairavasundaram-sigmetrics07] An Analysis of Latent Sector Errors in Disk Drives, Bairavasundaram, Goodson, Pasupathy, and Schindler, SIGMETRICS 2007 (University of Wisconsin ADSL PDF). https://research.cs.wisc.edu/adsl/Publications/latent-sigmetrics07.pdf (accessed 2026-10-15)
- [pinheiro-usenix-html] Failure Trends in a Large Disk Drive Population, Pinheiro, Weber, and Barroso, FAST 2007 (USENIX HTML proceedings). https://www.usenix.org/legacy/events/fast07/tech/full_papers/pinheiro/pinheiro_html/index.html (accessed 2026-10-09)
- [schroeder-fast16] Bianca Schroeder, Raghav Lagisetty and Arif Merchant. Flash Reliability in Production: The Expected and the Unexpected. FAST 2016, 67-80. Population provenance for the ATC 2017 SSD subset, not an additional independent cohort.. https://www.usenix.org/conference/fast16/technical-sessions/presentation/schroeder (accessed 2026-10-12)

### 0.86% of nearline disks and 0.065% of enterprise disks developed a checksum mismatch in 41 months

URL: https://hesela.dev/datasets/silent-corruption-checksum-mismatches/
Download (CSV): https://hesela.dev/data/datasets/silent-corruption-checksum-mismatches.csv
Metadata (JSON): https://hesela.dev/data/datasets/silent-corruption-checksum-mismatches.json
Rows: 18
License: Small derived table of figures printed in Bairavasundaram et al. (FAST 2008) and the CERN IT report Data integrity (Panzer-Steindel, draft 1.3, 2007), with credit. Not a Creative Commons license. The USENIX proceedings state that rights to individual papers remain with the author or the author's employer. This file is not a copy of either document and not the underlying support logs or probe data.

Bairavasundaram et al., FAST 2008, report that 3,088 of about 358,000 nearline disks (0.86%) and 767 of 1.17 million enterprise-class disks (0.065%) developed at least one silent checksum mismatch in 41 months of support logs covering 1.53 million disks, about 400,000 mismatched 4 KB blocks in all. The median affected disk had 3 mismatches, the mean 104, the maximum 33,000. Only detected corruption is counted. A CERN IT report from 2007 gives an independent but different measure: 22 of 33,700 files failed a checksum comparison.

Updated: 2026-10-12

Source accessed: 2026-10-10

Source: https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html

License URL: https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html

Companion analysis: https://hesela.com/analyses/silent-corruption-checksum-mismatches/

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Only corruption the storage system detected is counted. Corruption that is never read or scrubbed is invisible.
- Logging is optional for customers and removed disks are counted only until removal.
- A disk's result includes its adapter and shelf path. The paper names faulty adapters or shelf controllers for three models.
- The paper prints a mean of 104 for the whole sample and 78 in the first-17-months analysis.
- The CERN report is a 2007 internal draft from one site with its own probes. Its counts are not per-disk shares and do not test the NetApp percentages.
- Several results appear only as charts in the paper and are not in this file.

Citations:
- [bairavasundaram-usenix-html] An Analysis of Data Corruption in the Storage Stack, Bairavasundaram et al., FAST 2008 (USENIX HTML proceedings). https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html (accessed 2026-10-10)
- [bairavasundaram-usenix-pdf] An Analysis of Data Corruption in the Storage Stack (USENIX PDF, used for numerals the HTML conversion drops). https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram.pdf (accessed 2026-10-10)
- [cern-data-integrity-2007] Data integrity, Bernd Panzer-Steindel, CERN IT, draft 1.3, 8 April 2007. https://indico.cern.ch/event/13797/contributions/1362288/attachments/115080/163419/Data_integrity_v3.pdf (accessed 2026-10-10)

### SMART replacement prediction: recall, F-score and random splits

URL: https://hesela.dev/datasets/smart-replacement-prediction-random-splits/
Download (CSV): https://hesela.dev/data/datasets/smart-replacement-prediction-random-splits.csv
Metadata (JSON): https://hesela.dev/data/datasets/smart-replacement-prediction-random-splits.json
Rows: 18
Rights statement: Small derived table with source attribution. No standalone reuse license has been verified for this derived CSV. Papers and the Backblaze post retain their respective rights; attribution and public access are not a reuse license.

Botezatu et al. report 98% Seagate recall; their Hitachi table gives 79%, while the prose says 81%. These random-split results are not a prospective deployment estimate.

Method: This is a source audit and transcription, not a model reproduction. Botezatu et al. (KDD 2016) summarize SMART histories, downsample healthy disks and evaluate a regularized greedy forest using 100 random 80/20 splits. Table 3 reports median precision, recall and F-score for healthy and replaced classes separately. The reduced-feature decision-tree baseline is in Table 5, not the full-feature DT rows of Table 3. Xu et al. (ATC 2018), section 4.4, provide a separate Azure comparison of random and time-forward evaluation; Backblaze (2016) and Lu et al. (FAST 2020) provide contextual rows, not replications.

Updated: 2026-10-14

Source accessed: 2026-10-14

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-14

Source: https://kdd.org/kdd2016/papers/files/adf0849-botezatuA.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/smart-replacement-prediction-random-splits/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/smart-replacement-prediction-random-splits/

Rights evidence (primary publication and listed publisher policy only):
- KDD 2016 paper: source of the extracted table entries. https://kdd.org/kdd2016/papers/files/adf0849-botezatuA.pdf (checked 2026-10-14). Publicly accessible paper; this audit does not establish a standalone license for the combined derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Table 3 gives HitA RGF recall 0.79 and F-score 0.81; section 3.6 instead calls recall 81%. Separate rows preserve this unresolved discrepancy, not a 79-81% interval.
- Table 3 metrics are medians over 100 random runs; they are not pooled confusion counts or prospective deployment estimates.
- The 53% / 44% recall baseline is Table 5's reduced-feature DT, not Table 3's full-feature DT (87% / 61%).
- Random splits do not establish time-forward performance; same-drive leakage is not established by this source audit.
- Downsampled class prevalence differs from deployment conditions; cross-source comparisons use different populations and labels.
- The Azure experiment is not a replication or a quantitative performance bound for the Backblaze predictor.
- Section 3.7 and Figure 6 use snapshots aligned to known replacement dates; their 10/30-day scores are retrospective snapshot horizons, not first-alarm lead times from a continuously running detector.
- The introduction's 67,814 currently operating drives is not the failed-sample denominator. No prospective warning horizon is specified.
- Descriptive operational-drive proportion, not a prospective false positive rate; an observation window and future outcome labels are not supplied.
- Figure 8, p. 160; random five-fold mean. Section 4, p. 159 defines failure within the next 10 days, not guaranteed 10-day warning.
- Unresolved source conflict: the accompanying table reports 4.8% of operational drives for SMART 188 alone, above the narrative's 4.2% for any of five attributes. These cannot describe the same population and predicate; no denominator reconciliation is supplied. The 4.2% is retained as a source statement, not a corrected estimate.

Citations:
- [botezatu-kdd16-pdf] Botezatu, Giurgiu, Bogojeska and Wiesmann. Predicting Disk Replacement towards Reliable Data Centers. ACM SIGKDD 2016, pp. 39-48; Tables 3-5 and section 3.6 (PDF p. 7); section 3.7 and Figure 6 (PDF p. 8).. https://kdd.org/kdd2016/papers/files/adf0849-botezatuA.pdf (accessed 2026-10-14)
- [xu-atc18-pdf] Xu et al. Improving Service Availability of Cloud Systems by Predicting Disk Error. USENIX ATC 2018; section 4.4 and Figure 7, pp. 489-490.. https://www.usenix.org/system/files/conference/atc18/atc18-xu-yong.pdf (accessed 2026-10-14)
- [backblaze-smart-2016] Backblaze. What SMART Stats Tell Us About Hard Drives (6 October 2016), introduction and SMART Stats We Use section; narrative percentages.. https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ (accessed 2026-10-14)
- [lu-fast20-pdf] Lu et al. Making Disk Failure Predictions SMARTer! USENIX FAST 2020, section 4 (pp. 157-160), Figure 8 (p. 160), and section 5 (p. 161).. https://www.usenix.org/system/files/fast20-lu.pdf (accessed 2026-10-14)
- [backblaze-smart-image-2016] Backblaze 2016 SMART table: Operational row, SMART 188 column (image).. https://www.backblaze.com/blog/wp-content/uploads/2016/10/blog-smart-fail-vs-good.jpg (accessed 2026-10-14)

### Over 56% of failed drives had no count on four strong SMART signals

URL: https://hesela.dev/datasets/smart-signal-blind-spots/
Download (CSV): https://hesela.dev/data/datasets/smart-signal-blind-spots.csv
Metadata (JSON): https://hesela.dev/data/datasets/smart-signal-blind-spots.json
Rows: 12
License: Small derived table of figures stated in Pinheiro, Weber, and Barroso, Failure Trends in a Large Disk Drive Population, FAST '07, proceedings pages 17-28, and of one restatement in heise online (16 February 2007). Not a Creative Commons license. USENIX's open-access notice says papers and proceedings are freely available to everyone once the event begins. That notice is not a CC grant, and the FAST '07 HTML does not grant one. This CSV is not Google's SMART repository or repairs database. Canonical files are the USENIX HTML paper and the proceedings PDF.

Over 56% of failed drives in the Google fleet studied by Pinheiro, Weber, and Barroso (FAST '07; more than 100,000 consumer PATA and SATA drives; SMART counts from December 2005 through August 2006) had no count on scan errors, reallocation count, offline reallocation, or probational count. Adding every other SMART parameter except temperature still left over 36% of failed drives at zero on all of those variables. That 56% figure is an upper bound on coverage for the four signals, not a false-positive-aware accuracy.

Source accessed: 2026-10-10

Source: https://www.usenix.org/event/fast07/tech/full_papers/pinheiro/pinheiro_html/

License URL: https://www.usenix.org/conference/osdi18/preview1

Columns:
- row_id (string): Stable id for the signal or coverage cut.
- signal (string): SMART parameter, coverage cut, or the heise restatement of a coverage cut.
- population (string): Fleet, media, and failure definition the row's figures belong to. Google rows are one production fleet. The heise row is a news restatement of that study, not a second fleet.
- window (string): Observation window. Google SMART rows are December 2005 through August 2006 (2005-12/2006-08). The heise row states only about nine months.
- prevalence_percent (number): Share of drives with a non-zero count, in percent. The number is the figure printed next to the bound in prevalence_bound, not a refit. Empty when the row is not a prevalence.
- prevalence_bound (string): How prevalence_percent was stated: fewer-than, under, about, more-than, or point. Empty when prevalence is empty.
- afr_factor_low (number): Low end of the stated AFR multiple versus drives with a zero count. A factor, not a percent and not a line rate. Empty when the paper states no AFR factor. Equal to afr_factor_high when the paper states one factor.
- afr_factor_high (number): High end of that AFR multiple. Empty when afr_factor_low is empty.
- fail_60d_factor (number): Multiple for failure within 60 days after the first count, versus drives with a zero count. Not an AFR. The paper reports a critical threshold when a count raises that probability by at least 10 times at confidence above 95%. Empty when no 60-day factor is stated.
- fail_60d_bound (string): How fail_60d_factor was stated: point or over. Empty when the factor is empty.
- no_count_share_percent (number): Percent of the denominator in no_count_denominator that had no failure signal for this cut. Empty when the row is not a coverage sentence.
- no_count_share_bound (string): How no_count_share_percent was stated: over, about, or point. Empty when the share is empty.
- no_count_denominator (string): Who the no-count share divides: failed-drives or all-drives. The paper uses both for a 36% figure. Empty when the share is empty.
- signaled_group_failed_percent (number): Percent of drives that already had the count and then failed. Used for calibration retries only. Not an AFR and not a share of all failed drives. Empty otherwise.
- signaled_group_failed_bound (string): How signaled_group_failed_percent was stated: about or point. Empty when that percent is empty.
- fault (string): Named condition the signal is about, from a sentence in the cited source.
- catches (string): What a non-zero count indicates in that source.
- misses (string): The failure or ambiguity that count does not prove, from a sentence in the same source.
- citation_id (string): Id into the citations list. Open that URL for the sentence.

Citations:
- [pinheiro-fast07] Failure Trends in a Large Disk Drive Population (Pinheiro, Weber, and Barroso, FAST '07, HTML). https://www.usenix.org/event/fast07/tech/full_papers/pinheiro/pinheiro_html/ (accessed 2026-10-10)
- [pinheiro-fast07-pdf] Failure Trends in a Large Disk Drive Population, FAST '07 proceedings PDF. https://www.usenix.org/legacy/events/fast07/tech/full_papers/pinheiro/pinheiro.pdf (accessed 2026-10-10)
- [heise-2007-02-16] Google-Studie zur Ausfallursache von Festplatten. https://www.heise.de/news/Google-Studie-zur-Ausfallursache-von-Festplatten-147178.html (accessed 2026-10-10)
- [usenix-open-access] USENIX Open Access Media notice. https://www.usenix.org/conference/osdi18/preview1 (accessed 2026-10-10)

### Reported SSD failure-group measurements (FAST 2021)

URL: https://hesela.dev/datasets/ssd-correlated-failures-nodes-racks/
Download (CSV): https://hesela.dev/data/datasets/ssd-correlated-failures-nodes-racks.csv
Metadata (JSON): https://hesela.dev/data/datasets/ssd-correlated-failures-nodes-racks.json
Rows: 16
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Sixteen attributed measurements from published storage studies, with explicit populations and units. The Alibaba grouping shares use all recorded failures as their denominator; the adjacent-size group ratio is not a next-drive forecast. This CSV is a corrected transcription, not raw telemetry or a reproduced experiment.

Updated: 2026-10-16

Source accessed: 2026-10-11

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/system/files/fast21-han.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/ssd-correlated-failures-nodes-racks/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/ssd-correlated-failures-nodes-racks/

Rights evidence (primary publication and listed publisher policy only):
- An In-Depth Study of Correlated Failures in Production SSD-Based Data Centers, Han, Lee, Xu, Liu, He, and Liu, USENIX FAST 2021, pages 417 to 429 (USENIX PDF). https://www.usenix.org/system/files/fast21-han.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- One operator's fleet and ticketing rules.
- The 12.9% and 18.3% shares depend on the 30 minute threshold.
- 88.6% of nodes with two or more SSDs hold one drive model, so some clustering may be a model effect.
- The redundancy results come from a trace-driven simulation.
- The cross-check rows are other fleets with other definitions.
- Figure 3 uses all recorded failures, not only failures already classified as intra-node or intra-rack. Two denominator labels were corrected on 16 October 2026; numeric values were unchanged.
- Figure 2 uses n(x+1) / [n(x) + n(x+1)] for completed group counts n. It is not a per-drive prediction or an AFR risk multiplier.
- Consecutive gaps define groups; total group duration may exceed the threshold. Paper wording excludes equality, while pinned code includes it. The effect on reported totals has not been recomputed.

Citations:
- [han-fast21-pdf] An In-Depth Study of Correlated Failures in Production SSD-Based Data Centers, Han, Lee, Xu, Liu, He, and Liu, USENIX FAST 2021, pages 417 to 429 (USENIX PDF). https://www.usenix.org/system/files/fast21-han.pdf (accessed 2026-10-16)
- [maneas-fast20-pdf] A Study of SSD Reliability in Large Scale Enterprise Storage Deployments, Maneas, Mahdaviani, Emami, and Schroeder, FAST 2020 (USENIX PDF, section 6 on correlated replacements). https://www.usenix.org/system/files/fast20-maneas.pdf (accessed 2026-10-11)
- [ford-osdi10-pdf] Availability in Globally Distributed Storage Systems, Ford et al., USENIX OSDI 2010 (USENIX PDF, section 4 on correlated failures). https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf (accessed 2026-10-11)
- [han-code] Han et al. analysis code (measure.py, revision 5c896eba). https://github.com/shujiehan/ssdanalysis/blob/5c896eba971add07f214f5c7ef3a39882324eca6/analysis/measure.py (accessed 2026-10-16)

### TBW and DWPD conversion table for SSD endurance ratings

URL: https://hesela.dev/datasets/ssd-endurance-tbw-dwpd-calc/
Download (CSV): https://hesela.dev/data/datasets/ssd-endurance-tbw-dwpd-calc.csv
Metadata (JSON): https://hesela.dev/data/datasets/ssd-endurance-tbw-dwpd-calc.json
Chart (SVG): https://hesela.dev/data/datasets/ssd-endurance-tbw-dwpd-calc.svg
Rows: 60
License: The table is arithmetic computed here from the public definitions of TBW and DWPD. No third-party data or specification text is copied and no product rating is listed. Reuse is fine with attribution to this site.

How to convert between TBW (terabytes written) and DWPD (drive writes per day) for an SSD, with a worked table of 60 rows: six capacities from 0.25 to 8 TB, warranty periods of 3 and 5 years, and DWPD ratings of 0.1, 0.3, 1, 3 and 10. The formulas are TBW = DWPD x capacity x 365 x years and DWPD = TBW / (capacity x 365 x years). Pure arithmetic from the public definitions, with no measured data and no product ratings. For example, 1 TB at 1 DWPD over 5 years is 1,825 TBW, and 600 TBW on a 1 TB drive over 5 years is 0.33 DWPD.

Source accessed: 2026-10-10

Source: https://en.wikipedia.org/wiki/Solid-state_drive

License URL: https://en.wikipedia.org/wiki/Wikipedia:Copyrights

Columns:
- capacity_tb (number): Drive capacity in decimal terabytes (1 TB = 10^12 bytes).
- warranty_years (integer): Warranty period in years, each of 365 days.
- dwpd (number): Drive writes per day: full-capacity writes per day allowed for the warranty period.
- tbw (number): Terabytes written over the warranty period: dwpd * capacity_tb * 365 * warranty_years. Exact decimal arithmetic.
- host_writes_gb_per_day (number): dwpd * capacity_tb * 1000, gigabytes of host writes per day.
- pe_cycles_at_waf_1 (number): tbw / capacity_tb = dwpd * 365 * warranty_years: full-drive program/erase cycles used if write amplification is 1. Real drives have write amplification above 1, so this is a count of host full-drive writes.

Citations:
- [wp-ssd] Solid-state drive, Wikipedia: endurance section defining TBW and DWPD. https://en.wikipedia.org/wiki/Solid-state_drive (accessed 2026-10-11)
- [wp-wa] Write amplification, Wikipedia: program/erase cycles and write amplification. https://en.wikipedia.org/wiki/Write_amplification (accessed 2026-10-11)

### 38% of failed datacenter SSDs showed none of the four SMART symptoms; the ones that did failed 3 to 20 times as often

URL: https://hesela.dev/datasets/ssd-failures-datacenter-symptoms/
Download (CSV): https://hesela.dev/data/datasets/ssd-failures-datacenter-symptoms.csv
Metadata (JSON): https://hesela.dev/data/datasets/ssd-failures-datacenter-symptoms.json
Rows: 14
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Narayanan et al., SYSTOR 2016, studied over half a million SSDs in one operator's datacenters over nearly 3 years. 62% of failed devices had shown at least one of four SMART symptoms and 38% none; devices with a symptom failed 3 to 20 times as often. A classifier reached 87% precision and 71% recall with 5-fold cross-validation. Cross-check rows come from NetApp (FAST 2020) and Backblaze (2016).

Correction: 2026-10-13: removed unsupported random-fold wording and clarified training-only oversampling from SYSTOR 2016 section 4.1. Numerical rows and original citation IDs are unchanged.

Updated: 2026-10-13

Source accessed: 2026-10-10

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://bpb-us-e1.wpmucdn.com/sites.psu.edu/dist/9/36635/files/2016/06/systor16_ssd_failures.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/ssd-failures-datacenter-symptoms/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/ssd-failures-datacenter-symptoms/

Rights evidence (primary publication and listed publisher policy only):
- SSD Failures in Datacenters: What? When? and Why?, Narayanan et al., SYSTOR 2016 (author PDF, ACM article 7, pages 1 to 11). https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/a7-narayanan.pdf (checked 2026-10-13). The paper's page 1 notice permits credited abstracting and conditional personal or classroom copying, and states that other copying or redistribution requires permission and/or a fee. It does not establish a license for the study telemetry or this CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- One operator's fleet and workloads; model names are anonymized.
- Failure means a fail-stop that takes the server down; about 80% ended in replacement.
- Per-model AFR values are in charts, so only printed text figures are used.
- Section 4.1 reports five-fold device classification with SMOTE during training; this does not establish forward-time prediction performance.
- The cross-check rows are other fleets with other definitions.

Citations:
- [narayanan-systor16-pdf] SSD Failures in Datacenters: What? When? and Why?, Narayanan et al., SYSTOR 2016 (author PDF, ACM article 7, pages 1 to 11). https://bpb-us-e1.wpmucdn.com/sites.psu.edu/dist/9/36635/files/2016/06/systor16_ssd_failures.pdf (accessed 2026-10-10)
- [maneas-fast20-pdf] A Study of SSD Reliability in Large Scale Enterprise Storage Deployments, Maneas, Mahdaviani, Emami, and Schroeder, FAST 2020 (USENIX PDF, pages 137 to 149). https://www.usenix.org/system/files/fast20-maneas.pdf (accessed 2026-10-10)
- [backblaze-smart-2016] What SMART Stats Tell Us About Hard Drives, Backblaze, 6 October 2016. https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ (accessed 2026-10-10)

### SSD over-provisioning: analytical model values

URL: https://hesela.dev/datasets/ssd-overprovisioning-model/
Download (CSV): https://hesela.dev/data/datasets/ssd-overprovisioning-model.csv
Metadata (JSON): https://hesela.dev/data/datasets/ssd-overprovisioning-model.json
Rows: 7
License: CC0-1.0 for Hesela's original implementation and computed rows; source papers retain their rights.

Seven computed reserve-to-write-amplification cases with explicit logical and physical capacity denominators. Analytical model evaluation, not SSD measurements.

Evidence type: analytical-model-evaluation

Method: Evaluate Xiang and Kurkoski arXiv:1110.4245v1 equation 12 by solving A*log(1-1/A)+(1+rho)=0 for finite A>1. Bisection uses log1p, an expanding upper bracket and at most 100 steps, stopping at floating-point resolution. rho=(P-L)/L; supported domain 0.01 to 1. Capacity units are identical. No random sampling or device I/O.

Published: 2026-10-12

Updated: 2026-10-12

Generated: 2026-10-11T23:22:54.787Z

Source: https://arxiv.org/abs/1110.4245v1

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/ssd-overprovisioning-denominators/

Code: https://hesela.dev/research/ssd-overprovisioning.mjs

Columns:
- opUserPercent (number): 100*(P-L)/L; reserve divided by logical capacity.
- sparePhysicalPercent (number): 100*(P-L)/P; the same reserve divided by physical capacity.
- physicalPerLogical (number): P/L = 1 + rho; dimensionless.
- waf (number): Model physical page writes per host page write; dimensionless, not measured.
- reclaimedFraction (number): Fraction q of victim pages freed for new host writes; 1/waf.
- validFraction (number): Fraction of victim pages relocated; 1-q.

Limits:
- Uniform independent page writes and stationary simplified cleaning behavior; not commercial firmware.
- An asymptotic approximation to the paper's greedy model, not an exact finite-block greedy formula.
- No reproduction of either paper's simulator, trace evaluation or physical-device experiment.
- No metadata, parity, compression, wear-leveling or cache-folding traffic; no latency or lifetime prediction.
- No confidence interval: deterministic arithmetic uncertainty is distinct from model applicability.
- P denotes physical capacity available to this model, not all installed NAND including unavailable overhead.

Citations:
- [xiang] Luojie Xiang and Brian M. Kurkoski. An Improved Analytic Expression for Write Amplification in NAND Flash. arXiv:1110.4245v1 (19 October 2011), sections II-IV, equation 12 and Table I.. https://arxiv.org/abs/1110.4245v1 (accessed 2026-10-11)
- [desnoyers] Peter Desnoyers. Analytic Modeling of SSD Write Performance. SYSTOR 2012, sections 2-6, Tables 1-2. DOI: 10.1145/2367589.2367603.. https://www.ccs.neu.edu/home/pjd/papers/pjd-systor12.pdf (accessed 2026-10-11)

### SSD steady-state window counterexamples

URL: https://hesela.dev/datasets/ssd-steady-state-windows/
Download (CSV): https://hesela.dev/data/datasets/ssd-steady-state-windows.csv
Metadata (JSON): https://hesela.dev/data/datasets/ssd-steady-state-windows.json
Rows: 6
License: CC0-1.0 for Hesela's original code and invented values; source publications retain their rights.

Six synthetic five-round IOPS examples separate variation, drift and local stability. These are arithmetic counterexamples, not SSD benchmark measurements.

Evidence type: synthetic-numerical-counterexamples

Method: Each row contains five nonnegative invented IOPS values at equally spaced round indices 0-4. Ordinary least squares yields a fitted slope; its absolute value times four gives fitted span. Both observed range and fitted span are divided by the five-value arithmetic mean. Inclusive 20% and 10% limits illustrate SNIA SSS PTS 2.0.2 clause 2.1.24 only. Missing values are rejected. All-zero windows are rejected because normalization is undefined.

Published: 2026-10-12

Updated: 2026-10-14

Generated: 2026-10-14T13:29:15.305Z

Source: https://hesela.com/analyses/ssd-steady-state-is-not-a-timer/

License URL: https://creativecommons.org/publicdomain/zero/1.0/

Companion analysis: https://hesela.com/analyses/ssd-steady-state-is-not-a-timer/

Code: https://hesela.dev/research/ssd-steady-state.mjs

Columns:
- scenario (string): Synthetic case identifier; not a device model.
- round1 (number): Invented IOPS in round 1.
- round2 (number): Invented IOPS in round 2.
- round3 (number): Invented IOPS in round 3.
- round4 (number): Invented IOPS in round 4.
- round5 (number): Invented IOPS in round 5.
- mean (number): Arithmetic mean IOPS of the five values.
- rangePercent (number): 100 times (maximum minus minimum) divided by mean.
- fittedSpanPercent (number): 100 times absolute least-squares slope times four round intervals divided by mean.
- rangePass (boolean): Range at most 20% of mean.
- trendPass (boolean): Fitted span at most 10% of mean.
- pass (boolean): Both numerical checks pass; not PTS certification.

Limits:
- No real device, observation period, sample population, random seed or confidence interval.
- This numerical illustration does not implement preparation, workload matrices, all tracked variables or full PTS reporting.
- A passing window cannot establish future stability, statistical stationarity, acceptable speed or tail latency.
- Rounds are equally spaced test indices, not necessarily seconds. Do not pass irregular time samples to this API.
- Floating-point comparisons allow a 64-machine-epsilon tolerance at each threshold.
- Early and later plateaus can be concatenated to demonstrate a drop between two individually passing windows.

Citations:
- [snia] SNIA. Solid State Storage Performance Test Specification, version 2.0.2 (1 October 2020), definitions 2.1.1, 2.1.3, 2.1.6, 2.1.13, 2.1.18 and 2.1.24.. https://www.snia.org/sites/default/files/2025-02/SNIA-SSS-PTS-2.0.2.pdf (accessed 2026-10-11)

### Google measured a disk MTTF of 10 to 50 years but a node MTTF of 4.3 months; 37% of node failures came in bursts

URL: https://hesela.dev/datasets/storage-availability-correlated-failures/
Download (CSV): https://hesela.dev/data/datasets/storage-availability-correlated-failures.csv
Metadata (JSON): https://hesela.dev/data/datasets/storage-availability-correlated-failures.json
Rows: 14
Rights statement: No standalone reuse license has been verified for this derived CSV. It contains selected reported numeric values with attribution, not source publications or the underlying measurements. The sources have separate rights and any source-specific permissions retain their stated scope. This notice does not grant rights to the CSV, source publications, research code or underlying data.

Ford et al., OSDI 2010, studied tens of Google storage cells over one year. Node MTTF was 4.3 months against 10 to 50 years for a disk, and 37% of failures were part of a burst of at least 2 nodes. Cross-check rows come from NetApp (FAST 2020) and HPC1 (FAST 2007) and show clustered drive replacements.

Updated: 2026-10-13

Source accessed: 2026-10-10

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-13

Source: https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/storage-availability-correlated-failures/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/storage-availability-correlated-failures/

Rights evidence (primary publication and listed publisher policy only):
- Availability in Globally Distributed Storage Systems, Ford, Labelle, Popovici, Stokely, Truong, Barroso, Grimes, and Quinlan, USENIX OSDI 2010 (USENIX PDF). https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf (checked 2026-10-13). The paper is publicly readable through USENIX. No standalone reuse license for this CSV was verified.
- USENIX Conference Submissions Policy: copyright. https://www.usenix.org/conferences/author-resources/submissions-policy (checked 2026-10-13). Authors retain copyright; this publisher policy is not a license for Hesela's derived CSV.

Columns:
- measure (string): The quantity as the source names it.
- value_low (number): Reported lower value or bound, when supplied; empty means not stated. Read note for strictness, approximation and interpretation.
- value_high (number): Reported single value or upper bound, when supplied; empty means not stated. The note preserves qualifiers; this is not necessarily an exact value or confidence interval.
- unit (string): Unit stated in this row, applying to both reported-value columns.
- scope (string): Population and window the value applies to.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- One operator's cells and software; figures describe nodes and racks as well as disks.
- Disk MTTF is a printed range of 10 to 50 years, not a vendor rating.
- The 10% sensitivity results come from the authors' model with 3-way replication.
- The 37% burst share depends on a 120 second window.
- The cross-check rows are other fleets with other definitions.

Citations:
- [ford-osdi10-pdf] Availability in Globally Distributed Storage Systems, Ford, Labelle, Popovici, Stokely, Truong, Barroso, Grimes, and Quinlan, USENIX OSDI 2010 (USENIX PDF). https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf (accessed 2026-10-10)
- [maneas-fast20-pdf] A Study of SSD Reliability in Large Scale Enterprise Storage Deployments, Maneas, Mahdaviani, Emami, and Schroeder, FAST 2020 (USENIX PDF, section 6 on correlated replacements). https://www.usenix.org/system/files/fast20-maneas.pdf (accessed 2026-10-10)
- [schroeder-fast07-pdf] Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?, Schroeder and Gibson, FAST 2007 (USENIX PDF, section 5.2 on correlations). https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder.pdf (accessed 2026-10-10)

### Payload ceilings of SATA, SAS and PCIe x4 links by generation

URL: https://hesela.dev/datasets/storage-interface-payload-ceilings/
Download (CSV): https://hesela.dev/data/datasets/storage-interface-payload-ceilings.csv
Metadata (JSON): https://hesela.dev/data/datasets/storage-interface-payload-ceilings.json
Chart (SVG): https://hesela.dev/data/datasets/storage-interface-payload-ceilings.svg
Rows: 14
License: The line rates, line codes and release years are public facts about the SATA, SAS and PCIe standards. No specification text is copied and the specifications are not reproduced. The efficiency and ceiling columns are arithmetic done on this site. Reuse is fine with attribution to the standards bodies named in the sources. This is a small derived table and not a dump of any source.

Theoretical one-direction payload ceilings for 14 storage-link generations: SATA 1.0 to 3.0, SAS-1 to SAS-4 (one lane), and PCIe 1.0 to 7.0 at four lanes. Each value is the published line rate times the line-code efficiency, and nothing is measured. SATA 3.0 gives 600 MB/s, SAS-4 gives 2,400 MB/s, PCIe 4.0 x4 gives 7,877 MB/s and PCIe 7.0 x4 gives 60,500 MB/s. Real drives and protocols stay below these ceilings.

Source accessed: 2026-10-10

Source: https://en.wikipedia.org/wiki/PCI_Express

License URL: https://en.wikipedia.org/wiki/Wikipedia:Copyrights

Columns:
- interface (string): Interface family: SATA, SAS, or PCIe.
- generation (string): Specification generation as named by its standards body.
- spec_year (integer): Year the generation was released or approved, per the cited summaries.
- line_rate_gtps (number): Signalling rate per lane in gigatransfers per second (equal to Gbit/s on the coded line).
- line_code (string): Line code or framing assumed for payload accounting.
- coding_efficiency_percent (number): Payload bits divided by coded bits, in percent. Computed here.
- lanes (integer): Lanes in the link the last column refers to: 1 for SATA and SAS, 4 for PCIe (the usual NVMe SSD link).
- payload_gbps_per_lane (number): Line rate times coding efficiency, Gbit/s per lane, one direction. Computed here.
- payload_mb_s_per_lane (integer): Same in MB/s (10^6 bytes), rounded half up.
- payload_mb_s_link (integer): Per-lane value times lanes, from unrounded values and then rounded half up. One direction, before protocol overhead.

Citations:
- [pcie-wiki] PCI Express (comparison table of line codes, transfer rates and throughput; summarises PCI-SIG documents). https://en.wikipedia.org/wiki/PCI_Express (accessed 2026-10-10)
- [sas-wiki] Serial Attached SCSI (history, 8b/10b and 128b/150b encoding; summarises T10 standards). https://en.wikipedia.org/wiki/Serial_Attached_SCSI (accessed 2026-10-10)
- [sata-wiki] Serial ATA (revisions and usable rates; summarises SATA-IO releases). https://en.wikipedia.org/wiki/Serial_ATA (accessed 2026-10-10)
- [t10] T10 technical committee, SAS standards. https://www.t10.org/ (accessed 2026-10-10)
- [pcisig] PCI-SIG specifications. https://pcisig.com/specifications (accessed 2026-10-10)
- [sata-io] SATA-IO. https://sata-io.org/ (accessed 2026-10-10)

### Slow RAID hours are not request tail latency

URL: https://hesela.dev/datasets/storage-tail-slowdowns-raid-fanout/
Download (CSV): https://hesela.dev/data/datasets/storage-tail-slowdowns-raid-fanout.csv
Metadata (JSON): https://hesela.dev/data/datasets/storage-tail-slowdowns-raid-fanout.json
Rows: 24
Rights statement: No standalone reuse license has been verified for this mixed-source derived CSV. It contains attributed figures and labeled arithmetic, not the papers or raw fleet traces. Each source retains its own rights.

A slow-drive hour, a slow-RAID hour and a request percentile count different events. This source review separates them and shows why fan-out estimates need explicit dependence and workload assumptions.

Method: Source audit of four full papers, with locators in the table notes and accompanying dataset. Published rounded figures are retained separately from Hesela's reproducible arithmetic. Table 1 of Hao et al. supplies the integer exposure and slow-hour counts; no per-request traces were obtained. Synthetic examples use explicit values, exact fractions and nearest-rank percentiles. They are counterexamples, not a replication of a production fleet.

Updated: 2026-10-15

Source accessed: 2026-10-15

Standalone CSV reuse license status: not-verified

Rights status scope: derived-csv

Rights evidence reviewed: 2026-10-15

Source: https://www.usenix.org/system/files/conference/fast16/fast16-papers-hao.pdf

Rights statement URL (not a license grant): https://hesela.dev/datasets/storage-tail-slowdowns-raid-fanout/#rights-and-reuse

Companion analysis: https://hesela.com/analyses/storage-tail-slowdowns-raid-fanout/

Rights evidence (primary publication and listed publisher policy only):
- Hao et al., The Tail at Store, USENIX FAST 2016, pp. 263-276; Table 1, sections 3, 4.1.2, 5.2 and 6. https://www.usenix.org/system/files/conference/fast16/fast16-papers-hao.pdf (checked 2026-10-15). Reviewed for factual provenance; the publication is not a verified standalone reuse license for this mixed-source CSV.
- Dean and Barroso, The Tail at Scale, CACM 56(2), 2013, pp. 74-80; Tables 1-2; DOI 10.1145/2408776.2408794. https://www.barroso.org/publications/TheTailAtScale.pdf (checked 2026-10-15). Reviewed for factual provenance; the publication is not a verified standalone reuse license for this mixed-source CSV.
- Gunawi et al., Fail-Slow at Scale, USENIX FAST 2018; report collection (section 2) and detection time (section 3.5). https://www.usenix.org/system/files/conference/fast18/fast18-gunawi.pdf (checked 2026-10-15). Reviewed for factual provenance; the publication is not a verified standalone reuse license for this mixed-source CSV.
- Lu et al., Perseus, USENIX FAST 2023, pp. 49-64; abstract, sections 4.4-4.5 and 5.1. https://www.usenix.org/system/files/fast23-lu.pdf (checked 2026-10-15). Reviewed for factual provenance; the publication is not a verified standalone reuse license for this mixed-source CSV.

Columns:
- measure (string): The quantity as the source names it, or our derived quantity.
- value_low (number): Legacy lower endpoint: some rows pair HDD and SSD values rather than a statistical interval; empty for point values.
- value_high (number): Point value or paired upper endpoint; never an implied uncertainty bound.
- unit (string): Unit of the value columns: drives, drive hours, percent, milliseconds, times, reports.
- scope (string): Population and window the value applies to; 'Derived by us' marks our arithmetic.
- note (string): What the value is not, or the source wording behind it.
- citation_id (string): Id of the opened source in the citations list.

Limits:
- Hourly summaries cannot recover request percentiles, simultaneous sub-hour stalls, or an empirical confidence interval that accounts for temporal and group dependence. A conditional mean above one establishes multiple slow classifications within some group-hours, not statistical dependence between drives. Historical fleets, operator reports and selected benchmark traces must not be pooled. No current SSD failure rate, universal RAID slowdown, measured mitigation benefit or vendor ranking follows.
- The retained value_low/value_high columns also hold HDD/SSD category endpoints, not confidence intervals. Read the scope before comparing values.
- The 24 table rows are an editorial extract, not the empirical sample size. Source publication dates are not collection dates.

Citations:
- [hao-fast16-pdf] Hao et al., The Tail at Store, USENIX FAST 2016, pp. 263-276; Table 1, sections 3, 4.1.2, 5.2 and 6. https://www.usenix.org/system/files/conference/fast16/fast16-papers-hao.pdf (accessed 2026-10-15)
- [dean-barroso-cacm13-pdf] Dean and Barroso, The Tail at Scale, CACM 56(2), 2013, pp. 74-80; Tables 1-2; DOI 10.1145/2408776.2408794. https://www.barroso.org/publications/TheTailAtScale.pdf (accessed 2026-10-15)
- [gunawi-fast18-pdf] Gunawi et al., Fail-Slow at Scale, USENIX FAST 2018; report collection (section 2) and detection time (section 3.5). https://www.usenix.org/system/files/conference/fast18/fast18-gunawi.pdf (accessed 2026-10-15)
- [lu-fast23-pdf] Lu et al., Perseus, USENIX FAST 2023, pp. 49-64; abstract, sections 4.4-4.5 and 5.1. https://www.usenix.org/system/files/fast23-lu.pdf (accessed 2026-10-15)

### Low-end NetApp interconnect events exceed disk events, 4,338 to 3,230

URL: https://hesela.dev/datasets/what-fails-comparison/
Download (CSV): https://hesela.dev/data/datasets/what-fails-comparison.csv
Metadata (JSON): https://hesela.dev/data/datasets/what-fails-comparison.json
Rows: 33
License: Small derived table of figures stated in Jiang et al., FAST 2008, and Maneas et al., FAST 2020. Not a Creative Commons license. The opened FAST '14 Consent Form for Refereed Papers says USENIX lets authors retain copyright and asks only for a right to publish. That grant is non-exclusive, worldwide, perpetual, and irrevocable, and also non-sublicensable and non-transferable. The form contains no CC grant. This CSV is not the NetApp AutoSupport database and not the Active IQ bundles. Neither paper links a public dump or a data DOI for those logs. Canonical files are the USENIX PDFs.

In Jiang et al., FAST 2008, Table 1, low-end NetApp systems recorded 4,338 physical-interconnect failure events and 3,230 disk failure events from January 2004 through August 2007 (22,031 systems and 264,983 FC disks ever installed). For Figure 4(b), which excludes subsystems that used Disk H, that class has a stated disk AFR of 0.9% and a storage-subsystem AFR of 4.6%. In Maneas et al., FAST 2020, Table 2, SCSI error is 32.78% of SSD replacements (ARR 0.055%) on almost 1.4 million NetApp SSDs; that signal is a hardware error the SSD reports (the example is drive DRAM ECC), while aborted commands are 13.56% (ARR 0.023%) and include a host or connection case where write data never reaches the device.

Updated: 2026-10-12

Source accessed: 2026-10-08

Source: https://www.usenix.org/legacy/events/fast08/tech/full_papers/jiang/jiang.pdf

License URL: https://www.usenix.org/sites/default/files/fast14_consent_author.pdf

Columns:
- row_kind (string): Which stated cut the row transcribes: jiang-table1, jiang-figure4b, jiang-share, or maneas-table2.
- study (string): Citation id of the paper that states the row.
- fleet (string): Named fleet: NetApp AutoSupport or NetApp Active IQ.
- window (string): Study window as year-month bounds. Jiang is January 2004 through August 2007 (44 months). Maneas is the 30 months covered by 10 snapshots from January 2017 through May 2019.
- system_class (string): Jiang storage-system class (near-line, low-end, mid-range, high-end, or all four classes) or ssd sample.
- population (string): Who was counted, which cut (Table 1, Figure 4(b) excluding Disk H, cross-class prose, or Table 2), and what the count is not.
- fault (string): Named failure or replacement reason, using the paper's categories.
- systems_count (integer): Systems (count) from Jiang Table 1. Empty when the row is not a Table 1 class row. Not a Figure 4(b) population.
- shelves_count (integer): Shelf enclosures (count) from Jiang Table 1. Empty when the row is not a Table 1 class row.
- disks_ever_installed_count (integer): Disks ever installed (count) during the 44 months, including replacements, from Jiang Table 1. Empty when the row is not a Table 1 class row. Not the Maneas SSD population.
- failure_events (integer): Failure events (count) for that fault in Jiang Table 1. Empty when the source did not state an event count for the row.
- share_low_percent (number): Share, low (%). Jiang cross-class prose uses a range. The low-end Figure 4(b) disk row uses 20 for the paper's about-20% of subsystem AFR. Maneas Table 2 percent of replacements is a point, so low equals high. Empty when not stated.
- share_high_percent (number): Share, high (%). Equal to share_low_percent when the source stated a point rather than a range. Empty when not stated.
- annual_rate_percent (number): Annual rate (%). AFR for Jiang Figure 4(b) prose, or ARR for Maneas Table 2. Empty when the source did not state an annual rate for the row. Not a line rate and not a throughput.
- annual_rate_kind (string): AFR or ARR when annual_rate_percent is set. Empty otherwise. AFR and ARR are different definitions and are not converted into each other.
- signal (string): The log or telemetry signal the paper says catches this fault.
- misses (string): What that signal does not prove, from a sentence in the same paper.
- citation_id (string): Id into the citations list. Open that URL for the sentence.

Citations:
- [jiang-fast08] Weihang Jiang, Chongfeng Hu, Yuanyuan Zhou and Arkady Kanevsky. Are Disks the Dominant Contributor for Storage Failures? A Comprehensive Study of Storage Subsystem Failure Characteristics. FAST 2008.. https://www.usenix.org/legacy/events/fast08/tech/full_papers/jiang/jiang.pdf (accessed 2026-10-08)
- [maneas-fast20] Stathis Maneas, Kaveh Mahdaviani, Tim Emami and Bianca Schroeder. A Study of SSD Reliability in Large Scale Enterprise Storage Deployments. FAST 2020.. https://www.usenix.org/system/files/fast20-maneas.pdf (accessed 2026-10-08)
- [fast14-consent] FAST '14 Consent Form for Refereed Papers. https://www.usenix.org/sites/default/files/fast14_consent_author.pdf (accessed 2026-10-08)

## Terms

Historical fields below preserve recorded corpus values and source IDs. The fields do not specify whether an event is invention, announcement, availability or discontinuation; do not interpret them as universal priority dates.

### 3D NAND

URL: https://hesela.dev/terms/3d-nand/
Status: shipping

Flash memory that stacks cells vertically in layers to increase density without shrinking planar features alone.

Note: 3D describes the vertical organization of cells within a die, not merely stacking completed dies in a package. It does not specify charge storage or bits per cell: Micron documented floating-gate 3D NAND in 2016 and a charge-trap transition in 2020. Layer count alone is not a retention or endurance rating.

Limitations:
- Manufacturer architecture announcements establish a design choice, not a cross-vendor reliability ranking. (sources: [micron2016], [micron2020])

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [charge-trap-flash](https://hesela.dev/terms/charge-trap-flash/)
- [floating-gate](https://hesela.dev/terms/floating-gate/)
- [layer-to-layer-process-variation](https://hesela.dev/terms/layer-to-layer-process-variation/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] 3D NAND. https://en.wikipedia.org/wiki/3D_NAND (accessed 2026-03-26)
- [kioxia] KIOXIA. What is the 3D Flash Memory BiCS FLASH? Batch processing and vertical cell organization. https://www.kioxia.com/en-jp/rd/technology/bics-flash.html (accessed 2026-10-11)
- [micron2016] Micron. Mobile 3D NAND announcement, 9 August 2016: floating-gate architecture. https://investors.micron.com/news/press-release/2016/Micron-Introduces-Mobile-3D-NAND-Solution-for-Next-Generation-Smartphones-08-09-2016/default.aspx (accessed 2026-10-11)
- [micron2020] Micron. 176-layer NAND announcement, 9 November 2020: transition to charge trap and replacement gate. https://investors.micron.com/news/press-release/2020/Micron-Ships-Worlds-First-176-Layer-NAND-Delivering-A-Breakthrough-in-Flash-Memory-Performance-and-Density-11-09-2020/default.aspx (accessed 2026-10-11)
- [hesela3d] Hesela: 3D NAND retention, cell architecture and evidence limits. https://hesela.com/analyses/3d-nand-retention-evidence/ (accessed 2026-10-11)

### 3D XPoint

URL: https://hesela.dev/terms/3d-xpoint/
Also known as: 3D XPoint memory
Status: cancelled

Recorded firstSeen: 2015 (sources: [c1])

Recorded lastSeen: 2022 (sources: [c2])

A cross-point non-volatile memory technology announced by Intel and Micron, distinct from NAND flash in cell physics.

Note: 3D XPoint is the underlying non-volatile memory technology announced jointly by Intel and Micron in 2015: a transistor-less cross-point array of selectors and memory cells addressable at bit granularity, positioned between DRAM latency and NAND economics. Intel productized it as Optane; Micron briefly used the QuantX name before exiting. Volume manufacturing ended after Micron’s 2021 exit from the technology and Intel’s 2022 Optane wind-down. Cards and modules that remain in the field are end-of-life media—useful historically and for understanding storage-class memory attempts, not as a current industry roadmap. Do not equate 3D XPoint with NAND cell types (SLC–QLC).

Related terms:
- [optane](https://hesela.dev/terms/optane/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)

Citations:
- [c1] Intel and Micron produce breakthrough memory technology. https://www.intel.com/content/www/us/en/newsroom/news/intel-micron-produce-breakthrough-memory-technology.html (accessed 2026-03-26)
- [c2] Intel winding down Optane memory business. https://www.intel.com/content/www/us/en/newsroom/news/intel-winding-down-optane-memory-business.html (accessed 2026-03-26)
- [n3] Intel — Intel and Micron produce breakthrough memory technology (3D XPoint) press release. https://www.intc.com/news-events/press-releases/detail/324/intel-and-micron-produce-breakthrough-memory-technology (accessed 2026-10-07)
- [n4] Intel — Optane business update (wind-down). https://www.intel.com/content/www/us/en/support/articles/000091826/memory-and-storage.html (accessed 2026-10-07)

### 4Kn native sectors

URL: https://hesela.dev/terms/4kn-native/
Also known as: 4Kn, 4K native
Status: shipping

Record updated: 2026-10-12

4Kn exposes 4096-byte logical sectors and 4096-byte physical sectors without 512-byte sector emulation.

Note: The interface uses 4096-byte addressing units. A filesystem block is a separate abstraction; neither its size nor a device's sector format alone specifies an application's recovery contract.

Advantages:
- Removes the 512-byte addressing emulation used by 512e. (sources: [microsoft-af])

Limitations:
- Software and the complete access path must support the logical sector size. (sources: [microsoft-af])
- Aligned addressing alone does not establish persistent completion through volatile caches. (sources: [linux-cache])

Related terms:
- [advanced-format](https://hesela.dev/terms/advanced-format/)
- [nvme](https://hesela.dev/terms/nvme/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [physical-sector](https://hesela.dev/terms/physical-sector/)
- [512e](https://hesela.dev/terms/512e/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)

Citations:
- [c1] 4Kn native sectors. https://en.wikipedia.org/wiki/Advanced_Format (accessed 2026-03-26)
- [microsoft-af] Microsoft: Advanced format disk compatibility update, sector formats and alignment issues. https://learn.microsoft.com/en-us/windows/compatibility/advanced-format-disk-compatibility-update (accessed 2026-10-12)
- [linux-cache] Linux 6.12: Explicit volatile write back cache control. https://raw.githubusercontent.com/torvalds/linux/v6.12/Documentation/block/writeback_cache_control.rst (accessed 2026-10-12)
- [hesela-sector-alignment] Hesela: 512e, 4Kn and alignment: geometry is not durability. https://hesela.com/analyses/sector-sizes-alignment-not-durability/ (accessed 2026-10-12)

### 512e emulation

URL: https://hesela.dev/terms/512e/
Also known as: 512-byte emulation
Status: shipping

Record updated: 2026-10-12

512e exposes 512-byte logical sectors over 4096-byte physical sectors.

Note: A physical sector contains eight logical sectors. Partial-sector updates can require read-modify-write; host request counts alone do not reveal media work.

Advantages:
- Preserves 512-byte addressing for compatible software. (sources: [microsoft-af])

Limitations:
- Small writes and misaligned writes can both require partial-sector handling. (sources: [seagate-af])
- Cache coalescing can change which updates reach the media together. (sources: [seagate-af])

Related terms:
- [advanced-format](https://hesela.dev/terms/advanced-format/)
- [hdd](https://hesela.dev/terms/hdd/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [physical-sector](https://hesela.dev/terms/physical-sector/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)

Citations:
- [c1] 512e emulation. https://en.wikipedia.org/wiki/Advanced_Format (accessed 2026-03-26)
- [microsoft-af] Microsoft: Advanced format disk compatibility update, sector formats and alignment issues. https://learn.microsoft.com/en-us/windows/compatibility/advanced-format-disk-compatibility-update (accessed 2026-10-12)
- [seagate-af] Seagate: Transition to Advanced Format 4K Sector Hard Drives, emulation and read-modify-write. https://www.seagate.com/blog/advanced-format-4k-sector-hard-drives-master-ti/ (accessed 2026-10-12)
- [hesela-sector-alignment] Hesela: 512e, 4Kn and alignment: geometry is not durability. https://hesela.com/analyses/sector-sizes-alignment-not-durability/ (accessed 2026-10-12)

### Active LBA range

URL: https://hesela.dev/terms/active-lba-range/
Also known as: benchmark address range
Status: shipping

Record updated: 2026-10-12

The specified logical-block address interval available to a storage test or its preparation workload.

Note: Record the start and end addresses, not only a working-set size. A chosen test interval does not itself describe device occupancy, previous writes or the distribution of accesses inside that interval.

Limitations:
- The same address span can be accessed sequentially, uniformly randomly or with hotspots
- A host-visible interval does not identify physical NAND placement

Related terms:
- [ssd-preconditioning](https://hesela.dev/terms/ssd-preconditioning/)
- [ssd-steady-state](https://hesela.dev/terms/ssd-steady-state/)
- [over-provisioning](https://hesela.dev/terms/over-provisioning/)

Citations:
- [snia] SNIA. Solid State Storage Performance Test Specification, version 2.0.2 (1 October 2020), definitions 2.1.1, 2.1.3, 2.1.6, 2.1.13, 2.1.18 and 2.1.24.. https://www.snia.org/sites/default/files/2025-02/SNIA-SSS-PTS-2.0.2.pdf (accessed 2026-10-11)
- [hesela-windows] Hesela: SSD steady state is not a timer; original numerical examples and limits. https://hesela.com/analyses/ssd-steady-state-is-not-a-timer/ (accessed 2026-10-11)

### Active-zone limit

URL: https://hesela.dev/terms/active-zone-limit/
Also known as: maximum active zones
Status: shipping

Record updated: 2026-10-14

An active-zone limit caps the zones simultaneously in implicitly open, explicitly open or closed states in a zoned namespace.

Note: A closed, partially written zone still counts, even when no thread writes to it. Budget reclamation and metadata activity as well as foreground streams; the limit is not a free-byte counter. Raw NVMe MAR = 0 permits one active zone; 0xffffffff denotes no advertised limit, and other raw values decode to value + 1. Linux zonefs instead uses decoded zero for no limit.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [open-zone-limit](https://hesela.dev/terms/open-zone-limit/)
- [zone-capacity](https://hesela.dev/terms/zone-capacity/)
- [zone-finish](https://hesela.dev/terms/zone-finish/)

Citations:
- [zonefs] Linux kernel documentation, zonefs: sequential files, explicit-open and runtime sysfs attributes.. https://docs.kernel.org/filesystems/zonefs.html (accessed 2026-10-11)
- [bjorling] Bjorling, Aghayev, Holmberg, Ramesh, Le Moal, Ganger and Amvrosiadis. ZNS: Avoiding the Block Interface Tax for Flash-based SSDs. USENIX ATC 2021, pp. 689-703, sections 3-5 and Table 3.. https://www.usenix.org/system/files/atc21-bjorling.pdf (accessed 2026-10-11)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-11)
- [zns-spec] NVM Express, Zoned Namespace Command Set Specification, revision 1.1 (cover: 18 May 2021), Figure 48, Figure 48, sections 2.1.1.4, 3.4.1, 3.4.3 and Annex A. Copyright 2007-2021 NVM Express, Inc. ALL RIGHTS RESERVED.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-1.1-2021.06.02-Ratified.pdf (accessed 2026-10-14)

### Adaptive Read-Retry

URL: https://hesela.dev/terms/adaptive-read-retry/
Also known as: AR2
Status: research

Record updated: 2026-10-14

Adaptive Read-Retry selects shorter NAND precharge timing from profiled conditions while reserving error-correction margin.

Note: Park's research design restores default timing and requires fallback when reduced-timing retries are exhausted. [park]

Related terms:
- [read-retry](https://hesela.dev/terms/read-retry/)
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)
- [pipelined-read-retry](https://hesela.dev/terms/pipelined-read-retry/)

Citations:
- [park] Park et al. Reducing Solid-State Drive Read Latency by Optimizing Read-Retry. ASPLOS 2021, sections 6-7. DOI: 10.1145/3445814.3446719. https://people.inf.ethz.ch/~omutlu/pub/Reducing-SSD-Read-Latency-by-Optimizing-Read-Retry_asplos21.pdf (accessed 2026-10-14)
- [hesela] Hesela: NAND read-retry and stage timing. https://hesela.com/analyses/nand-read-retry-latency/ (accessed 2026-10-14)

### Adaptive Replacement Cache

URL: https://hesela.dev/terms/adaptive-replacement-cache/
Also known as: ARC
Status: research

Record updated: 2026-10-15

Adaptive Replacement Cache adjusts a recency/frequency balance using resident lists and nonresident histories.

Note: The FAST 2003 algorithm assumes equal-sized demand-paged items, not arbitrary SSD firmware. [arc]

Related terms:
- [ghost-cache-entry](https://hesela.dev/terms/ghost-cache-entry/)
- [lru-replacement](https://hesela.dev/terms/lru-replacement/)
- [cache-pollution](https://hesela.dev/terms/cache-pollution/)

Citations:
- [arc] Nimrod Megiddo and Dharmendra S. Modha. ARC: A Self-Tuning, Low Overhead Replacement Cache. FAST 2003, pp. 115-130; sections I, IV-V.. https://www.usenix.org/event/fast03/tech/full_papers/megiddo/megiddo.pdf (accessed 2026-10-15)
- [hesela] Hesela: mapping caches, scan phases and cache-history semantics (constructed examples). https://hesela.com/analyses/ssd-mapping-cache-hmb/#scan-pollution (accessed 2026-10-15)

### Adaptive scrubbing

URL: https://hesela.dev/terms/adaptive-scrubbing/
Also known as: Prediction-guided scrubbing
Status: research

Record updated: 2026-10-15

Adaptive scrubbing adjusts the rate or schedule of proactive storage verification in response to observed conditions or estimated error risk.

Note: Distinguish classifier false-positive rate from the fraction of time spent scanning faster. An alert budget must include true alerts and alert duration, not just false alarms. The ATC 2017 evaluation was a simulation, not a measurement of reduced production data loss. [mahdisoltani2017] Equal-duration examples and their assumptions are available in the accompanying arithmetic note. [hesela-budget]

Related terms:
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [mean-time-to-detection](https://hesela.dev/terms/mean-time-to-detection/)
- [false-positive-rate](https://hesela.dev/terms/false-positive-rate/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [recall](https://hesela.dev/terms/recall/)

Citations:
- [mahdisoltani2017] Mahdisoltani, Stefanovici and Schroeder. Improving Storage System Reliability with Proactive Error Prediction. USENIX ATC 2017, sections 4.1-4.3.. https://www.usenix.org/system/files/conference/atc17/atc17-mahdisoltani.pdf (accessed 2026-10-15)
- [hesela-budget] Hesela: sector-error prediction and adaptive scrub-budget arithmetic.. https://hesela.com/analyses/sector-error-prediction-scrubbing/ (accessed 2026-10-15)

### Additional sense code qualifier

URL: https://hesela.dev/terms/additional-sense-code-qualifier/
Also known as: ASCQ, SCSI ASCQ
Status: shipping

Record updated: 2026-10-13

The additional sense code qualifier (ASCQ) is an eight-bit SCSI sense-data field interpreted with the ASC to identify a more specific condition.

Note: A qualifier has meaning within its ASC pair, not as an independent error code. [t10-asc] Record the response format and available length alongside the pair; a decoder's default zero is not evidence that an absent byte was returned as zero. [linux-sense]

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [scsi-check-condition](https://hesela.dev/terms/scsi-check-condition/)
- [scsi-sense-key](https://hesela.dev/terms/scsi-sense-key/)
- [additional-sense-code](https://hesela.dev/terms/additional-sense-code/)

Citations:
- [t10-asc] T10: Additional sense data and ASC/ASCQ lookup tables. https://www.t10.org/lists/2asc.htm (accessed 2026-10-13)
- [linux-sense] Linux v6.12: scsi_normalize_sense, fixed and descriptor field extraction. https://github.com/torvalds/linux/blob/v6.12/drivers/scsi/scsi_common.c (accessed 2026-10-13)
- [hesela-sense] Media error or link error? SCSI sense codes and Linux ATA logs. https://hesela.com/analyses/scsi-sense-kernel-log-signatures/ (accessed 2026-10-13)

### Additional sense code

URL: https://hesela.dev/terms/additional-sense-code/
Also known as: ASC, SCSI ASC
Status: shipping

Record updated: 2026-10-13

The additional sense code (ASC) is an eight-bit SCSI sense-data field that refines the sense key and is interpreted together with its qualifier.

Note: Use the ASC and ASCQ as a pair and check the device-type applicability in T10's assignments. The lookup table is informative; the applicable written standard takes precedence. [t10-asc] Missing bytes in a truncated report must not be treated as an observed 00h/00h pair. [linux-sense] Software translation can be version-dependent: Linux v6.12 maps BSY to 0Bh/47h/00h, whereas the pinned 3857c2fe5449 routine maps it to 0Bh/00h/00h. Both ignore the ATA error byte when BSY is set. Keep the kernel version and original registers; a translated code is not a unique physical diagnosis. [linux-v612-ata] [linux-pinned-ata]

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [scsi-check-condition](https://hesela.dev/terms/scsi-check-condition/)
- [scsi-sense-key](https://hesela.dev/terms/scsi-sense-key/)
- [additional-sense-code-qualifier](https://hesela.dev/terms/additional-sense-code-qualifier/)

Citations:
- [t10-asc] T10: Additional sense data and ASC/ASCQ lookup tables. https://www.t10.org/lists/2asc.htm (accessed 2026-10-13)
- [linux-sense] Linux v6.12: scsi_normalize_sense, fixed and descriptor field extraction. https://github.com/torvalds/linux/blob/v6.12/drivers/scsi/scsi_common.c (accessed 2026-10-13)
- [hesela-sense] Media error or link error? SCSI sense codes and Linux ATA logs. https://hesela.com/analyses/scsi-sense-kernel-log-signatures/ (accessed 2026-10-13)
- [linux-pinned-ata] Linux pinned 3857c2fe5449: ata_to_sense_error and its callers. https://github.com/torvalds/linux/blob/3857c2fe5449541e24afc5efdb0f81a8a8f9a3a0/drivers/ata/libata-scsi.c (accessed 2026-10-13)
- [linux-v612-ata] Linux v6.12, commit adc218676eef: ATA-to-SCSI translation. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/drivers/ata/libata-scsi.c (accessed 2026-10-13)

### Asynchronous DRAM Refresh

URL: https://hesela.dev/terms/adr/
Also known as: ADR
Status: shipping

Record updated: 2026-10-13

Asynchronous DRAM Refresh is a platform power-fail mechanism that drains covered memory-controller write-pending buffers to persistent memory without protecting dirty CPU caches.

Note: In Intel's documented persistent-memory platform, data that reaches the covered controller queue can survive power loss, while cache-resident updates require software persistence operations. [intel-adr] The name does not mean ordinary DRAM automatically becomes nonvolatile; protection depends on the platform and backing medium. eADR extends the protected boundary to CPU caches. [intel-eadr]

Related terms:
- [persistence-domain](https://hesela.dev/terms/persistence-domain/)
- [eadr](https://hesela.dev/terms/eadr/)
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [intel-adr] Intel. Second Generation Xeon Processor Scalable Family Technical Overview: The Persistence Domain.. https://www.intel.com/content/www/us/en/developer/articles/news/second-generation-intel-xeon-processor-scalable-family-technical-overview.html (accessed 2026-10-13)
- [intel-eadr] Intel. Third Generation Xeon Processor Scalable Family on Two Socket Platforms: eADR.. https://www.intel.com/content/www/us/en/developer/articles/technical/third-generation-xeon-scalable-family-overview.html (accessed 2026-10-13)
- [hesela-pmem] Hesela. Persistent memory: DAX is not a durable commit.. https://hesela.com/analyses/pmem-persistence-domains-dax/ (accessed 2026-10-13)

### Advanced Format (4K)

URL: https://hesela.dev/terms/advanced-format/
Also known as: AF, 4K Advanced Format
Status: shipping

Record updated: 2026-10-12

Advanced Format is a disk-sector architecture expanded beyond legacy 512-byte sectors, with 512e and 4Kn as its familiar 4K variants.

Note: The 4K variants covered here use 4096-byte physical sectors. The format label does not identify a filesystem allocation unit or a NAND erase block. Compare logical and physical sector reports before interpreting a device as 512e or 4Kn.

Advantages:
- Larger sectors reduce repeated per-sector format overhead in the HDD design described by Seagate. (sources: [seagate-af])

Limitations:
- 512e and 4Kn expose different addressing units despite the same physical-sector size. (sources: [microsoft-af])

Related terms:
- [512e](https://hesela.dev/terms/512e/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [physical-sector](https://hesela.dev/terms/physical-sector/)

Citations:
- [c1] Advanced Format (4K). https://en.wikipedia.org/wiki/Advanced_Format (accessed 2026-03-26)
- [idema-af] IDEMA: Advanced Format Definitions, Abbreviations, and Conventions. https://idema.org/initiatives/advanced-format/af-definitions-abbreviations-and-conventions/ (accessed 2026-10-12)
- [microsoft-af] Microsoft: Advanced format disk compatibility update, sector formats and alignment issues. https://learn.microsoft.com/en-us/windows/compatibility/advanced-format-disk-compatibility-update (accessed 2026-10-12)
- [seagate-af] Seagate: Transition to Advanced Format 4K Sector Hard Drives, emulation and read-modify-write. https://www.seagate.com/blog/advanced-format-4k-sector-hard-drives-master-ti/ (accessed 2026-10-12)
- [hesela-sector-alignment] Hesela: 512e, 4Kn and alignment: geometry is not durability. https://hesela.com/analyses/sector-sizes-alignment-not-durability/ (accessed 2026-10-12)

### Advisory file lock

URL: https://hesela.dev/terms/advisory-file-lock/
Also known as: advisory locking
Status: shipping

Record updated: 2026-10-16

An advisory file lock coordinates access among cooperating participants without itself preventing access that bypasses the locking protocol.

Note: On local Linux filesystems, flock() locks follow open file descriptions; a replacement pathname can refer to a different file. Hesela's ordered subprocess observation acquires a second lock after target replacement while the old file remains locked. Retaining a separate coordination file preserves the tested conflict; deleting and recreating it loses that shared identity. [flock] [observation]

Limitations:
- A lock does not substitute for file or directory synchronization. (sources: [hesela-locks])
- NFS and SMB/CIFS can change flock interaction and enforcement; this local experiment does not test them. (sources: [flock])
- All participants must coordinate on the same stable file using compatible locking operations. (sources: [hesela-locks])

Related terms:
- [open-file-description-lock](https://hesela.dev/terms/open-file-description-lock/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [atomic-rename](https://hesela.dev/terms/atomic-rename/)
- [unlink](https://hesela.dev/terms/unlink/)
- [process-associated-record-lock](https://hesela.dev/terms/process-associated-record-lock/)

Citations:
- [flock] Linux man-pages 6.19: flock(2), ownership and filesystem differences. https://man7.org/linux/man-pages/man2/flock.2.html (accessed 2026-10-16)
- [observation] Hesela: local Linux lock-identity observation, source hash and limitations. https://hesela.dev/research/lock-identity/observation.json (accessed 2026-10-16)
- [hesela-locks] Hesela: A lock follows the opened file, not the replacement name. https://hesela.com/analyses/atomic-rename-directory-durability/#lock-identity (accessed 2026-10-16)

### Annualized failure rate (AFR)

URL: https://hesela.dev/terms/afr/
Status: shipping

Annualized failure rate (AFR) expresses observed failures relative to drive-time exposure, scaled to a year, and is not inherently a one-year failure probability.

Note: For Backblaze-style daily exposure, AFR (%) = failures / drive_days * 365 * 100. Report the event definition, cohort, observation window and year-length convention. A rate can exceed 100%; a probability cannot. Under an assumed constant individual hazard lambda per year, one-year failure probability is 1 - exp(-lambda), where lambda = AFR / 100; pooled fleet AFR alone does not establish that assumption.

Related terms:
- [mtbf](https://hesela.dev/terms/mtbf/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [drive-day](https://hesela.dev/terms/drive-day/)
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)

Citations:
- [bb-exposure] Backblaze: 10 Stories From 10 Years of Drive Stats Data, sections 3-4. https://www.backblaze.com/blog/10-stories-from-10-years-of-drive-stats-data/ (accessed 2026-10-10)
- [nist-exponential] NIST e-Handbook: Exponential distribution (8.1.6.1). https://www.itl.nist.gov/div898/handbook/apr/section1/apr161.htm (accessed 2026-10-10)
- [hesela-methods] Hesela: AFR is a rate, not a one-year failure probability. https://hesela.com/analyses/afr-rate-not-probability/ (accessed 2026-10-10)

### AHCI

URL: https://hesela.dev/terms/ahci/
Status: limited

Record updated: 2026-10-15

Advanced Host Controller Interface, the PCI class driver model SATA SSDs and HDDs used before NVMe dominance.

Note: AHCI is Intel’s register-level specification for SATA host controllers; revision 1.3.1 is the latest and is dated November 2011. It defines a system-memory structure that lets drivers detect, configure and program SATA adapters in a standard way. An AHCI host bus adapter exposes 1 to 32 ports, and where the optional per-port command list is implemented, Native Command Queuing (via the FPDMA Queued Command protocol) can hold up to 32 entries per device; the NCQ capability bit in the HBA registers tells software whether queuing may be used. The same spec lists hot plug, staggered spin-up, port multiplier support, 64-bit addressing and power management among its features. In a controller’s legacy IDE mode the limit is usually four devices (two channels, master and slave), against up to 32 ports in AHCI mode. Operating-system support is broad (Linux since kernel 2.6.19, Windows Vista and later, FreeBSD since 8.0), but switching a controller from IDE to AHCI after installing Windows can make the boot drive inaccessible unless the driver is enabled first. For SSDs, NVMe has superseded AHCI as the host interface.

Advantages:
- Standard register interface so one driver covers many SATA controllers
- Exposes SATA hot plug and Native Command Queuing (up to 32 commands per device)
- Up to 32 ports per HBA, versus about four devices in legacy IDE mode

Limitations:
- Command queue depth is capped at 32 per port
- Changing IDE to AHCI mode after an OS install can cause a boot failure
- Superseded by NVMe for SSDs

Related terms:
- [sata](https://hesela.dev/terms/sata/)
- [sata-express](https://hesela.dev/terms/sata-express/)
- [ide](https://hesela.dev/terms/ide/)
- [pata](https://hesela.dev/terms/pata/)
- [hba](https://hesela.dev/terms/hba/)
- [nvme](https://hesela.dev/terms/nvme/)
- [ssd](https://hesela.dev/terms/ssd/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)
- [native-command-queuing](https://hesela.dev/terms/native-command-queuing/)

Citations:
- [c1] Advanced Host Controller Interface (Wikipedia). https://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface (accessed 2026-10-10)
- [c2] Serial ATA AHCI Specification, Rev. 1.3.1 (Intel). https://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1-3-1.html (accessed 2026-10-10)
- [c3] Linux drivers/ata/ahci.h (AHCI_MAX_PORTS = 32, AHCI_MAX_CMDS = 32). https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/ata/ahci.h (accessed 2026-10-10)

### Air-gapped backup

URL: https://hesela.dev/terms/air-gap-backup/
Status: shipping

Offline copies physically isolated from production networks to resist ransomware.

Note: An air-gapped backup is a copy that sits on media or a network segment an attacker cannot reach from production, so stolen credentials do not let ransomware encrypt or delete it. CISA's #StopRansomware Guide (updated September 2023) tells organizations to maintain offline, encrypted backups of critical data and test their availability and integrity regularly, because many ransomware variants try to find and delete or encrypt accessible backups. In the general networking sense, an air gap means a network with no interfaces connected to other networks; data moves only on physical media carried between systems, which is labor-intensive and still needs controlled physical access. Air gaps are not absolute: published research has shown covert channels such as acoustic, thermal and radio signals, and malware such as Stuxnet and ProjectSauron has crossed gaps through removable media. In backup practice the term is often confused with immutability. One 2026 practitioner guide to the 3-2-1-1-0 rule (three copies, two media, one offsite, one immutable or air-gapped copy, zero verified restore errors) separates the two: immutable storage such as S3 Object Lock in compliance mode is online and fast to restore from but depends on the platform enforcing it, while an air gap survives platform compromise but restores slowly. The same guide cautions that a 'logical air gap' amounting to a firewall rule deserves skepticism and suggests a true offline copy for the most critical share of data. CISA separately notes that immutable cloud storage can protect data without a separate environment but should be used with caution because it may not meet some regulatory criteria and misconfiguration can be costly.

Advantages:
- Unreachable from the production network, so stolen admin credentials cannot delete or encrypt the copy
- Survives compromise of the backup platform itself, unlike online immutability that depends on the platform enforcing it
- Offline media such as tape can be rotated out of a library and stored offsite

Limitations:
- Restores are slow and testing is awkward compared with online immutable storage
- A 'logical' air gap that is only a firewall rule or reachable on a schedule is weaker than true offline media
- Physical transfer needs controlled access, and removable media has been used to cross air gaps (Stuxnet, ProjectSauron)

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)
- [cold-archive](https://hesela.dev/terms/cold-archive/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [worm-storage](https://hesela.dev/terms/worm-storage/)
- [tape-library](https://hesela.dev/terms/tape-library/)
- [tape-encryption](https://hesela.dev/terms/tape-encryption/)
- [object-storage](https://hesela.dev/terms/object-storage/)
- [snapshot](https://hesela.dev/terms/snapshot/)

Citations:
- [c1] Air gap (networking) (Wikipedia). https://en.wikipedia.org/wiki/Air_gap_(networking) (accessed 2026-10-10)
- [c2] #StopRansomware Guide (CISA, MS-ISAC, FBI, NSA). https://www.cisa.gov/stopransomware/ransomware-guide (accessed 2026-10-10)
- [c3] The 3-2-1-1-0 Backup Rule: How to Actually Implement It (Enterprise Techie, 15 July 2026). https://enterprisetechie.com/3-2-1-1-0-backup-rule/ (accessed 2026-10-10)

### All-flash array

URL: https://hesela.dev/terms/all-flash-array/
Status: shipping

A storage array built entirely from flash modules without HDD tiers.

Note: An all-flash array (AFA) is a shared storage system whose media is entirely flash, with no spinning-disk tier; it is usually sold as a SAN or NAS appliance with redundant controllers. Vendors increasingly build the media layer on NVMe and expose volumes to hosts over NVMe over Fabrics (NVMe-oF). Pure Storage's FlashArray//X datasheet describes an end-to-end NVMe and NVMe-oF array that talks to raw NAND through its DirectFlash layer, and IBM's FlashSystem 5200 guide describes FlashCore Modules that use the NVMe protocol. Because flash costs more per terabyte than disk, arrays lean on data reduction: zero and pattern removal, inline deduplication, compression and thin provisioning. NetApp's All Flash FAS datasheet lists inline adaptive compression, inline deduplication and inline data compaction and quotes typical space savings of 5 to 10 times; Pure's FlashArray//X datasheet quotes an average data reduction of 5:1 (10:1 including thin provisioning); IBM states that DRP compression and deduplication can raise effective capacity up to 5x on the FlashSystem 5200. These are vendor-stated figures, and Pure's own data-reduction guide says the only way to know the ratio on your data is to try it, quoting workload ranges of 2-4:1 for databases and 5-10:1 for virtual desktops. Reduction can be done in software on the controllers or in hardware inside each flash module: IBM describes always-on FPGA-based compression in every FlashCore Module. Effective capacity figures therefore depend on workload and should not be compared with raw capacity.

Advantages:
- No seek or rotational latency, so random I/O performance is far less dependent on spindle count
- Data reduction (deduplication, compression, thin provisioning) can raise effective capacity well above raw capacity
- NVMe back ends and NVMe-oF front ends cut protocol overhead between hosts, controllers and media

Limitations:
- Higher cost per raw terabyte than HDD-based or hybrid arrays, which makes capacity-heavy cold data expensive
- Effective capacity depends on how well the data reduces; encrypted or already compressed data reduces little
- Published reduction ratios are vendor averages or observed best cases, not guarantees for a given workload

Related terms:
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [san](https://hesela.dev/terms/san/)
- [nvme](https://hesela.dev/terms/nvme/)
- [nvme-of](https://hesela.dev/terms/nvme-of/)
- [deduplication](https://hesela.dev/terms/deduplication/)
- [hybrid-flash-array](https://hesela.dev/terms/hybrid-flash-array/)
- [flash-module](https://hesela.dev/terms/flash-module/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [raid](https://hesela.dev/terms/raid/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)

Citations:
- [c1] FlashArray//X All-Flash, NVMe Array Datasheet (Pure Storage). https://cdn2.hubspot.net/hubfs/4423734/marketing/vendor%20insights/Pure%20Storage/data%20sheets/ds-flasharray-x.pdf (accessed 2026-10-10)
- [c2] What Is Data Reduction? (Everpure / Pure Storage). https://www.everpuredata.com/knowledge/what-is-data-reduction.html (accessed 2026-10-10)
- [c3] NetApp All Flash FAS datasheet. https://www.netapp.com/media/19763-ds-3829.pdf (accessed 2026-10-10)
- [c4] IBM Storage FlashSystem 5200 Product Guide (IBM Redbooks). https://www.redbooks.ibm.com/redpapers/pdfs/redp5617.pdf (accessed 2026-10-10)

### ALUA

URL: https://hesela.dev/terms/alua/
Status: shipping

Record updated: 2026-10-11

Asymmetric Logical Unit Access is the SCSI mechanism for reporting logical-unit access states through target port groups.

Note: ALUA is the SCSI mechanism by which a target tells hosts which paths to a LUN are preferred. Target ports are collected into target port groups, and each group reports an access state; the two usable states are active/optimized and active/non-optimized. In NetApp ONTAP, for example, a LUN is hosted on one node, paths through a LIF on that node are direct and marked optimized, paths through other nodes are indirect and marked non-optimized, and non-optimized paths are used only when no optimized path is available. Linux multipath reads the state with the ALUA handler and turns it into path priorities. In one Red Hat support example, the active/optimized paths report an ALUA priority of 50 and the active/non-optimized paths 10; with path_grouping_policy set to multibus, all paths were merged into one priority group regardless of those priorities, and removing that setting restored separate groups. States can change implicitly, when the array moves them itself, or explicitly, when the host issues SET TARGET PORT GROUPS; the Linux LIO target implements both, plus standby and unavailable states, and works across Fibre Channel, iSCSI, FCoE, SAS and other SCSI transports. NVMe has an equivalent called Asymmetric Namespace Access (ANA): the Linux NVMe multipath driver follows ANA and chooses an optimized path over a non-optimized one before applying its numa, round-robin or queue-depth policy.

Advantages:
- Hosts route I/O to the controller that owns the LUN without manual path configuration
- Non-optimized paths remain available as failover when all optimized paths fail
- One mechanism works across Fibre Channel, iSCSI, FCoE and SAS transports

Limitations:
- Non-optimized paths cost extra hops between controllers, so spreading I/O equally across all paths can reduce performance
- Host multipath settings can override ALUA priorities, for example path_grouping_policy multibus puts all paths in one group
- Transport-level support and states vary by array vendor and host driver

Related terms:
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [san](https://hesela.dev/terms/san/)
- [iscsi](https://hesela.dev/terms/iscsi/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [scsi](https://hesela.dev/terms/scsi/)
- [multipath-nvme](https://hesela.dev/terms/multipath-nvme/)
- [nvme-of](https://hesela.dev/terms/nvme-of/)
- [fcoe](https://hesela.dev/terms/fcoe/)
- [dual-port](https://hesela.dev/terms/dual-port/)
- [asymmetric-namespace-access](https://hesela.dev/terms/asymmetric-namespace-access/)

Citations:
- [c1] Linux SCSI Target - Asymmetric Logical Unit Assignment. https://linux-iscsi.org/wiki/alua (accessed 2026-10-10)
- [c2] Why are there Active/Optimized and Active/Unoptimized paths on Windows Server LUNs? (NetApp KB). https://kb.netapp.com/on-prem/ontap/da/SAN/SAN-KBs/Why_are_there_Active_Optimized_and_Active_Unoptimized_on_Windows_Server_LUNs (accessed 2026-10-10)
- [c3] How to setup preferred path with multipath (Red Hat Customer Portal). https://access.redhat.com/solutions/2139931 (accessed 2026-10-10)
- [c4] Linux NVMe multipath (Linux kernel documentation). https://docs.kernel.org/admin-guide/nvme-multipath.html (accessed 2026-10-10)

### ANA group

URL: https://hesela.dev/terms/ana-group/
Also known as: Asymmetric Namespace Access group
Status: shipping

Record updated: 2026-10-15

An ANA group is a set of NVMe namespaces whose ANA access states change together for a given controller.

Note: ANAGRPID identifies the group within an NVM subsystem. The same group can have different ANA states through different controllers; a group is not a physical path or an independent failure domain. [base23]

Related terms:
- [asymmetric-namespace-access](https://hesela.dev/terms/asymmetric-namespace-access/)
- [namespace-nvme](https://hesela.dev/terms/namespace-nvme/)

Citations:
- [base23] NVM Express Base Specification 2.3 (1 August 2025), section 8.1.1: Asymmetric Namespace Access. Pinned edition, not a claim about the latest revision.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [hesela-paths] Hesela: NVMe multipath: ANA access states and Linux path policies. https://hesela.com/analyses/nvme-multipath-ana-path-selection/ (accessed 2026-10-15)

### Annual replacement rate

URL: https://hesela.dev/terms/annual-replacement-rate/
Also known as: ARR
Status: shipping

Record updated: 2026-10-12

Annual replacement rate (ARR) counts recorded device replacements relative to device exposure, scaled to one year.

Note: For exposure E in drive-years and R recorded replacements, 100 R/E expresses replacements per 100 drive-years. Declare the replacement policy: a replacement record does not certify a physical failure. Do not substitute an end-of-period headcount for exposure when the fleet changes.

Related terms:
- [afr](https://hesela.dev/terms/afr/)
- [drive-day](https://hesela.dev/terms/drive-day/)
- [interarrival-time](https://hesela.dev/terms/interarrival-time/)
- [mtbf](https://hesela.dev/terms/mtbf/)

Citations:
- [schroeder-arr] Schroeder and Gibson, FAST 2007: Disk failures in the real world, sections 2.1-2.3. https://static.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html (accessed 2026-10-12)
- [hesela-measurement-clocks] Hesela: Disk replacement rates are not disk lifetimes. https://hesela.com/analyses/mttf-vs-field-replacement-rates/ (accessed 2026-10-12)

### Anti-entropy repair

URL: https://hesela.dev/terms/anti-entropy-repair/
Also known as: Replica anti-entropy
Status: shipping

Record updated: 2026-10-16

Anti-entropy repair compares replica state over a selected scope and synchronizes differences to reduce divergence.

Note: Cassandra 5.0.0 compares common token ranges using Merkle trees and transfers differing data. Incremental repair skips data already marked repaired; full repair revisits the selected scope. [repair]

Limitations:
- One completed job need not cover the whole cluster, and incremental repair is not a complete later-corruption check. (sources: [repair])

Related terms:
- [read-repair](https://hesela.dev/terms/read-repair/)
- [hinted-handoff](https://hesela.dev/terms/hinted-handoff/)
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)
- [lsm-tombstone](https://hesela.dev/terms/lsm-tombstone/)
- [set-reconciliation](https://hesela.dev/terms/set-reconciliation/)

Citations:
- [repair] Apache Cassandra 5.0.0: Repair. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/managing/operating/repair.adoc (accessed 2026-10-13)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### Application-consistent snapshot

URL: https://hesela.dev/terms/application-consistent-snapshot/
Also known as: application-aware snapshot
Status: shipping

Record updated: 2026-10-15

An application-consistent snapshot captures an application's data through a coordinated procedure that satisfies that application's consistency requirements.

Note: For example, VSS writers prepare applications for capture and cooperate with a temporary write freeze. This does not mean capturing all RAM. A crash-consistent database image can also be recoverable through its documented log-replay procedure; application coordination and recoverability are different questions. Filesystem freeze and application quiescing are distinct stages; verify writer participation rather than inferring it from storage-level success. [microsoft-vss]

Advantages:
- Application participation can coordinate buffered data and transaction state before capture. (sources: [microsoft-vss])

Limitations:
- A storage snapshot alone does not prove that application writers participated successfully. (sources: [microsoft-vss])

Related terms:
- [snapshot](https://hesela.dev/terms/snapshot/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [backup](https://hesela.dev/terms/backup/)
- [distributed-snapshot](https://hesela.dev/terms/distributed-snapshot/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [filesystem-freeze](https://hesela.dev/terms/filesystem-freeze/)
- [application-quiescing](https://hesela.dev/terms/application-quiescing/)

Citations:
- [microsoft-vss] Microsoft: Volume Shadow Copy Service, application writers and snapshot coordination. https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service (accessed 2026-10-13)
- [postgresql-18] PostgreSQL 18: File System Level Backup, section 25.2. https://www.postgresql.org/docs/18/backup-file.html (accessed 2026-10-13)
- [hesela-recovery] Hesela: Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-13)

### Application quiescing

URL: https://hesela.dev/terms/application-quiescing/
Also known as: Application quiescence, Application quiesce
Status: shipping

Record updated: 2026-10-15

Application quiescing is application-specific preparation and temporary restriction of writes to establish a defined state for snapshot or backup capture.

Note: VSS writers illustrate this coordination by preparing application state before filesystem freezing. [microsoft-vss] QEMU can invoke a configured hook with freeze and thaw arguments, but configuration alone does not establish successful preparation or resumption of every application. [qemu-hooks] The QEMU v10.1.0 example wrapper exits zero when its hook directory is absent and skips non-executable hooks, so a successful wrapper exit does not prove that an application hook ran. [qemu-example-hook] Verify preparation and resumption separately from storage capture.

Advantages:
- Allows application-specific preparation before a snapshot is established. (sources: [microsoft-vss])

Limitations:
- Depends on participating applications and their supported backup procedure. (sources: [microsoft-vss])
- A configured guest-agent hook does not independently prove application-level success. (sources: [qemu-hooks])

Related terms:
- [application-consistent-snapshot](https://hesela.dev/terms/application-consistent-snapshot/)
- [filesystem-freeze](https://hesela.dev/terms/filesystem-freeze/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [backup](https://hesela.dev/terms/backup/)
- [restore-test](https://hesela.dev/terms/restore-test/)

Citations:
- [microsoft-vss] Microsoft: Volume Shadow Copy Service, application writers and snapshot coordination. https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service (accessed 2026-10-15)
- [qemu-hooks] QEMU Guest Agent: fsfreeze hook configuration. https://www.qemu.org/docs/master/interop/qemu-ga.html#cmdoption-qemu-ga-F (accessed 2026-10-15)
- [qemu-example-hook] QEMU v10.1.0 example fsfreeze hook: missing directory and executable hook checks. https://github.com/qemu/qemu/blob/v10.1.0/scripts/qemu-guest-agent/fsfreeze-hook (accessed 2026-10-15)
- [hesela-recovery] Hesela: Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-15)

### Areal density

URL: https://hesela.dev/terms/areal-density/
Status: shipping

Recorded firstSeen: 1956 (sources: [c1])

Bits stored per unit of disk surface area, the central metric driving HDD capacity growth.

Note: Areal density is measured in bits per square inch (or Tbit/in²). Wikipedia reports the 1956 IBM 350 at 2,000 bit/in², HDDs reaching 1 Tbit/in² in 2014, and a 1.34 Tbit/in² Seagate drive in 2015, more than 600 million times the IBM 350. Seagate describes its HAMR-based Mozaic 3+ platform as reaching 3TB per disk and beyond.

Advantages:
- Higher areal density raises capacity per platter, so fewer platters are needed for a given capacity, which lowers cost (Wikipedia, Density (computer storage)). (sources: [c1])
- On rotating media, higher density moves more bits under the head per unit of mechanical motion, which generally raises transfer speed (Wikipedia, Density (computer storage)). (sources: [c1])

Limitations:
- Packing grains closer makes their magnetism affect neighbours, so thermal stability becomes a problem; more stable media are harder to write, which is the trade-off HAMR addresses with a brief laser heat pulse (Seagate, HAMR). (sources: [c2])
- The maximum density is set by the size of the magnetic particles in the surface and by the size of the read/write head (Wikipedia, Density (computer storage)). (sources: [c1])
- NAND flash is the notable exception to the rule that denser media transfer faster (Wikipedia, Density (computer storage)). (sources: [c1])

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [pmr](https://hesela.dev/terms/pmr/)
- [hamr](https://hesela.dev/terms/hamr/)
- [mamr](https://hesela.dev/terms/mamr/)

Citations:
- [c1] Density (computer storage) — Wikipedia. https://en.wikipedia.org/wiki/Areal_density_(computer_storage) (accessed 2026-10-09)
- [c2] Seagate — Heat Assisted Magnetic Recording (HAMR). https://www.seagate.com/innovation/hamr/ (accessed 2026-10-09)

### Asymmetric Namespace Access

URL: https://hesela.dev/terms/asymmetric-namespace-access/
Also known as: ANA, NVMe ANA
Status: shipping

Record updated: 2026-10-15

Asymmetric Namespace Access is the NVMe mechanism for reporting namespace access states through different controllers.

Note: ANA reports access for a controller and ANA group, not one global state of a namespace. Non-optimized access is usable; inaccessible and persistent-loss states describe lack of user-data access through the reporting controller. Persistent loss is not proof of media destruction across all controllers. The change state denotes an ANA transition, not transport reconnection. In inaccessible or persistent-loss states, some Identify Namespace capacity fields (including NUSE and NVMCAP) are cleared when accurate capacity information is unavailable; consult an optimized or non-optimized controller rather than interpreting those zeros as an empty namespace. [base23] Linux prefers optimized paths before applying its I/O policy. ANA does not elect an application leader or enforce exclusive writes. [linux-code]

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [multipath-nvme](https://hesela.dev/terms/multipath-nvme/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [alua](https://hesela.dev/terms/alua/)
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [ana-group](https://hesela.dev/terms/ana-group/)
- [nvme-multipath-io-policy](https://hesela.dev/terms/nvme-multipath-io-policy/)

Citations:
- [linux-ana] Linux kernel documentation: Linux NVMe multipath, introduction and policies.. https://docs.kernel.org/admin-guide/nvme-multipath.html (accessed 2026-10-11)
- [hesela-fencing] Storage fencing: why a lost heartbeat does not stop writes. https://hesela.com/analyses/storage-fencing-stale-writes/ (accessed 2026-10-11)
- [base23] NVM Express Base Specification 2.3 (1 August 2025), section 8.1.1: Asymmetric Namespace Access. Pinned edition, not a claim about the latest revision.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [linux-code] Linux v6.12, drivers/nvme/host/multipath.c: ANA selection, controller nr_active accounting and subsystem iopolicy.. https://github.com/torvalds/linux/blob/v6.12/drivers/nvme/host/multipath.c (accessed 2026-10-15)
- [hesela-paths] Hesela: NVMe multipath: ANA access states and Linux path policies. https://hesela.com/analyses/nvme-multipath-ana-path-selection/ (accessed 2026-10-15)

### Asynchronous commit

URL: https://hesela.dev/terms/asynchronous-commit/
Also known as: Async commit
Status: shipping

Record updated: 2026-10-15

Asynchronous commit is an acknowledgment mode that can report a transaction as successful before its recovery log has reached durable storage.

Note: In PostgreSQL 18, synchronous_commit=off can lose recently acknowledged transactions after a crash while retaining consistent recovery, assuming the remaining safety mechanisms and storage behave correctly. This is not fsync=off. [pg-async] The setting in effect at commit controls ordinary transaction acknowledgment; PostgreSQL forces utility commands such as DROP TABLE and two-phase-commit commands such as PREPARE TRANSACTION to commit synchronously. [pg-async] Local persistence and standby progress are separate: asynchronous replication does not by itself imply asynchronous local commit. [pg-settings] Group commit with commit_delay remains a synchronous optimization; commit_delay is ignored for asynchronous commits. [pg-async]

Advantages:
- Can reduce response latency by removing the immediate WAL synchronization wait. (sources: [pg-async])

Limitations:
- A successful response is not proof that the transaction will survive a crash. (sources: [pg-async])
- An external action triggered by success cannot be undone by database recovery. (sources: [pg-async])

Related terms:
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [group-commit](https://hesela.dev/terms/group-commit/)

Citations:
- [pg-async] PostgreSQL 18: Asynchronous Commit. https://www.postgresql.org/docs/18/wal-async-commit.html (accessed 2026-10-15)
- [pg-settings] PostgreSQL 18: WAL settings, commit_delay and synchronous_commit. https://www.postgresql.org/docs/18/runtime-config-wal.html (accessed 2026-10-15)
- [hesela-wal] Hesela: Group commit shares persistence work, not transaction identity. https://hesela.com/analyses/wal-checkpoints-torn-pages/#group-commit (accessed 2026-10-15)

### Asynchronous replication

URL: https://hesela.dev/terms/asynchronous-replication/
Status: shipping

Record updated: 2026-10-16

Asynchronous replication allows primary-side completion without waiting for the corresponding update to reach a specified processing stage on a replica.

Note: The remote copy may lag, so promotion can lose acknowledged transactions that it has not received. PostgreSQL 18 streaming replication defaults to this mode. This is distinct from asynchronous local commit: local WAL can be durable while remote replication remains asynchronous. A lag observation alone is not a recovery-point guarantee. Asynchronous replication can still encounter backpressure when buffers fill, as documented for DRBD protocol A. A replication slot can retain WAL during disconnection without changing this acknowledgement policy. [pg-slots]

Related terms:
- [synchronous-replication](https://hesela.dev/terms/synchronous-replication/)
- [replication-lag](https://hesela.dev/terms/replication-lag/)
- [mirroring](https://hesela.dev/terms/mirroring/)
- [replication-slot](https://hesela.dev/terms/replication-slot/)

Citations:
- [pg-streaming] PostgreSQL 18: warm standby and synchronous replication. https://www.postgresql.org/docs/18/warm-standby.html#SYNCHRONOUS-REPLICATION (accessed 2026-10-12)
- [pg-commit] PostgreSQL 18: WAL settings, synchronous_commit. https://www.postgresql.org/docs/18/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT (accessed 2026-10-12)
- [hesela-replication] Replication acknowledgements: received, durable, applied. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-12)
- [drbd] LINBIT DRBD 9 guide: section 2.3, replication modes. https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/ (accessed 2026-10-12)
- [pg-slots] PostgreSQL 18: replication slots and WAL retention. https://www.postgresql.org/docs/18/warm-standby.html#STREAMING-REPLICATION-SLOTS (accessed 2026-10-16)

### ATA SMART

URL: https://hesela.dev/terms/ata-smart/
Status: shipping

Record updated: 2026-10-15

ATA SMART is the ATA interface for retrieving drive self-monitoring attributes, status and logs from supporting devices.

Note: ATA SMART attributes have separate raw values, normalized values and thresholds. The Pre-fail type label alone does not indicate a threshold crossing. Model and firmware context are necessary for interpreting raw fields.

Related terms:
- [smart](https://hesela.dev/terms/smart/)
- [sata](https://hesela.dev/terms/sata/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [smart-raw-value](https://hesela.dev/terms/smart-raw-value/)
- [smart-normalized-value](https://hesela.dev/terms/smart-normalized-value/)
- [smartctl-exit-status](https://hesela.dev/terms/smartctl-exit-status/)

Citations:
- [c1] ATA SMART. https://en.wikipedia.org/wiki/S.M.A.R.T. (accessed 2026-03-26)
- [smartctl] smartmontools 7.5 smartctl manual: -A attributes and -v raw-value formats. https://github.com/smartmontools/smartmontools/blob/RELEASE_7_5/smartmontools/smartctl.8.in (accessed 2026-10-11)
- [hesela] Hesela: SMART zeros, missing attributes and failure-day selection. https://hesela.com/analyses/smart-missing-values-not-zero/ (accessed 2026-10-11)

### Atomic rename

URL: https://hesela.dev/terms/atomic-rename/
Also known as: atomic file replacement, rename atomicity
Status: shipping

Record updated: 2026-10-16

Atomic rename is a filesystem namespace operation whose successful replacement of an existing destination changes the file reached through that pathname without exposing an intermediate missing destination to concurrent lookups.

Note: For Linux rename(), source and destination must be on the same mounted filesystem; even separate mount points of one filesystem produce EXDEV. Existing descriptors retain their original file references, and other hard links are unaffected. Both pathnames may temporarily refer to the source, so the guarantee is not a two-path snapshot. Success establishes visibility, not crash durability: the file-data and directory-persistence requirements must be handled separately. A lock held on the old file does not automatically coordinate writers opening its replacement; see the scoped lock-identity observation. [hesela-locks]

Advantages:
- Publishes a replacement without first removing the destination name.

Limitations:
- Does not redirect already-open descriptors or update other hard links.
- Does not by itself make replacement data or directory entries crash-persistent.
- On NFS, a reported rename failure can follow successful server execution; NFSv4.1 replay guarantees depend on session and reply-cache recovery.

Related terms:
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [inode](https://hesela.dev/terms/inode/)
- [hard-link](https://hesela.dev/terms/hard-link/)
- [unlink](https://hesela.dev/terms/unlink/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [advisory-file-lock](https://hesela.dev/terms/advisory-file-lock/)
- [open-file-description-lock](https://hesela.dev/terms/open-file-description-lock/)

Citations:
- [linux-rename-2] Linux man-pages 6.19: rename(2). https://man7.org/linux/man-pages/man2/rename.2.html (accessed 2026-10-15)
- [linux-open-2] Linux man-pages 6.19: open(2). https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-15)
- [linux-fsync-2] Linux man-pages 6.19: fsync(2). https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-15)
- [hesela-namespace] Hesela: The name changes; existing readers do not. https://hesela.com/analyses/atomic-rename-directory-durability/#namespace-identity (accessed 2026-10-15)
- [rfc8881-replay] RFC 8881: NFSv4.1 replay and persistence, sections 2.10.6 and 2.10.6.5. https://www.rfc-editor.org/rfc/rfc8881.html#section-2.10.6.5 (accessed 2026-10-15)
- [hesela-locks] Hesela: A lock follows the opened file, not the replacement name. https://hesela.com/analyses/atomic-rename-directory-durability/#lock-identity (accessed 2026-10-16)

### Authenticated encryption

URL: https://hesela.dev/terms/authenticated-encryption/
Status: shipping

Record updated: 2026-10-15

Authenticated encryption combines confidentiality with cryptographic integrity protection for the protected message.

Note: AEAD additionally authenticates associated data without encrypting it; another layer may protect its confidentiality. RFC 5116 defines decryption as returning plaintext or failure and requires compliance with the chosen algorithm's nonce rules. It leaves anti-replay services and access decisions outside the interface. [rfc5116] A storage design therefore needs a separate trusted freshness mechanism if it must reject older valid data. [broz2018]

Limitations:
- Authentication does not repair damaged bytes or prove that a write was durable; those are separate storage contracts. (sources: [hesela-encryption])

Related terms:
- [xts-aes](https://hesela.dev/terms/xts-aes/)
- [cryptographic-nonce](https://hesela.dev/terms/cryptographic-nonce/)
- [dm-crypt](https://hesela.dev/terms/dm-crypt/)
- [luks](https://hesela.dev/terms/luks/)
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)
- [cryptographic-hash](https://hesela.dev/terms/cryptographic-hash/)
- [lost-write](https://hesela.dev/terms/lost-write/)
- [replay-attack](https://hesela.dev/terms/replay-attack/)
- [rollback-protection](https://hesela.dev/terms/rollback-protection/)

Citations:
- [rfc5116] RFC 5116: AEAD scope, interface and nonce requirements, sections 1.2, 2 and 3.1. https://www.rfc-editor.org/rfc/rfc5116.html (accessed 2026-10-15)
- [broz2018] Broz, Patocka and Matyas: Practical cryptographic data integrity protection with full disk encryption (extended version), 2018, section 2.4. https://arxiv.org/pdf/1807.00309v1 (accessed 2026-10-15)
- [hesela-encryption] Hesela: Encryption is not authentication. https://hesela.com/analyses/checksums-identity-and-lost-writes/#encryption-boundaries (accessed 2026-10-15)

### Average precision

URL: https://hesela.dev/terms/average-precision/
Also known as: AP, non-interpolated average precision
Status: shipping

Record updated: 2026-10-12

Non-interpolated average precision summarizes ranked prediction scores by weighting precision at each threshold by the corresponding increase in recall.

Note: The scikit-learn convention is AP = sum((R_n - R_(n-1)) * P_n), with points ordered by increasing recall and initial recall zero. It uses score thresholds, not just one binary decision. Trapezoidal PR-AUC instead integrates linear segments between precision-recall points; it need not equal AP. State the algorithm, positive class and any averaging across classes. [sklearn-ap]

Limitations:
- AP does not specify an operating threshold or alert budget, and an evaluation sample without positive outcomes cannot establish failure-detection quality. (sources: [sklearn-ap])

Related terms:
- [precision](https://hesela.dev/terms/precision/)
- [recall](https://hesela.dev/terms/recall/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)

Citations:
- [sklearn-ap] scikit-learn: average_precision_score; non-interpolated AP versus trapezoidal integration.. https://scikit-learn.org/stable/modules/generated/sklearn.metrics.average_precision_score.html (accessed 2026-10-12)
- [hesela-prediction] Hesela: disk failure prediction, metric denominators and a synthetic alert-count example.. https://hesela.com/analyses/ml-disk-failure-prediction/ (accessed 2026-10-12)

### Background fsck

URL: https://hesela.dev/terms/background-fsck/
Also known as: background filesystem check
Status: shipping

Record updated: 2026-10-15

Background fsck is a filesystem-specific consistency-checking mode that performs permitted repairs while the filesystem remains in use.

Note: The 2002 BSD design uses a snapshot and kernel-assisted reclamation. [background2002] The FreeBSD 14.3 manual requires eligible soft-updates filesystems and stops background cleaning on unexpected errors. [freebsd143]

Limitations:
- This is not a generic permission to run an arbitrary repair tool against a mounted filesystem. (sources: [background2002])

Related terms:
- [soft-updates](https://hesela.dev/terms/soft-updates/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [filesystem-consistency-invariant](https://hesela.dev/terms/filesystem-consistency-invariant/)

Citations:
- [background2002] McKusick. Running "fsck" in the Background. BSDCon 2002, pp. 55-64, sections 4-7.. https://static.usenix.org/events/bsdcon/mckusick/mckusick_html/index.html (accessed 2026-10-15)
- [freebsd143] FreeBSD 14.3-RELEASE fsck_ffs(8): background checking, eligibility and exit status.. https://man.freebsd.org/cgi/man.cgi?query=fsck_ffs&sektion=8&manpath=FreeBSD+14.3-RELEASE (accessed 2026-10-15)
- [hesela-soft] Hesela: Soft updates and metadata ordering. https://hesela.com/analyses/soft-updates-metadata-ordering/ (accessed 2026-10-15)

### Backup manifest

URL: https://hesela.dev/terms/backup-manifest/
Status: shipping

Record updated: 2026-10-14

A backup manifest is a machine-readable inventory of expected backup contents and associated verification metadata.

Note: PostgreSQL uses UTF-8 JSON, with file paths, sizes and optional checksum fields; recorded modification times are informational. The format also identifies required WAL ranges. Other backup formats need not use this schema.

Advantages:
- Provides explicit expected file contents for automated checks. (sources: [manifest], [files])

Limitations:
- Optional per-file checksums must not be assumed present. (sources: [files])
- A hash match cannot authenticate a manifest that an attacker could also replace. (sources: [base])

Related terms:
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [incremental-backup](https://hesela.dev/terms/incremental-backup/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [full-backup](https://hesela.dev/terms/full-backup/)
- [synthetic-full-backup](https://hesela.dev/terms/synthetic-full-backup/)

Citations:
- [manifest] PostgreSQL 18: Backup Manifest Format. https://www.postgresql.org/docs/18/backup-manifest-format.html (accessed 2026-10-13)
- [files] PostgreSQL 18: Backup Manifest File Object. https://www.postgresql.org/docs/18/backup-manifest-files.html (accessed 2026-10-13)
- [ranges] PostgreSQL 18: Backup Manifest WAL Range Object. https://www.postgresql.org/docs/18/backup-manifest-wal-ranges.html (accessed 2026-10-13)
- [base] PostgreSQL 18: pg_basebackup, manifest checksums and trust. https://www.postgresql.org/docs/18/app-pgbasebackup.html (accessed 2026-10-13)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-13)

### Backup verification

URL: https://hesela.dev/terms/backup-verification/
Also known as: backup integrity verification
Status: shipping

Record updated: 2026-10-14

Backup verification checks stored backup material against specified integrity and completeness rules.

Note: A passing result describes the checks performed, not proven application recovery. PostgreSQL 18 pg_verifybackup checks a manifest, files and required WAL; WAL parsing is version-specific and supported for plain-format backups, not tar backups. Record any --no-parse-wal, --skip-checksums or --ignore options. It deliberately ignores postgresql.auto.conf, standby.signal and recovery.signal, so success does not validate recovery configuration. Required backup WAL checks do not prove coverage to a later recovery target. [verify]

Advantages:
- Can identify missing or altered files before recovery is attempted. (sources: [verify])

Limitations:
- Does not replace a restore test. (sources: [verify])
- A result is conditional on a trustworthy manifest. (sources: [base])

Related terms:
- [backup-manifest](https://hesela.dev/terms/backup-manifest/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [incremental-backup](https://hesela.dev/terms/incremental-backup/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [backup](https://hesela.dev/terms/backup/)
- [recovery-point-objective](https://hesela.dev/terms/recovery-point-objective/)
- [recovery-time-objective](https://hesela.dev/terms/recovery-time-objective/)
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)
- [wal-archiving](https://hesela.dev/terms/wal-archiving/)

Citations:
- [verify] PostgreSQL 18: pg_verifybackup, checks and exclusions. https://www.postgresql.org/docs/18/app-pgverifybackup.html (accessed 2026-10-13)
- [base] PostgreSQL 18: pg_basebackup, manifest checksums and trust. https://www.postgresql.org/docs/18/app-pgbasebackup.html (accessed 2026-10-13)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-13)

### Backup

URL: https://hesela.dev/terms/backup/
Also known as: data backup, backup copy
Status: shipping

Record updated: 2026-10-14

A backup is a retained copy of data or software intended to support later recovery.

Note: A snapshot can be a backup source or recovery copy; its name alone does not establish independence from the original storage. OpenZFS send streams can be stored or received elsewhere. Hesela's engineering criterion is to name the failure the copy must survive, including loss of the source pool or deletion by a shared administrator.

Advantages:
- A retained copy provides an input to a recovery process. (sources: [nist-backup])

Limitations:
- Transporting a snapshot does not by itself establish independent retention or access control. (sources: [zfs-send])

Related terms:
- [snapshot](https://hesela.dev/terms/snapshot/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [recovery-point-objective](https://hesela.dev/terms/recovery-point-objective/)
- [recovery-time-objective](https://hesela.dev/terms/recovery-time-objective/)
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [incremental-backup](https://hesela.dev/terms/incremental-backup/)
- [full-backup](https://hesela.dev/terms/full-backup/)
- [synthetic-full-backup](https://hesela.dev/terms/synthetic-full-backup/)
- [differential-backup](https://hesela.dev/terms/differential-backup/)

Citations:
- [nist-backup] NIST CSRC glossary: Backup (SP 800-34 Rev. 1 definition). https://csrc.nist.gov/glossary/term/backup (accessed 2026-10-13)
- [zfs-send] OpenZFS v2.3: zfs-send(8), full and incremental streams. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-send.8.html (accessed 2026-10-13)
- [hesela-recovery] Hesela: Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-13)

### Bad block management

URL: https://hesela.dev/terms/bad-block-management/
Status: shipping

Firmware maps out factory and grown NAND defects so hosts see a contiguous logical address space.

Note: NAND flash is shipped with some blocks already unusable, and more fail during its life. Linux MTD documentation notes that NAND chips have physical eraseblocks marked bad by the manufacturer, that manufacturers usually guarantee the first few blocks are good and cap the total number of bad blocks, and that a 256 MiB (2048 x 128 KiB) Samsung OneNAND part is guaranteed no more than 40 bad blocks over its endurance lifetime, a common ratio of 20 per 1024 blocks, about 2% of the flash. Raw-flash software therefore reserves spare blocks: UBI reserves 20 physical eraseblocks per 1024 by default, a kernel config option adjustable per device. At runtime UBI marks a block bad in two cases: an erase that fails with an I/O error (marked immediately), and a failed write, after which it moves the data elsewhere and queues the block for a background torture test (erase, check for all 0xFF, write and verify the patterns 0xA5, 0x5A and 0x00). A block that survives the test is kept; a bit-flip during the test is reason to mark it bad. On SSDs, SD cards and USB drives the controller's firmware does this work behind the logical block interface, together with wear leveling, garbage collection and error correction, so hosts never see the bad-block map. Hard disks have an analogous mechanism: a sector that cannot be written is remapped to a spare sector, with a factory P-list for defects found in production and a G-list for those grown in use, and SMART reports how many sectors were reallocated. Once spare capacity is exhausted a device can no longer remap and starts returning write errors.

Advantages:
- Hosts see a contiguous logical address space despite factory and grown defects
- Spare-block reserve lets a device keep working after individual blocks wear out
- Failed blocks are retired without losing the data they held when the write path detects the failure

Limitations:
- Spare capacity is finite; once the reserve is used up writes fail
- Reserved blocks reduce usable capacity (UBI default: 20 per 1024 blocks, about 2%)
- The bad-block map is hidden inside the controller, so hosts only see it through SMART or vendor logs

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [ssd](https://hesela.dev/terms/ssd/)
- [wear-leveling](https://hesela.dev/terms/wear-leveling/)
- [over-provisioning](https://hesela.dev/terms/over-provisioning/)
- [flash-controller](https://hesela.dev/terms/flash-controller/)
- [smart](https://hesela.dev/terms/smart/)
- [nor-flash](https://hesela.dev/terms/nor-flash/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)

Citations:
- [c1] Flash file system (Wikipedia). https://en.wikipedia.org/wiki/Flash_file_system (accessed 2026-10-10)
- [c2] UBI - Unsorted Block Images (Linux MTD documentation). http://www.linux-mtd.infradead.org/doc/ubi.html (accessed 2026-10-10)
- [c3] Bad sector (Wikipedia). https://en.wikipedia.org/wiki/Bad_sector (accessed 2026-10-10)

### Barium ferrite tape

URL: https://hesela.dev/terms/barium-ferrite-tape/
Status: shipping

Modern tape coatings enabling higher coercivity and capacity in LTO generations.

Related terms:
- [lto](https://hesela.dev/terms/lto/)
- [tape](https://hesela.dev/terms/tape/)

Citations:
- [c1] Barium ferrite tape. https://en.wikipedia.org/wiki/Linear_Tape-Open (accessed 2026-03-26)

### BD-R HTL

URL: https://hesela.dev/terms/bd-r-htl/
Also known as: high-to-low BD-R
Status: unknown

Record updated: 2026-10-15

BD-R HTL is a recordable Blu-ray type whose written marks have lower optical reflectivity than the unrecorded material.

Note: JVC describes the conventional inorganic recording approach as high-to-low, contrasting it with organic-dye LTH [jvc]. HTL is not a brand, an archival certification or a quantified lifetime.

Related terms:
- [bd-r-lth](https://hesela.dev/terms/bd-r-lth/)
- [blu-ray-archive](https://hesela.dev/terms/blu-ray-archive/)
- [m-disc](https://hesela.dev/terms/m-disc/)

Citations:
- [jvc] JVC (7 October 2008): BD-R LTH TYPE announcement, terminology and compatibility notes.. https://www3.jvckenwood.com/press/2008/bv-r130lw.html (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates and format-specific evidence. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### BD-R LTH

URL: https://hesela.dev/terms/bd-r-lth/
Also known as: low-to-high BD-R, BD-R LTH TYPE
Status: unknown

Record updated: 2026-10-15

BD-R LTH is an organic-dye recordable Blu-ray type whose written marks have higher optical reflectivity than the unrecorded material.

Note: JVC identifies LTH as requiring explicit device support, sometimes enabled by firmware [jvc]. A Blu-ray label alone does not establish compatibility with this recording type; incompatibility is not evidence of aging.

Related terms:
- [bd-r-htl](https://hesela.dev/terms/bd-r-htl/)
- [blu-ray-archive](https://hesela.dev/terms/blu-ray-archive/)

Citations:
- [jvc] JVC (7 October 2008): BD-R LTH TYPE announcement, terminology and compatibility notes.. https://www3.jvckenwood.com/press/2008/bv-r130lw.html (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates and format-specific evidence. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### Bit error rate

URL: https://hesela.dev/terms/bit-error-rate/
Also known as: BER, bit error ratio
Status: shipping

Record updated: 2026-10-12

Bit error rate (BER) expresses erroneous bits relative to the total bits considered at a specified observation point.

Note: Always state the observation point, sample size and interval; the term BER alone does not mean before error correction. Raw bit error rate identifies the pre-correction boundary. [schroeder2016] UBER requires its own error-event counting convention and bit denominator. [solidigm-p5810]

Limitations:
- Raw BER and post-correction outcomes are distinct; a codeword failure ratio is not itself a count of erroneous bits. (sources: [cai2017])

Related terms:
- [ldpc](https://hesela.dev/terms/ldpc/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [hdd](https://hesela.dev/terms/hdd/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)
- [codeword](https://hesela.dev/terms/codeword/)
- [raw-bit-error-rate](https://hesela.dev/terms/raw-bit-error-rate/)
- [uncorrectable-bit-error-rate](https://hesela.dev/terms/uncorrectable-bit-error-rate/)

Citations:
- [c1] Bit error rate. https://en.wikipedia.org/wiki/Bit_error_rate (accessed 2026-03-26)
- [nist] NIST CSRC glossary: bit error rate, citing CNSSI 4009-2022.. https://csrc.nist.gov/glossary/term/bit_error_rate (accessed 2026-10-11)
- [cai2017] Cai, Ghose, Haratsch, Luo and Mutlu. Error Characterization, Mitigation, and Recovery in Flash Memory Based Solid-State Drives. Author manuscript arXiv:1706.08642, 2017, sections 6.2-6.3.. https://arxiv.org/abs/1706.08642 (accessed 2026-10-11)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-11)
- [snia-ber] SNIA Dictionary: bit error rate.. https://www.snia.org/education/online-dictionary/term/bit-error-rate (accessed 2026-10-12)
- [solidigm-p5810] Solidigm D7-P5810 product brief, page 3 reliability table and page 4 qualification note.. https://www.solidigm.com/content/dam/solidigm/en/site/products/data-center/product-briefs/d7-5810/documents/solidigm-d7-p5810-product-brief.pdf (accessed 2026-10-12)
- [schroeder2016] Schroeder, Lagisetty and Merchant. Flash Reliability in Production: The Expected and the Unexpected. USENIX FAST 2016, sections 4 and 5.2-5.3.. https://www.usenix.org/system/files/conference/fast16/fast16-papers-schroeder.pdf (accessed 2026-10-12)

### Bit-patterned media

URL: https://hesela.dev/terms/bit-patterned-media/
Status: research

A proposed HDD technology isolating magnetic islands lithographically instead of continuous grains.

Related terms:
- [hamr](https://hesela.dev/terms/hamr/)
- [pmr](https://hesela.dev/terms/pmr/)

Citations:
- [c1] Bit-patterned media. https://en.wikipedia.org/wiki/Bit-patterned_media (accessed 2026-03-26)

### Linux block-device read-only flag

URL: https://hesela.dev/terms/block-device-read-only/
Also known as: Block-device read-only state
Status: shipping

Record updated: 2026-10-15

The Linux block-device read-only flag is a software-controlled device state exposed through block-device ioctls to restrict write access.

Note: The util-linux v2.41.1 manual warns that changing the flag may leave existing active access unaffected, including a filesystem already in read-write use. [blockdev] A flag value alone is not evidence of a validated forensic write-blocking workflow; NIST publishes software write-blocker test resources, so software and unvalidated are not synonyms. [write-block-testing]

Limitations:
- Device state, filesystem state and subvolume properties have distinct scopes. (sources: [blockdev], [mount-scope])

Related terms:
- [read-only-mount](https://hesela.dev/terms/read-only-mount/)
- [btrfs-read-only-subvolume](https://hesela.dev/terms/btrfs-read-only-subvolume/)
- [dm-integrity-recovery-mode](https://hesela.dev/terms/dm-integrity-recovery-mode/)

Citations:
- [blockdev] util-linux v2.41.1: blockdev(8), read-only flag and active-access caveat. https://kernel.googlesource.com/pub/scm/utils/util-linux/util-linux/+/refs/tags/v2.41.1/disk-utils/blockdev.8.adoc (accessed 2026-10-15)
- [mount-scope] util-linux v2.41.1: mount(8), Read-only Setting Notes. https://kernel.googlesource.com/pub/scm/utils/util-linux/util-linux/+/refs/tags/v2.41.1/sys-utils/mount.8.adoc (accessed 2026-10-15)
- [write-block-testing] NIST CFTT: Software Write Block testing resources. https://www.nist.gov/itl/csd/secure-systems-and-applications/computer-forensics-tool-testing-program-cftt/cftt-9 (accessed 2026-10-15)
- [hesela] Hesela: Btrfs tree logs and read-only scope boundaries. https://hesela.com/analyses/btrfs-tree-log-read-only-replay/#read-only-scopes (accessed 2026-10-15)

### Block storage

URL: https://hesela.dev/terms/block-storage/
Status: shipping

Fixed-size addressable blocks presented to hosts or hypervisors without file semantics.

Related terms:
- [san](https://hesela.dev/terms/san/)
- [iscsi](https://hesela.dev/terms/iscsi/)
- [nvme](https://hesela.dev/terms/nvme/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Block storage. https://en.wikipedia.org/wiki/Block_(data_storage) (accessed 2026-03-26)

### Bloom filter

URL: https://hesela.dev/terms/bloom-filter/
Also known as: Bloom membership filter
Status: shipping

Record updated: 2026-10-16

A compact approximate-membership structure that can reject absent keys but may report a false positive, without false negatives for correctly inserted keys in an intact standard filter.

Note: A positive answer requires checking the underlying data. The false-positive denominator is queries for keys absent from the represented set, not all queries. This is not an integrity checksum. The represented set may be whole keys or extracted prefixes; prefix membership and range emptiness are not interchangeable. The pinned RocksDB filter-policy API requires compatibility with comparator equality. [filter-policy]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [sstable](https://hesela.dev/terms/sstable/)
- [ribbon-filter](https://hesela.dev/terms/ribbon-filter/)
- [partitioned-filter](https://hesela.dev/terms/partitioned-filter/)
- [prefix-bloom-filter](https://hesela.dev/terms/prefix-bloom-filter/)
- [prefix-extractor](https://hesela.dev/terms/prefix-extractor/)
- [succinct-range-filter](https://hesela.dev/terms/succinct-range-filter/)
- [invertible-bloom-lookup-table](https://hesela.dev/terms/invertible-bloom-lookup-table/)

Citations:
- [bloom] Burton H. Bloom. Space/time trade-offs in hash coding with allowable errors. Communications of the ACM 13(7), 422-426 (1970), method 2. DOI: 10.1145/362686.362692.. https://courses.cs.washington.edu/courses/csep521/21wi/readings/bloom_cacm.pdf (accessed 2026-10-12)
- [rocks-bloom] RocksDB project. RocksDB Bloom Filter: statistics, full filters and implementation trade-offs. Documentation reviewed 12 October 2026.. https://github.com/facebook/rocksdb/wiki/RocksDB-Bloom-Filter (accessed 2026-10-12)
- [hesela] Hesela: Bloom filters and the cost of an absent LSM lookup. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-12)
- [filter-policy] RocksDB v9.7.3. FilterPolicy: custom comparator compatibility warning.. https://github.com/facebook/rocksdb/blob/v9.7.3/include/rocksdb/filter_policy.h (accessed 2026-10-13)

### Blu-ray data archive

URL: https://hesela.dev/terms/blu-ray-archive/
Status: limited

Record updated: 2026-10-15

A Blu-ray data archive stores retained digital content on recordable BD-R or rewritable BD-RE optical media.

Note: An archive may use individual discs or a library; robotics is not part of the format definition. BD-R includes inorganic and organic-dye variants [cci]. HTL and LTH name opposite reflectivity changes during recording, not preservation grades [jvc]. CCI distinguishes Blu-ray LDC/BIS scans from CD/DVD metrics and warns that unsupported formats can resemble disc degradation [cci]. Retain format, reader, recording details and independent content-verification evidence.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [m-disc](https://hesela.dev/terms/m-disc/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [bd-r-htl](https://hesela.dev/terms/bd-r-htl/)
- [bd-r-lth](https://hesela.dev/terms/bd-r-lth/)
- [optical-disc-lifetime-estimate](https://hesela.dev/terms/optical-disc-lifetime-estimate/)

Citations:
- [cci] Joe Iraci. CCI Notes 19/1 (2020): Longevity of Recordable CDs, DVDs and Blu-rays; BD-Rs and recorder compatibility.. https://www.canada.ca/en/conservation-institute/services/conservation-preservation-publications/canadian-conservation-institute-notes/longevity-recordable-cds-dvds.html (accessed 2026-10-15)
- [jvc] JVC (7 October 2008): BD-R LTH TYPE announcement, terminology and compatibility notes.. https://www3.jvckenwood.com/press/2008/bv-r130lw.html (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates and format-specific evidence. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### Bounded crash testing

URL: https://hesela.dev/terms/bounded-crash-testing/
Also known as: bounded black-box crash testing, B3 crash testing
Status: research

Record updated: 2026-10-14

Bounded crash testing systematically explores recovery behavior within an explicitly limited set of workloads, initial states and crash points.

Note: CrashMonkey and ACE implement this approach for file systems; exhaustive coverage within selected bounds is not a proof covering every possible crash.

Related terms:
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [crash-test-oracle](https://hesela.dev/terms/crash-test-oracle/)
- [fsync](https://hesela.dev/terms/fsync/)
- [fault-injection](https://hesela.dev/terms/fault-injection/)

Citations:
- [mohan] Jayashree Mohan, Ashlie Martinez, Soujanya Ponnapalli, Pandian Raju and Vijay Chidambaram. Finding Crash-Consistency Bugs with Bounded Black-Box Crash Testing. OSDI 2018, pp. 33-50; sections 3-6.. https://www.usenix.org/system/files/osdi18-mohan.pdf (accessed 2026-10-12)
- [ace-docs] CrashMonkey project. ACE documentation: sequence lengths count core operations and the input space is bounded.. https://github.com/utsaslab/crashmonkey/blob/master/docs/Ace.md (accessed 2026-10-12)
- [hesela] Hesela. Crash-consistency tests: the oracle is part of the result.. https://hesela.com/analyses/crash-testing-oracles-and-bounds/ (accessed 2026-10-12)

### Btrfs NODATASUM

URL: https://hesela.dev/terms/btrfs-nodatasum/
Also known as: NODATASUM, Btrfs no-data-checksum flag
Status: shipping

Record updated: 2026-10-13

Btrfs NODATASUM marks file data as excluded from the filesystem's data checksumming.

Note: NODATACOW implies NODATASUM, but disabling data checksums is not synonymous with disabling copy-on-write; the mount option applies to newly created files. Metadata remains checksummed.

Limitations:
- Scrub cannot checksum-validate the affected file data or use those missing checksums to select a correct mirror after silent damage. (sources: [btrfs-scrub])

Related terms:
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [checksum](https://hesela.dev/terms/checksum/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [mirroring](https://hesela.dev/terms/mirroring/)

Citations:
- [btrfs-mount] Btrfs documentation: btrfs(5), datacow/nodatacow and datasum/nodatasum. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html (accessed 2026-10-13)
- [btrfs-scrub] Btrfs documentation: btrfs-scrub(8), checksum exclusions and read-only limitations. https://btrfs.readthedocs.io/en/latest/btrfs-scrub.html (accessed 2026-10-13)
- [btrfs-dedup] Btrfs documentation: Deduplication, compatibility of COW files with NODATASUM. https://btrfs.readthedocs.io/en/latest/Deduplication.html (accessed 2026-10-13)
- [hesela-scrub] Hesela: Disk scrubbing, checksum coverage and consistency boundaries. https://hesela.com/analyses/scrubbing-detection-not-durability/ (accessed 2026-10-13)

### Btrfs read-only subvolume

URL: https://hesela.dev/terms/btrfs-read-only-subvolume/
Also known as: Btrfs subvolume ro property
Status: shipping

Record updated: 2026-10-15

A Btrfs read-only subvolume is a subvolume whose ro property prevents modification of its file contents and directory hierarchy.

Note: The property belongs to the subvolume, not its access path: a read-only mount does not set it. A parent snapshot does not include nested subvolume contents; those locations become stubs. [property] [subvolume]

Limitations:
- This is not device-wide write protection or an independent backup. (sources: [subvolume])

Related terms:
- [btrfs](https://hesela.dev/terms/btrfs/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [read-only-mount](https://hesela.dev/terms/read-only-mount/)
- [block-device-read-only](https://hesela.dev/terms/block-device-read-only/)

Citations:
- [property] Btrfs documentation: subvolume ro property. https://btrfs.readthedocs.io/en/stable/btrfs-property.html (accessed 2026-10-15)
- [subvolume] Btrfs documentation: subvolume flags and non-recursive snapshots. https://btrfs.readthedocs.io/en/stable/btrfs-subvolume.html (accessed 2026-10-15)
- [hesela] Hesela: Btrfs tree logs and read-only scope boundaries. https://hesela.com/analyses/btrfs-tree-log-read-only-replay/#read-only-scopes (accessed 2026-10-15)

### Btrfs tree log

URL: https://hesela.dev/terms/btrfs-tree-log/
Also known as: Btrfs log tree
Status: shipping

Record updated: 2026-10-15

The Btrfs tree log is a per-subvolume recovery structure that can persist file or directory changes for fsync without a full filesystem transaction commit.

Note: The Linux v6.16 fsync path can also fall back to a full commit. Mount-time replay can write even on a read-only mount. Upstream Linux 6.16 removed standalone nologreplay; rescue=nologreplay remains available and requires read-only mounting. Suppressing replay can hide recent logged changes, while btrfs rescue zero-log clears the log and may lose them. [fsync] [mount] [versions] [rescue]

Limitations:
- A source-registration audit does not test actual recovery or distribution backports. (sources: [parser])
- notreelog and rescue=nologreplay control different flags; rescue=all additionally disables checksum checks. (sources: [parser])

Related terms:
- [btrfs](https://hesela.dev/terms/btrfs/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [fsync](https://hesela.dev/terms/fsync/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)

Citations:
- [tree-log] Linux v6.16: Btrfs tree-log.c, design comment and replay implementation. https://github.com/torvalds/linux/blob/v6.16/fs/btrfs/tree-log.c (accessed 2026-10-15)
- [fsync] Linux v6.16: Btrfs file.c, btrfs_sync_file and transaction-commit fallback. https://github.com/torvalds/linux/blob/v6.16/fs/btrfs/file.c (accessed 2026-10-15)
- [mount] Btrfs documentation: btrfs(5), tree logging and rescue mount options. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html (accessed 2026-10-15)
- [versions] Btrfs feature-by-version: rescue in 5.9 and standalone nologreplay removal in 6.16. https://btrfs.readthedocs.io/en/latest/Feature-by-version.html (accessed 2026-10-15)
- [parser] Linux v6.16: Btrfs super.c, option registration and read-only checks. https://github.com/torvalds/linux/blob/v6.16/fs/btrfs/super.c (accessed 2026-10-15)
- [rescue] Btrfs documentation: btrfs-rescue(8), zero-log and possible loss of changes. https://btrfs.readthedocs.io/en/latest/btrfs-rescue.html (accessed 2026-10-15)
- [hesela] Hesela: Btrfs tree logs, read-only replay and version boundaries. https://hesela.com/analyses/btrfs-tree-log-read-only-replay/ (accessed 2026-10-15)

### Btrfs

URL: https://hesela.dev/terms/btrfs/
Also known as: B-tree filesystem
Status: shipping

Record updated: 2026-10-15

Btrfs is a Linux filesystem built around copy-on-write B-trees, with integrated snapshots, checksumming and multi-device storage.

Note: Copy-on-write does not remove the need for recovery: Btrfs uses a separate tree log for eligible fsync updates before a full transaction commit. Checksum coverage and mount-time recovery depend on the features and options in use. [bacik] [tree-log] The subvolume ro property is separate from read-only mounting. [subvolume]

Limitations:
- File data marked NODATASUM is outside data-checksum coverage; copy-on-write is not itself an application transaction or independent backup. (sources: [mount])

Related terms:
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [btrfs-nodatasum](https://hesela.dev/terms/btrfs-nodatasum/)
- [btrfs-tree-log](https://hesela.dev/terms/btrfs-tree-log/)
- [checksum](https://hesela.dev/terms/checksum/)
- [btrfs-read-only-subvolume](https://hesela.dev/terms/btrfs-read-only-subvolume/)

Citations:
- [bacik] Josef Bacik (2012). Btrfs: The Swiss Army Knife of Storage. USENIX ;login:, volume 37, number 1, Filesystem Consistency section.. https://www.usenix.org/system/files/login/articles/bacik_0.pdf (accessed 2026-10-15)
- [tree-log] Linux v6.16: Btrfs tree-log.c, design comment and replay implementation. https://github.com/torvalds/linux/blob/v6.16/fs/btrfs/tree-log.c (accessed 2026-10-15)
- [mount] Btrfs documentation: btrfs(5), tree logging and rescue mount options. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html (accessed 2026-10-15)
- [hesela] Hesela: Btrfs tree logs, read-only replay and version boundaries. https://hesela.com/analyses/btrfs-tree-log-read-only-replay/ (accessed 2026-10-15)
- [subvolume] Btrfs documentation: subvolume flags and non-recursive snapshots. https://btrfs.readthedocs.io/en/stable/btrfs-subvolume.html (accessed 2026-10-15)

### Bubble memory

URL: https://hesela.dev/terms/bubble-memory/
Status: eol

Non-volatile magnetic memory using cylindrical domains; briefly shipped before cheap DRAM and flash.

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)

Citations:
- [c1] Bubble memory. https://en.wikipedia.org/wiki/Bubble_memory (accessed 2026-03-26)

### Buffered I/O

URL: https://hesela.dev/terms/buffered-io/
Status: shipping

Record updated: 2026-10-15

Buffered I/O is file access through an operating-system cache, allowing transfers between an application and storage to be decoupled.

Note: For Linux iomap, buffered reads use page-cache folios and buffered writes dirty them for later writeback. This is distinct from a language runtime's stream buffer or an SSD's device cache. [iomap]

Advantages:
- Allows cache reuse and writeback rather than requiring every application transfer to reach storage immediately.

Limitations:
- Successful buffer updates alone are not persistence evidence; mixing access paths can require coherence work.

Related terms:
- [page-cache](https://hesela.dev/terms/page-cache/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [fsync](https://hesela.dev/terms/fsync/)
- [posix-fadv-noreuse](https://hesela.dev/terms/posix-fadv-noreuse/)
- [posix-fadv-dontneed](https://hesela.dev/terms/posix-fadv-dontneed/)
- [rwf-dontcache](https://hesela.dev/terms/rwf-dontcache/)

Citations:
- [iomap] Linux v6.17: iomap supported file operations, sections 2.2.1-2.2.3.. https://www.kernel.org/doc/html/v6.17/filesystems/iomap/operations.html (accessed 2026-10-14)

### Byte-addressable storage

URL: https://hesela.dev/terms/byte-addressable-storage/
Status: limited

Record updated: 2026-10-13

Byte-addressable storage exposes individual byte locations rather than only block-sized addresses, without by itself specifying atomicity or durability.

Note: For memory-like storage, Linux DAX can expose file contents through a direct userspace mapping and avoid a page-cache copy. [dax-docs] Addressability is distinct from persistence: PMDK separates page, cache-line and byte persistence granularity according to the protected domain. [pmdk-granularity] Even a persistence function is not transactional, and cache eviction can make stores durable before software explicitly persists them. A byte-addressed interface therefore does not promise an atomic multi-byte update. [pmdk-persist] Linux's Block Translation Table (BTT) provides sector-update atomicity through a stacked block device with remapping metadata, rather than deriving that guarantee from byte addressability alone. [btt-docs]

Advantages:
- Suitable DAX mappings avoid the redundant page-cache copy of memory-like backing storage. (sources: [dax-docs])

Limitations:
- Address granularity is not a guarantee of power-fail atomicity or durable ordering. (sources: [pmdk-persist], [pmdk-granularity])

Related terms:
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [storage-class-memory](https://hesela.dev/terms/storage-class-memory/)
- [nvdimm-n](https://hesela.dev/terms/nvdimm-n/)
- [optane](https://hesela.dev/terms/optane/)
- [3d-xpoint](https://hesela.dev/terms/3d-xpoint/)
- [cxl-memory](https://hesela.dev/terms/cxl-memory/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [dax](https://hesela.dev/terms/dax/)
- [persistence-domain](https://hesela.dev/terms/persistence-domain/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [dax-docs] Linux kernel documentation. Direct Access for files: motivation and S_DAX state.. https://docs.kernel.org/filesystems/dax.html (accessed 2026-10-13)
- [pmdk-granularity] PMDK 1.13.1. libpmem2(7), GRANULARITY (pinned source documentation).. https://github.com/pmem/pmdk/blob/1.13.1/doc/libpmem2/libpmem2.7.md (accessed 2026-10-13)
- [pmdk-persist] PMDK 1.13.1. pmem2_get_persist_fn(3): early persistence and non-transactional semantics.. https://github.com/pmem/pmdk/blob/1.13.1/doc/libpmem2/pmem2_get_persist_fn.3.md (accessed 2026-10-13)
- [btt-docs] Linux kernel documentation. BTT - Block Translation Table, introduction and theory of operation.. https://docs.kernel.org/driver-api/nvdimm/btt.html (accessed 2026-10-13)
- [hesela-pmem] Hesela. Persistent memory: DAX is not a durable commit.. https://hesela.com/analyses/pmem-persistence-domains-dax/ (accessed 2026-10-13)

### Storage cache flush

URL: https://hesela.dev/terms/cache-flush/
Also known as: write cache flush, REQ_PREFLUSH
Status: shipping

Record updated: 2026-10-12

A storage cache flush requests persistence of writes buffered in the addressed storage stack, with its coverage and ordering defined by that interface.

Note: In the Linux block layer, REQ_PREFLUSH makes previously completed writes persistent before an accompanying I/O starts; it can also be issued without a data payload. REQ_FUA instead covers persistence of the flagged write before its completion, and both flags may be combined. This block-level operation does not submit data still held only in an application buffer or establish multi-file transaction atomicity. Device-mapper layers must propagate the required persistence semantics.

Advantages:
- Provides a persistence boundary for earlier completed writes in a stack that honors the request. (sources: [linux-cache])

Limitations:
- A successful lower-layer flush does not certify an application's complete recovery protocol. (sources: [linux-cache], [hesela-stability])

Related terms:
- [force-unit-access](https://hesela.dev/terms/force-unit-access/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [write-through-cache](https://hesela.dev/terms/write-through-cache/)
- [fsync](https://hesela.dev/terms/fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [linux-cache] Linux kernel documentation. Explicit volatile write back cache control: REQ_PREFLUSH and REQ_FUA.. https://docs.kernel.org/block/writeback_cache_control.html (accessed 2026-10-12)
- [dm-cache] Linux kernel documentation. Device-mapper cache: operating modes and on-disk metadata.. https://docs.kernel.org/admin-guide/device-mapper/cache.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)

### Cache pollution

URL: https://hesela.dev/terms/cache-pollution/
Also known as: cache scan pollution
Status: research

Record updated: 2026-10-15

Cache pollution occurs when low-reuse entries displace entries that would otherwise serve useful cache hits.

Note: A scan can cause misses after the scan itself has finished. [car]

Related terms:
- [lru-replacement](https://hesela.dev/terms/lru-replacement/)
- [mapping-cache](https://hesela.dev/terms/mapping-cache/)
- [adaptive-replacement-cache](https://hesela.dev/terms/adaptive-replacement-cache/)

Citations:
- [car] Sorav Bansal and Dharmendra S. Modha. CAR: Clock with Adaptive Replacement. FAST 2004; sections III-V.. https://www.usenix.org/legacy/events/fast04/tech/full_papers/bansal/bansal.pdf (accessed 2026-10-15)
- [hesela] Hesela: mapping caches, scan phases and cache-history semantics (constructed examples). https://hesela.com/analyses/ssd-mapping-cache-hmb/#scan-pollution (accessed 2026-10-15)

### Acting set (Ceph)

URL: https://hesela.dev/terms/ceph-acting-set/
Also known as: Ceph acting set
Status: shipping

Record updated: 2026-10-13

In Ceph, the acting set is the ordered OSD list responsible for a placement group at a particular map epoch.

Note: It normally matches the up set but can be overridden through PG temp. Membership is not proof that every member has the latest contents. [ceph-peering]

Related terms:
- [placement-group](https://hesela.dev/terms/placement-group/)
- [ceph-up-set](https://hesela.dev/terms/ceph-up-set/)
- [ceph-peering](https://hesela.dev/terms/ceph-peering/)

Citations:
- [ceph-peering] Ceph Squid developer documentation: Peering, concepts. https://docs.ceph.com/en/squid/dev/peering/ (accessed 2026-10-13)
- [hesela-availability] Storage availability and correlated failures: placement boundaries. https://hesela.com/analyses/storage-availability-correlated-failures/ (accessed 2026-10-13)

### Peering (Ceph)

URL: https://hesela.dev/terms/ceph-peering/
Also known as: Ceph PG peering
Status: shipping

Record updated: 2026-10-13

Ceph peering establishes agreement among OSDs about a placement group's object state and associated metadata.

Note: Agreement does not mean all copies are current. [ceph-peering] The peered state can still block client I/O when min_size is unmet; recovery may continue. [ceph-pg-states]

Related terms:
- [placement-group](https://hesela.dev/terms/placement-group/)
- [ceph-acting-set](https://hesela.dev/terms/ceph-acting-set/)

Citations:
- [ceph-peering] Ceph Squid developer documentation: Peering, concepts. https://docs.ceph.com/en/squid/dev/peering/ (accessed 2026-10-13)
- [ceph-pg-states] Ceph Squid documentation: Placement Group States. https://docs.ceph.com/en/squid/rados/operations/pg-states/ (accessed 2026-10-13)
- [hesela-availability] Storage availability and correlated failures: placement boundaries. https://hesela.com/analyses/storage-availability-correlated-failures/ (accessed 2026-10-13)

### Up set (Ceph)

URL: https://hesela.dev/terms/ceph-up-set/
Also known as: Ceph up set
Status: shipping

Record updated: 2026-10-13

In Ceph, the up set is the ordered OSD list assigned to a placement group by CRUSH for a particular map epoch.

Note: It describes placement, not completed data transfer; an explicit PG temp override can make the acting set differ. [ceph-peering]

Related terms:
- [placement-group](https://hesela.dev/terms/placement-group/)
- [ceph-acting-set](https://hesela.dev/terms/ceph-acting-set/)

Citations:
- [ceph-peering] Ceph Squid developer documentation: Peering, concepts. https://docs.ceph.com/en/squid/dev/peering/ (accessed 2026-10-13)
- [hesela-availability] Storage availability and correlated failures: placement boundaries. https://hesela.com/analyses/storage-availability-correlated-failures/ (accessed 2026-10-13)

### CFexpress

URL: https://hesela.dev/terms/cfexpress/
Status: shipping

A removable card standard using PCIe and NVMe for high-end cameras and embedded recorders.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [sd-express](https://hesela.dev/terms/sd-express/)

Citations:
- [c1] CFexpress. https://en.wikipedia.org/wiki/CFexpress (accessed 2026-03-26)

### Chain replication

URL: https://hesela.dev/terms/chain-replication/
Status: research

Record updated: 2026-10-12

Chain replication orders replicas so that updates enter at a head, propagate along the chain and complete at a tail that also serves queries.

Note: The original OSDI 2004 protocol assumes fail-stop servers and reliable FIFO links. A master changes membership; the prototype replicates that master using Paxos. These are protocol assumptions, not arbitrary-partition availability or multi-object transaction guarantees.

Related terms:
- [synchronous-replication](https://hesela.dev/terms/synchronous-replication/)
- [linearizability](https://hesela.dev/terms/linearizability/)

Citations:
- [chain-paper] Robbert van Renesse and Fred B. Schneider: Chain Replication for Supporting High Throughput and Availability, OSDI 2004, pp. 91-104. https://www.usenix.org/legacy/events/osdi04/tech/full_papers/renesse/renesse.pdf (accessed 2026-10-12)
- [hesela-replication] Replication acknowledgements: received, durable, applied. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-12)

### NAND channel

URL: https://hesela.dev/terms/channel-nand/
Status: shipping

Record updated: 2026-10-12

A NAND channel is a communication path between an SSD controller and flash components sharing its transfer resources.

Note: Independent connections permit concurrent transfers; adding flash components to a shared bus does not increase that bus's bandwidth. Internal cell-array operations and register-to-controller transfers are different stages, and scheduling may overlap them. More channels do not themselves shorten an individual NAND operation. Agrawal and colleagues analyze these architectural tradeoffs using trace-driven simulation; their historical component timings are not current-device specifications. Realized performance depends on workload, data placement, controller resources and the host interface. A NAND channel is not a host PCIe lane, and channel count alone does not determine application latency. [agrawal-atc08]

Advantages:
- Independent paths can expose parallel work across flash components. (sources: [agrawal-atc08])
- Interleaving can overlap internal operations and transfers when hardware constraints permit. (sources: [agrawal-atc08])

Limitations:
- Flash components sharing a channel compete for its transfer bandwidth. (sources: [agrawal-atc08])
- Workload and data placement can prevent available parallelism from being used. (sources: [agrawal-atc08])

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [flash-controller](https://hesela.dev/terms/flash-controller/)
- [ssd](https://hesela.dev/terms/ssd/)
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [die-stacking](https://hesela.dev/terms/die-stacking/)
- [open-channel-ssd](https://hesela.dev/terms/open-channel-ssd/)
- [nvme](https://hesela.dev/terms/nvme/)
- [over-provisioning](https://hesela.dev/terms/over-provisioning/)
- [wear-leveling](https://hesela.dev/terms/wear-leveling/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] Solid-state drive (Wikipedia), sections on the controller and internal parallelism. https://en.wikipedia.org/wiki/Solid-state_drive (accessed 2026-10-11)
- [c2] Open NAND Flash Interface Working Group (Wikipedia). https://en.wikipedia.org/wiki/Open_NAND_Flash_Interface (accessed 2026-10-11)
- [agrawal-atc08] Nitin Agrawal, Vijayan Prabhakaran, Ted Wobber, John D. Davis, Mark Manasse and Rina Panigrahy. Design Tradeoffs for SSD Performance. USENIX ATC 2008, sections 2.1-2.2, 3.3 and 4.1.. https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal_html/index.html (accessed 2026-10-12)

### Charge trap flash

URL: https://hesela.dev/terms/charge-trap-flash/
Also known as: CTF
Status: shipping

A flash cell design that stores charge in localized traps within an insulating material rather than on a conductive floating gate.

Note: Charge storage and vertical stacking are separate design choices. In the 3D charge-trap structures studied by Luo et al., neighboring cells share a trapping layer; neighbor state affects retention loss. This is not the same event as interference during programming.

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [floating-gate](https://hesela.dev/terms/floating-gate/)
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [retention-interference](https://hesela.dev/terms/retention-interference/)
- [early-retention-loss](https://hesela.dev/terms/early-retention-loss/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] Charge trap flash. https://en.wikipedia.org/wiki/Charge_trap_flash (accessed 2026-03-26)
- [luo] Luo, Ghose, Cai, Haratsch and Mutlu. Improving 3D NAND Flash Memory Lifetime by Tolerating Early Retention Loss and Process Variation. POMACS author manuscript, 2018, sections 4.1-4.4. https://ghose.cs.illinois.edu/papers/18sigmetrics_3dflash.pdf (accessed 2026-10-11)
- [micron2020] Micron. 176-layer NAND announcement, 9 November 2020: transition to charge trap and replacement gate. https://investors.micron.com/news/press-release/2020/Micron-Ships-Worlds-First-176-Layer-NAND-Delivering-A-Breakthrough-in-Flash-Memory-Performance-and-Density-11-09-2020/default.aspx (accessed 2026-10-11)
- [hesela3d] Hesela: 3D NAND retention, cell architecture and evidence limits. https://hesela.com/analyses/3d-nand-retention-evidence/ (accessed 2026-10-11)

### Checkpoint starvation

URL: https://hesela.dev/terms/checkpoint-starvation/
Also known as: SQLite WAL checkpoint starvation
Status: shipping

Record updated: 2026-10-14

Checkpoint starvation is sustained inability to finish or reset a database log checkpoint because the required progress conditions keep being obstructed.

Note: In SQLite WAL, retained reader snapshots can constrain backfill and recycling while later writes continue. [sqlite-wal] Our two-case observation separates a pinned transaction from an idle open connection; it is not a production failure-rate study. [hesela-observation] A PASSIVE result can report busy=0 with fewer checkpointed frames than current log frames. [sqlite-checkpoint-pragma]

Limitations:
- A large WAL file alone does not identify starvation; file length can remain high after progress. (sources: [sqlite-wal])

Related terms:
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [sqlite-wal-end-mark](https://hesela.dev/terms/sqlite-wal-end-mark/)

Citations:
- [sqlite-wal] SQLite: Write-Ahead Logging, sections 2, 6 and 11. https://www.sqlite.org/wal.html (accessed 2026-10-14)
- [sqlite-checkpoint-pragma] SQLite: PRAGMA wal_checkpoint, three-column result. https://www.sqlite.org/pragma.html#pragma_wal_checkpoint (accessed 2026-10-14)
- [hesela-readers] SQLite WAL checkpoint starvation: success is not completion. https://hesela.com/analyses/sqlite-wal-checkpoint-starvation/ (accessed 2026-10-14)
- [hesela-observation] Hesela: measured SQLite WAL-reader observations and limits. https://hesela.dev/research/sqlite-wal-readers.json (accessed 2026-10-14)

### Checksum

URL: https://hesela.dev/terms/checksum/
Also known as: Data checksum
Status: shipping

Record updated: 2026-10-15

A checksum is a value computed from specified data and later compared with a reference value to detect changes.

Note: A checksum names a checking role, not a security level: storage systems can use a CRC or a cryptographic digest in that role. Btrfs supports both categories. State the covered bytes, algorithm and location of the reference value; disagreement alone does not identify which copy is correct. [nist-checksum] [btrfs-checksumming]

Limitations:
- CRC error-detection properties depend on the polynomial, message length and error model; CRC is not an authentication mechanism. (sources: [rfc3385])
- A valid checksum alone does not establish the requested address, committed generation or successful repair. (sources: [hesela-integrity])
- A matching checksum does not establish that filesystem metadata relationships are consistent. (sources: [recon12])

Related terms:
- [cryptographic-hash](https://hesela.dev/terms/cryptographic-hash/)
- [hash-collision](https://hesela.dev/terms/hash-collision/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [end-to-end-data-protection](https://hesela.dev/terms/end-to-end-data-protection/)
- [btrfs-nodatasum](https://hesela.dev/terms/btrfs-nodatasum/)
- [filesystem-consistency-invariant](https://hesela.dev/terms/filesystem-consistency-invariant/)
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)

Citations:
- [nist-checksum] NIST CSRC glossary: checksum (definitions with source attribution). https://csrc.nist.gov/glossary/term/checksum (accessed 2026-10-12)
- [btrfs-checksumming] Btrfs documentation: Checksumming, algorithm choices and verification boundary. https://btrfs.readthedocs.io/en/latest/Checksumming.html (accessed 2026-10-12)
- [rfc3385] RFC 3385: iSCSI CRC/Checksum Considerations, sections 1-2 and 10 (historical error-model analysis). https://www.rfc-editor.org/rfc/rfc3385.html (accessed 2026-10-12)
- [hesela-integrity] Hesela: Why a valid checksum can still return the wrong data. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-12)
- [recon12] Fryer et al. Recon: Verifying File System Consistency at Runtime. FAST 2012, sections 2, 4.1 and 5. https://www.usenix.org/legacy/events/fast/tech/full_papers/Fryer2-16-12.pdf (accessed 2026-10-13)

### Chunk fragmentation

URL: https://hesela.dev/terms/chunk-fragmentation/
Also known as: deduplication fragmentation
Status: research

Record updated: 2026-10-11

Chunk fragmentation is the dispersion of chunks needed by a deduplicated restore across storage containers or an order poorly matched to the restore sequence.

Note: Sparsity and repeated container visits are different costs; this is not NAND erase-block fragmentation. [fu2014]

Related terms:
- [deduplication](https://hesela.dev/terms/deduplication/)
- [container-capping](https://hesela.dev/terms/container-capping/)
- [forward-assembly-area](https://hesela.dev/terms/forward-assembly-area/)

Citations:
- [fu2014] Min Fu, Dan Feng, Yu Hua, Xubin He, Zuoning Chen, Wen Xia, Fangting Huang and Qing Liu. Accelerating Restore and Garbage Collection in Deduplication-based Backup Systems via Exploiting Historical Information. USENIX ATC 2014, pp. 181-192; sections 3-6.. https://www.usenix.org/system/files/conference/atc14/atc14-paper-fu_min.pdf (accessed 2026-10-11)
- [hesela-dedup-restore] Deduplication ratio does not predict restore cost. https://hesela.com/analyses/deduplication-restore-fragmentation/ (accessed 2026-10-11)

### Class prevalence

URL: https://hesela.dev/terms/class-prevalence/
Also known as: positive-class prevalence, class proportion
Status: shipping

Record updated: 2026-10-14

Class prevalence is the proportion of observations belonging to a specified class in a defined population or evaluation sample.

Note: For a nonempty binary sample, positive prevalence = (TP + FN) / (TP + FP + FN + TN). Predicting every observation positive gives precision equal to that prevalence. [sklearn-pr-curve] Sampling more failures changes the evaluation prevalence and may change precision; a balanced test sample does not directly establish deployment alert quality. [saito2015] For storage, specify whether an observation is a drive or a drive-day window, and whether positive means failure within a stated horizon; this proportion is not AFR. [hesela-prediction]

Related terms:
- [precision](https://hesela.dev/terms/precision/)
- [recall](https://hesela.dev/terms/recall/)
- [false-positive-rate](https://hesela.dev/terms/false-positive-rate/)
- [average-precision](https://hesela.dev/terms/average-precision/)
- [drive-day](https://hesela.dev/terms/drive-day/)
- [afr](https://hesela.dev/terms/afr/)
- [f1-score](https://hesela.dev/terms/f1-score/)
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)

Citations:
- [sklearn-pr-curve] scikit-learn: precision_recall_curve; the all-positive endpoint.. https://scikit-learn.org/stable/modules/generated/sklearn.metrics.precision_recall_curve.html (accessed 2026-10-12)
- [saito2015] Saito and Rehmsmeier. The Precision-Recall Plot Is More Informative than the ROC Plot When Evaluating Binary Classifiers on Imbalanced Datasets. PLOS ONE 10(3): e0118432 (2015).. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0118432 (accessed 2026-10-12)
- [hesela-prediction] Hesela: disk failure prediction, metric denominators and a synthetic alert-count example.. https://hesela.com/analyses/ml-disk-failure-prediction/ (accessed 2026-10-12)

### Clear sanitization

URL: https://hesela.dev/terms/clear-sanitization/
Also known as: Clear sanitization method
Status: shipping

Record updated: 2026-10-14

Clear sanitization uses logical operations across all user-addressable storage locations to resist simple, non-invasive recovery through the device interface available to the user, such as the host interface.

Note: NIST SP 800-88 Rev. 2 section 3.1.1 limits this method to the user-interface recovery boundary; it is not a claim that every physical flash cell has been erased. SSD remapping and spare capacity can keep older data outside host-addressable locations. Repeated host overwrites do not establish purge assurance. The selected technique must suit the medium and the required confidentiality protection. [nist-r2]

Advantages:
- Typically preserves the medium for reuse when an appropriate clear technique can be applied. (sources: [nist-r2])

Limitations:
- Does not promise resistance to laboratory recovery from inaccessible flash areas; an inoperable device may prevent a suitable logical overwrite. (sources: [nist-r2])

Related terms:
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [purge-sanitization](https://hesela.dev/terms/purge-sanitization/)
- [destroy-sanitization](https://hesela.dev/terms/destroy-sanitization/)
- [sanitization-verification](https://hesela.dev/terms/sanitization-verification/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)
- [ftl](https://hesela.dev/terms/ftl/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, 3.1.1, printed pages 8-10. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-14)

### Close-to-open consistency

URL: https://hesela.dev/terms/close-to-open-consistency/
Also known as: CTO consistency, close-to-open cache consistency
Status: shipping

Record updated: 2026-10-14

Close-to-open consistency is a file-sharing cache policy that combines writeback at close with validation at a later open to support visibility of updates between sequential users.

Note: An already-open reader is a different case from a new opener. Concurrent access needs application coordination; CTO alone does not serialize simultaneous writers. Linux documents NFSv3 open-time checks and close-time writeback, while NFSv4 delegations can avoid repeated validation and defer writeback. Persistence still depends on the applicable protocol and error handling.

Limitations:
- Linux cto/nocto options differ by version: the NFSv4 setting concerns directories, not file-data caching. (sources: [nfs-client])

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [nfs-attribute-cache](https://hesela.dev/terms/nfs-attribute-cache/)
- [nfs-delegation](https://hesela.dev/terms/nfs-delegation/)
- [nfs-commit](https://hesela.dev/terms/nfs-commit/)

Citations:
- [nfs-client] nfs-utils nfs(5), Debian trixie: data and metadata coherence and version-specific cto/nocto options.. https://manpages.debian.org/trixie/nfs-common/nfs.5.en.html (accessed 2026-10-14)
- [rfc7530] Haynes and Noveck (editors). NFS Version 4 Protocol. RFC 7530, sections 10.3, 10.4 and 10.6 (NFSv4.0).. https://datatracker.ietf.org/doc/html/rfc7530#section-10 (accessed 2026-10-14)
- [rfc8881] Noveck and Lever (editors). NFS Version 4 Minor Version 1 Protocol. RFC 8881, sections 10.3-10.6 (NFSv4.1).. https://www.rfc-editor.org/rfc/rfc8881.html#section-10 (accessed 2026-10-14)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-14)

### Closed-loop load

URL: https://hesela.dev/terms/closed-loop-load/
Also known as: Closed workload model
Status: unknown

Record updated: 2026-10-11

A closed-loop load model uses a fixed client population whose next request follows completion of a previous request, optionally after think time.

Note: Useful when that feedback matches the application; a longer response also slows future arrivals, changing the question compared with independent demand.

Related terms:
- [open-loop-load](https://hesela.dev/terms/open-loop-load/)
- [coordinated-omission](https://hesela.dev/terms/coordinated-omission/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)

Citations:
- [schroeder] Schroeder, Wierman and Harchol-Balter. Open Versus Closed: A Cautionary Tale. USENIX NSDI 2006, sections 2-5 and 7.. https://www.usenix.org/legacy/events/nsdi06/tech/full_papers/schroeder/schroeder_html/index.html (accessed 2026-10-11)
- [hesela-latency] Hesela: synthetic arrival cohorts, timing boundaries and percentile pooling. https://hesela.com/analyses/storage-latency-coordinated-omission/ (accessed 2026-10-11)

### Conventional magnetic recording (CMR)

URL: https://hesela.dev/terms/cmr/
Also known as: non-shingled PMR
Status: shipping

Perpendicular magnetic recording with non-overlapping tracks so any sector can be rewritten in place.

Note: CMR (also called conventional or non-shingled layout in vendor catalogs) writes concentric tracks with guard bands so a rewrite to one track does not trim its neighbors. On modern shipping drives the underlying magnetization is usually perpendicular (PMR); “CMR” is the product-behavior label vendors use to contrast with SMR. Because in-place updates do not force band rewrite, CMR remains the default choice for mixed random I/O, RAID, and any stack that assumes a traditional block device. Seagate’s public CMR/SMR matrix lists recording technology per SKU—capacity alone does not reveal the layout.

Advantages:
- Random rewrite without track-band garbage collection typical of SMR. (sources: [c1])

Related terms:
- [pmr](https://hesela.dev/terms/pmr/)
- [smr](https://hesela.dev/terms/smr/)
- [hdd](https://hesela.dev/terms/hdd/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)

Supersedes:
- [longitudinal-recording](https://hesela.dev/terms/longitudinal-recording/)

Citations:
- [c1] Shingled magnetic recording. https://en.wikipedia.org/wiki/Shingled_magnetic_recording (accessed 2026-03-26)
- [n2] Seagate — CMR and SMR hard drive list. https://www.seagate.com/products/cmr-smr-list/ (accessed 2026-10-07)
- [n3] Zoned Storage — SMR introduction (CMR vs overlapping tracks). https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-07)

### Codeword (storage ECC)

URL: https://hesela.dev/terms/codeword/
Also known as: ECC codeword
Status: shipping

Record updated: 2026-10-12

A storage ECC codeword is an encoded unit representing a data chunk together with error-correction redundancy.

Note: A NAND page can hold multiple codewords. Codeword length and protected payload length are different quantities when redundancy is included; report which one a size or error-rate denominator uses. A codeword is not automatically a sector, NAND page or erase block. [cai2017]

Limitations:
- A count of failed codewords does not count every erroneous bit in those words. (sources: [cai2017])

Related terms:
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)
- [ldpc](https://hesela.dev/terms/ldpc/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [bit-error-rate](https://hesela.dev/terms/bit-error-rate/)

Citations:
- [cai2017] Cai et al. Error Characterization, Mitigation, and Recovery in Flash Memory Based Solid-State Drives (2017), sections II.C and VI.C.. https://research.ece.cmu.edu/safari/pubs/1706.08642.pdf (accessed 2026-10-12)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence.. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-12)

### Cold archive tier

URL: https://hesela.dev/terms/cold-archive/
Status: shipping

Offline or very low-cost storage tier optimized for rare reads and long retention.

Related terms:
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)
- [object-storage](https://hesela.dev/terms/object-storage/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)

Citations:
- [c1] Cold archive tier. https://en.wikipedia.org/wiki/Cold_data (accessed 2026-03-26)

### LSM compaction

URL: https://hesela.dev/terms/compaction/
Also known as: LSM-tree compaction
Status: shipping

Record updated: 2026-10-15

LSM compaction reorganizes sorted storage components, commonly merging selected runs or SST files and removing obsolete entries when visibility rules permit.

Note: Compaction is not compression: it changes the organization and retained versions of data, whereas compression changes their representation. A snapshot can keep an older version necessary. Background merges consume CPU and I/O even when foreground queries perform no writes. [rocks-overview] Some nonoverlapping files can move between levels without rewriting their contents, so compaction need not rewrite every selected byte. [rocks-compaction] A strategy specifies trigger, layout, granularity and data-movement policy, not just leveled versus tiered organization. [compaction-design] RocksDB can apply write backpressure when background work falls behind. Its pending-compaction-byte estimate is specifically a leveled-compaction property, not a universal measure of all compaction strategies. [properties]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [sstable](https://hesela.dev/terms/sstable/)
- [leveled-compaction](https://hesela.dev/terms/leveled-compaction/)
- [tiered-compaction](https://hesela.dev/terms/tiered-compaction/)
- [database-write-amplification](https://hesela.dev/terms/database-write-amplification/)
- [pending-compaction-bytes](https://hesela.dev/terms/pending-compaction-bytes/)
- [rocksdb-write-stall](https://hesela.dev/terms/rocksdb-write-stall/)

Citations:
- [rocks-overview] RocksDB project. Overview: multi-threaded compaction and snapshot visibility.. https://github.com/facebook/rocksdb/wiki/RocksDB-Overview (accessed 2026-10-14)
- [rocks-compaction] RocksDB project. Compaction: leveled, tiered and hybrid policies.. https://github.com/facebook/rocksdb/wiki/Compaction (accessed 2026-10-14)
- [compaction-design] Sarkar, Staratzis, Zhu and Athanassoulis. Constructing and Analyzing the LSM Compaction Design Space. PVLDB 14(11), 2216-2229 (2021), DOI: 10.14778/3476249.3476274; updated arXiv:2202.04522v2 (2022), sections 2-5.. https://arxiv.org/abs/2202.04522v2 (accessed 2026-10-14)
- [hesela] Hesela. Bloom filters: optimize the lookup, not each filter; compaction and measurement boundaries.. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-14)
- [properties] RocksDB v10.10.1. Pending compaction bytes and write-control properties.. https://github.com/facebook/rocksdb/blob/v10.10.1/include/rocksdb/db.h#L1263 (accessed 2026-10-15)

### Compare-and-swap

URL: https://hesela.dev/terms/compare-and-swap/
Also known as: CAS, Compare-and-set
Status: shipping

Record updated: 2026-10-12

Compare-and-swap is an atomic conditional update that replaces a stored value only if it matches an expected value and reports the comparison outcome or observed value.

Note: The comparison and update must be indivisible; separate GET and PUT requests leave a race. In etcd, a transaction can compare a value or modification revision before its update. A value-only comparison cannot detect an intervening change that restores the original value; this is a constructed consequence of equality testing. A timeout can leave the operation's outcome unknown. This storage-API use of CAS is not content-addressable storage.

Related terms:
- [linearizability](https://hesela.dev/terms/linearizability/)
- [serializability](https://hesela.dev/terms/serializability/)
- [conditional-write](https://hesela.dev/terms/conditional-write/)

Citations:
- [etcd-api] etcd v3.6 documentation: Key-Value pair metadata and Transaction.. https://etcd.io/docs/v3.6/learning/api/ (accessed 2026-10-12)
- [etcd-guarantees] etcd v3.6 API guarantees: durability, strict serializability and operation completion.. https://etcd.io/docs/v3.6/learning/api_guarantees/ (accessed 2026-10-12)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-12)

### Compensation log record

URL: https://hesela.dev/terms/compensation-log-record/
Also known as: CLR
Status: shipping

Record updated: 2026-10-15

An ARIES compensation log record describes a rollback action for redo and records where undo processing should continue.

Note: CLRs are redo-only: recovery does not undo the compensation itself. PrevLSN follows the transaction's log chain; UndoNxtLSN bypasses already compensated work. A durable CLR can survive while the corresponding page update does not; redo restores that update before rollback continues. If the CLR was volatile and is lost, that progress is not preserved. These are original ARIES semantics, not a claim that every WAL engine uses CLRs. [aries] [aries-beyond] The companion's 12-state example is a single-page synthetic model, not a hardware crash test. [hesela-wal]

Related terms:
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)
- [page-lsn](https://hesela.dev/terms/page-lsn/)
- [fuzzy-checkpoint](https://hesela.dev/terms/fuzzy-checkpoint/)

Citations:
- [aries] Mohan, Haderle, Lindsay, Pirahesh and Schwarz. ARIES. ACM TODS 17(1), 1992, sections 3, 5.2 and 6.2-6.3.. https://www.cs.cmu.edu/~15849g/readings/mohan92.pdf (accessed 2026-10-15)
- [aries-beyond] C. Mohan. Repeating History Beyond ARIES. VLDB 1999, sections 3.2.1-3.2.2.. https://www.vldb.org/conf/1999/P1.pdf (accessed 2026-10-15)
- [hesela-wal] Hesela: ARIES rollback progress, with a synthetic executable trace. https://hesela.com/analyses/wal-checkpoints-torn-pages/#aries-rollback (accessed 2026-10-15)

### Completion latency (fio)

URL: https://hesela.dev/terms/completion-latency/
Also known as: clat
Status: shipping

Record updated: 2026-10-13

Completion latency in fio is the engine-dependent interval from submission of an I/O unit to observation of its completion.

Note: For asynchronous I/O, observation includes fio reaping the completion; clat is not necessarily time spent only inside a storage device [fio]. Pool compatible clat means using their own sample counts; a zero-sample mean does not measure zero latency [fio-stat].

Related terms:
- [submission-latency](https://hesela.dev/terms/submission-latency/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)
- [iops](https://hesela.dev/terms/iops/)

Citations:
- [fio] fio documentation: interpreting slat, clat and lat; engine-dependent timing boundaries.. https://fio.readthedocs.io/en/master/fio_doc.html (accessed 2026-10-13)
- [fio-stat] fio 3.41 source: stat.c, add_ddir_lat_json and add_ddir_status_json; latency sample counts and directional runtime denominators.. https://github.com/axboe/fio/blob/fio-3.41/stat.c#L1410-L1600 (accessed 2026-10-13)
- [hesela-populations] Hesela: fio summaries, latency sample populations and runtime denominators; synthetic examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#fio-populations (accessed 2026-10-13)

### Computational storage drive

URL: https://hesela.dev/terms/computational-storage/
Status: limited

An SSD or NVMe device that runs limited compute near data to reduce data movement.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] Computational storage drive. https://en.wikipedia.org/wiki/Computational_storage (accessed 2026-03-26)

### Concurrent positioning range (ATA)

URL: https://hesela.dev/terms/concurrent-positioning-range/
Also known as: Concurrent Positioning Ranges log
Status: shipping

Record updated: 2026-10-16

An ATA concurrent positioning range is a contiguous logical-block range reported as supporting positioning concurrently with other reported ranges.

Note: The Exos 2X18 SATA manual identifies the Concurrent Positioning Ranges log at address 47h and maps each half of its LBA space to an actuator. ATA logical-block counts must use the device's current logical-block size; Linux independent_access_ranges instead reports normalized 512-byte sectors. Do not substitute one unit for the other.

Related terms:
- [dual-actuator](https://hesela.dev/terms/dual-actuator/)
- [independent-access-range](https://hesela.dev/terms/independent-access-range/)
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [sata](https://hesela.dev/terms/sata/)

Citations:
- [sata-manual] Seagate Exos 2X18 SATA product manual, Rev. A, sections 2.2.1 and 2.2.2. https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/manuals/exos-x-2x18/pdf/203859600a.pdf (accessed 2026-10-16)
- [linux-abi] Linux 6.14 stable ABI: 512-byte independent access range units. https://docs.kernel.org/6.14/admin-guide/abi-stable.html#abi-sys-block-disk-queue-independent-access-ranges (accessed 2026-10-16)

### Conditional write

URL: https://hesela.dev/terms/conditional-write/
Also known as: Conditional object write
Status: shipping

Record updated: 2026-10-15

A conditional write changes a resource only when a server-evaluated precondition, such as a matching entity tag or the absence of a current object, holds.

Note: For Amazon S3 general-purpose buckets, If-Match on PutObject or CompleteMultipartUpload compares the current destination object's ETag, while If-None-Match: * requires no current object. This is an object-level precondition, not a multi-object transaction or a test that no intervening write ever happened. Client-side checking followed by an unconditional upload does not provide the same protection. An ETag condition validates the representation under the service's ETag rules, not every metadata field or application invariant.

Advantages:
- An If-Match precondition can reject a stale replacement instead of silently overwriting a representation whose validator has changed. (sources: [c1], [c2])
- If-None-Match: * lets an S3 writer require that the destination has no current object at the write operation, without a separate check-then-create race. (sources: [c1], [c2])

Limitations:
- A mismatched ETag or an existing current object under If-None-Match: * causes S3 to return 412; a conflicting operation can return 409, and blindly refreshing the ETag without reconciling stale content can lose an update. (sources: [c3], [c6])
- After a 409 from CompleteMultipartUpload, S3 requires a new upload ID and re-upload of every part; retry rules therefore differ from PutObject. (sources: [c3], [c4])
- In versioned S3 buckets, If-None-Match: * permits a write when the current version is a delete marker, even if older versions remain; If-Match fails with 404 when there is no current object or the current version is a delete marker. (sources: [c2])
- Strong S3 read-after-write consistency does not make a separate read-modify-write sequence atomic, and S3 does not provide atomic updates across multiple keys. (sources: [c5], [c6])

Related terms:
- [object-storage](https://hesela.dev/terms/object-storage/)
- [entity-tag](https://hesela.dev/terms/entity-tag/)
- [multipart-upload](https://hesela.dev/terms/multipart-upload/)
- [compare-and-swap](https://hesela.dev/terms/compare-and-swap/)
- [delete-marker](https://hesela.dev/terms/delete-marker/)

Citations:
- [c1] RFC 9110: HTTP Semantics, conditional requests. https://www.rfc-editor.org/rfc/rfc9110.html#section-13 (accessed 2026-10-12)
- [c2] Amazon S3: How to prevent object overwrites with conditional writes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html (accessed 2026-10-12)
- [c3] Amazon S3 API Reference: PutObject. https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html (accessed 2026-10-12)
- [c4] Amazon S3 API Reference: CompleteMultipartUpload. https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html (accessed 2026-10-12)
- [c5] Amazon S3: Data consistency model. https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#ConsistencyModel (accessed 2026-10-12)
- [c6] Object ETags: checksums and conditional writes are different. https://hesela.com/analyses/object-etags-checksums-conditional-writes/ (accessed 2026-10-12)

### Consumer SSD

URL: https://hesela.dev/terms/consumer-ssd/
Also known as: client SSD
Status: shipping

Record updated: 2026-10-15

An SSD intended for personal computers and other client devices rather than shared server workloads.

Note: SNIA SSS PTS 2.0.2 defines client and enterprise categories by application environment, not by a power-loss-protection certification. Check a particular model's documentation for endurance and cache-persistence guarantees. For sustained performance comparisons, report the workload, preparation and stability evidence; retail branding and warm-up duration alone do not establish those properties.

Related terms:
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [sata](https://hesela.dev/terms/sata/)
- [nvme](https://hesela.dev/terms/nvme/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [trim](https://hesela.dev/terms/trim/)
- [ssd-steady-state](https://hesela.dev/terms/ssd-steady-state/)
- [ssd-preconditioning](https://hesela.dev/terms/ssd-preconditioning/)
- [ssd](https://hesela.dev/terms/ssd/)

Citations:
- [c1] Solid-state drive. https://en.wikipedia.org/wiki/Solid-state_drive (accessed 2026-03-26)
- [n2] NVM Express — overview (client and enterprise PCIe SSD interface). https://nvmexpress.org/wp-content/uploads/NVMe_Overview.pdf (accessed 2026-10-07)
- [n3] SNIA — Emerald device classification context. https://www.snia.org/emerald (accessed 2026-10-07)
- [snia] SNIA. Solid State Storage Performance Test Specification, version 2.0.2 (1 October 2020), definitions 2.1.1, 2.1.3, 2.1.6, 2.1.13, 2.1.18 and 2.1.24.. https://www.snia.org/sites/default/files/2025-02/SNIA-SSS-PTS-2.0.2.pdf (accessed 2026-10-11)
- [hesela-steady-state] Hesela: SSD steady state is not a timer. https://hesela.com/analyses/ssd-steady-state-is-not-a-timer/ (accessed 2026-10-11)

### Container capping

URL: https://hesela.dev/terms/container-capping/
Status: research

Record updated: 2026-10-11

Container capping limits the old containers referenced by a backup segment by storing selected duplicate chunks again.

Note: A locality-versus-space trade-off, not a cap on total repository containers. [lillibridge2013]

Related terms:
- [deduplication](https://hesela.dev/terms/deduplication/)
- [chunk-fragmentation](https://hesela.dev/terms/chunk-fragmentation/)

Citations:
- [lillibridge2013] Mark Lillibridge, Kave Eshghi and Deepavali Bhagwat. Improving Restore Speed for Backup Systems that Use Inline Chunk-Based Deduplication. USENIX FAST 2013, pp. 183-197; sections 2-4.. https://www.usenix.org/system/files/conference/fast13/fast13-final124.pdf (accessed 2026-10-11)
- [hesela-dedup-restore] Deduplication ratio does not predict restore cost. https://hesela.com/analyses/deduplication-restore-fragmentation/ (accessed 2026-10-11)

### Content-defined chunking

URL: https://hesela.dev/terms/content-defined-chunking/
Also known as: CDC
Status: shipping

Record updated: 2026-10-12

Content-defined chunking divides a byte stream using content-dependent boundary rules rather than only fixed offsets.

Note: The aim is to retain reusable chunks despite shifted offsets; minimum-size suppression and maximum-size forced cuts can disrupt resynchronization. Boundary selection is separate from checking whole-chunk identity. [lbfs]

Related terms:
- [deduplication](https://hesela.dev/terms/deduplication/)
- [fastcdc](https://hesela.dev/terms/fastcdc/)
- [rolling-hash](https://hesela.dev/terms/rolling-hash/)
- [chunk-fragmentation](https://hesela.dev/terms/chunk-fragmentation/)

Citations:
- [lbfs] Athicha Muthitacharoen, Benjie Chen and David Mazieres. A Low-bandwidth Network File System. SOSP 2001, sections 3.1.1-3.1.3.. https://pdos.csail.mit.edu/papers/lbfs:sosp01/lbfs.pdf (accessed 2026-10-12)
- [hesela-cdc] Content-defined chunking: boundaries are not identity. https://hesela.com/analyses/content-defined-chunking-boundaries/ (accessed 2026-10-12)

### Coordinated omission

URL: https://hesela.dev/terms/coordinated-omission/
Status: unknown

Record updated: 2026-10-11

Coordinated omission is a measurement bias in which a workload generator or sampler misses observations because its activity depends on the slow responses being measured.

Note: A correct histogram of issued requests need not describe independent arrivals; synthetic correction must state its expected-interval assumption.

Related terms:
- [open-loop-load](https://hesela.dev/terms/open-loop-load/)
- [closed-loop-load](https://hesela.dev/terms/closed-loop-load/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)

Citations:
- [wrk2] Gil Tene, wrk2: scheduled-arrival latency and coordinated omission; maintainer documentation, not an SSD benchmark.. https://github.com/giltene/wrk2 (accessed 2026-10-11)
- [hdr] HdrHistogram maintainers: corrected versus raw value recording and expected sampling intervals.. https://github.com/HdrHistogram/HdrHistogram#corrected-vs-raw-value-recording-calls (accessed 2026-10-11)
- [hesela-latency] Hesela: synthetic arrival cohorts, timing boundaries and percentile pooling. https://hesela.com/analyses/storage-latency-coordinated-omission/ (accessed 2026-10-11)
- [hesela-model] Hesela synthetic timing records: model parameters, full request cohorts and SHA-256 provenance. https://hesela.dev/research/latency-measurement.json (accessed 2026-10-11)

### copy_file_range

URL: https://hesela.dev/terms/copy-file-range/
Status: shipping

Record updated: 2026-10-15

copy_file_range is a Linux system call that copies a requested file range in the kernel and reports the number of bytes actually copied.

Note: A successful call may copy fewer bytes than requested, and zero can indicate EOF. Implementations may accelerate copying with reflinks or server-side copy; success alone does not identify physical allocation. Sparse holes can expand. [linux-cfr]

Related terms:
- [reflink](https://hesela.dev/terms/reflink/)
- [sparse-file](https://hesela.dev/terms/sparse-file/)

Citations:
- [linux-cfr] Linux man-pages 6.19: copy_file_range(2), return values and notes. https://man7.org/linux/man-pages/man2/copy_file_range.2.html (accessed 2026-10-15)
- [hesela-clones] Hesela: Fast file clones and deferred copying costs. https://hesela.com/analyses/file-clones-deferred-copy-cost/ (accessed 2026-10-15)

### Copy-on-abundant-write

URL: https://hesela.dev/terms/copy-on-abundant-write/
Status: research

Record updated: 2026-10-15

Copy-on-abundant-write is a research cloning policy that buffers changes to postpone unsharing until enough work accumulates to justify copying.

Note: BetrFS 0.5 implements this policy; structural maintenance can also require unsharing. It is not a generic Linux reflink option. [fast2020]

Related terms:
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [reflink](https://hesela.dev/terms/reflink/)

Citations:
- [fast2020] Zhan et al., How to Copy Files, FAST 2020, sections 1-4. https://www.usenix.org/system/files/fast20-zhan.pdf (accessed 2026-10-15)
- [hesela-clones] Hesela: Fast file clones and deferred copying costs. https://hesela.com/analyses/file-clones-deferred-copy-cost/ (accessed 2026-10-15)

### Copy-on-write (storage)

URL: https://hesela.dev/terms/copy-on-write/
Status: shipping

Record updated: 2026-10-15

A technique that writes modified blocks to new locations instead of overwriting in place.

Note: For shared file data, writes must preserve the other file's contents and may require new allocation. Linux provides an unshare-range operation to prepare shared extents before later writes. Logical isolation does not create a separate failure domain. In Btrfs, nodatacow for newly created files also implies nodatasum; changing write placement can therefore change integrity coverage. In ZFS, copy-on-write transaction-group commit and intent logging solve different persistence steps; copy-on-write alone does not mean each system-call return is durable. [zfs-txg] Btrfs also has a tree-log path and a full transaction-commit path for fsync; copy-on-write does not mean recovery needs no log. [btrfs-log]

Related terms:
- [snapshot](https://hesela.dev/terms/snapshot/)
- [ssd](https://hesela.dev/terms/ssd/)
- [file-storage](https://hesela.dev/terms/file-storage/)
- [reflink](https://hesela.dev/terms/reflink/)
- [btrfs-nodatasum](https://hesela.dev/terms/btrfs-nodatasum/)
- [zfs-transaction-group](https://hesela.dev/terms/zfs-transaction-group/)
- [copy-on-abundant-write](https://hesela.dev/terms/copy-on-abundant-write/)
- [btrfs-tree-log](https://hesela.dev/terms/btrfs-tree-log/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Copy-on-write (storage). https://en.wikipedia.org/wiki/Copy-on-write (accessed 2026-03-26)
- [ficlone] Linux man-pages: FICLONE and FICLONERANGE sharing semantics. https://man7.org/linux/man-pages/man2/ioctl_ficlone.2.html (accessed 2026-10-13)
- [fallocate] Linux man-pages: fallocate(2), unshare-range contract. https://man7.org/linux/man-pages/man2/fallocate.2.html (accessed 2026-10-13)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)
- [btrfs-mount] Btrfs documentation: btrfs(5), datacow/nodatacow and datasum/nodatasum. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html (accessed 2026-10-13)
- [zfs-txg] OpenZFS 2.3.4: txg.c, transaction-group lifecycle and synchronization. https://github.com/openzfs/zfs/blob/zfs-2.3.4/module/zfs/txg.c (accessed 2026-10-14)
- [btrfs-log] Linux v6.16: Btrfs tree-log.c, design comment and replay implementation. https://github.com/torvalds/linux/blob/v6.16/fs/btrfs/tree-log.c (accessed 2026-10-15)

### CKD DASD

URL: https://hesela.dev/terms/count-key-data/
Status: limited

Count-key-data block layout used on classic mainframe disks unlike fixed SCSI sectors.

Related terms:
- [mainframe-dasd](https://hesela.dev/terms/mainframe-dasd/)

Citations:
- [c1] CKD DASD. https://en.wikipedia.org/wiki/Count_key_data (accessed 2026-03-26)

### Crash consistency

URL: https://hesela.dev/terms/crash-consistency/
Also known as: crash consistency
Status: shipping

Record updated: 2026-10-15

Crash consistency is the property that persistent state remains within an application's allowed recovery states after an unexpected interruption.

Note: It is distinct from preserving every acknowledged update: an older, internally consistent state may still violate durability. Pillai et al. distinguish persistence ordering and atomicity, while SQLite documents a concrete rollback-journal protocol. Filesystem metadata consistency alone does not establish that an application's multi-file transaction committed.

Related terms:
- [journal-checkpoint](https://hesela.dev/terms/journal-checkpoint/)
- [journal-revoke-record](https://hesela.dev/terms/journal-revoke-record/)
- [ext4-fast-commit](https://hesela.dev/terms/ext4-fast-commit/)
- [fsync](https://hesela.dev/terms/fsync/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [bounded-crash-testing](https://hesela.dev/terms/bounded-crash-testing/)
- [crash-test-oracle](https://hesela.dev/terms/crash-test-oracle/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [torn-write](https://hesela.dev/terms/torn-write/)
- [full-page-write](https://hesela.dev/terms/full-page-write/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [application-consistent-snapshot](https://hesela.dev/terms/application-consistent-snapshot/)
- [rollback-journal](https://hesela.dev/terms/rollback-journal/)
- [hot-journal](https://hesela.dev/terms/hot-journal/)
- [sqlite-super-journal](https://hesela.dev/terms/sqlite-super-journal/)
- [soft-updates](https://hesela.dev/terms/soft-updates/)

Citations:
- [pillai-2014] Pillai et al. (OSDI 2014): All File Systems Are Not Created Equal. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf (accessed 2026-10-10)
- [sqlite-atomic] SQLite: Atomic Commit. https://www.sqlite.org/atomiccommit.html (accessed 2026-10-10)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-10)
- [hesela-rename] Hesela: Atomic rename is not a durable commit. https://hesela.com/analyses/atomic-rename-directory-durability/ (accessed 2026-10-11)
- [hesela] Hesela. Crash-consistency tests: the oracle is part of the result.. https://hesela.com/analyses/crash-testing-oracles-and-bounds/ (accessed 2026-10-12)

### Crash-test oracle

URL: https://hesela.dev/terms/crash-test-oracle/
Also known as: recovery correctness checker
Status: research

Record updated: 2026-10-12

A crash-test oracle is a checker that decides whether a recovered state satisfies the specified correctness and durability contract.

Note: The allowed outcome can depend on which durable acknowledgements were observed before the fault. Merely opening recovered files does not check that contract; ALICE requires application-specific checkers.

Related terms:
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [bounded-crash-testing](https://hesela.dev/terms/bounded-crash-testing/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [pillai] Pillai et al. All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications. OSDI 2014; sections 3-4.. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf (accessed 2026-10-12)
- [alice-docs] University of Wisconsin-Madison ADSL. ALICE user documentation: checker contract and caveats.. https://research.cs.wisc.edu/adsl/Software/alice/doc/adsl-doc.html (accessed 2026-10-12)
- [hesela] Hesela. Crash-consistency tests: the oracle is part of the result.. https://hesela.com/analyses/crash-testing-oracles-and-bounds/ (accessed 2026-10-12)

### NAND cross-temperature effect

URL: https://hesela.dev/terms/cross-temperature-effect/
Status: shipping

Record updated: 2026-10-13

The NAND cross-temperature effect is the change in read behavior associated with programming and subsequently reading a cell at different temperatures.

Note: Keep programming temperature, storage history and reading temperature separate. An et al. measured a 24-layer device during cooling and used TCAD to interpret channel effects; their near-zero net threshold shift at one condition did not mean zero charge loss [an2023]. This is not a universal SSD failure rate or a thermal-throttling threshold.

Limitations:
- The magnitude depends on device structure, stored state, wear and sensing policy.
- Chip-level observations do not prescribe a safe operating temperature for a complete SSD.

Related terms:
- [data-retention](https://hesela.dev/terms/data-retention/)
- [read-reference-voltage](https://hesela.dev/terms/read-reference-voltage/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [3d-nand](https://hesela.dev/terms/3d-nand/)

Citations:
- [an2023] An, Yoon, Go, Park, Kim, Kim and Lee. Effects of Poly-Si Grain Boundary on Retention Characteristics under Cross-Temperature Conditions in 3-D NAND Flash Memory. Micromachines 14(12), 2199 (2023), sections 2.1-2.2. DOI: 10.3390/mi14122199.. https://doi.org/10.3390/mi14122199 (accessed 2026-10-13)
- [hesela] 3D NAND retention: layer count is not a reliability rating. https://hesela.com/analyses/3d-nand-retention-evidence/#cross-temperature (accessed 2026-10-13)

### CRUSH

URL: https://hesela.dev/terms/crush-placement/
Also known as: Controlled Replication Under Scalable Hashing, CRUSH placement
Status: shipping

Record updated: 2026-10-13

CRUSH is a deterministic, pseudorandom placement algorithm that maps an identifier to storage targets using a weighted cluster hierarchy and placement rules.

Note: Clients can calculate target locations without a per-object location directory. [crush-paper] In Ceph, rules can separate replicas or erasure-code shards across modeled hosts or racks. [ceph-crush] CRUSH is a placement mechanism, not an erasure code, a consensus protocol or a guarantee of availability.

Related terms:
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [placement-group](https://hesela.dev/terms/placement-group/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)

Citations:
- [crush-paper] Weil, Brandt, Miller and Maltzahn, CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data, SC 2006, sections 3-3.2. https://ceph.io/assets/pdfs/weil-crush-sc06.pdf (accessed 2026-10-13)
- [ceph-crush] Ceph Squid documentation: CRUSH Maps, hierarchy and placement rules. https://docs.ceph.com/en/squid/rados/operations/crush-map/ (accessed 2026-10-13)
- [hesela-availability] Storage availability and correlated failures: placement boundaries. https://hesela.com/analyses/storage-availability-correlated-failures/ (accessed 2026-10-13)

### Cryptographic erase

URL: https://hesela.dev/terms/cryptographic-erase/
Also known as: Crypto erase, CE
Status: shipping

Record updated: 2026-10-14

Cryptographic erase sanitizes the keys protecting encrypted target data so that recovering the plaintext becomes infeasible.

Note: This can sanitize access without rewriting every ciphertext block. It requires suitable cryptography and key management, coverage of the target data before sanitization, and sanitization of all copies of the target cryptographic keys. Deleting an account password is not automatically key sanitization. Sensitive plaintext stored since the last appropriate sanitization needs a different suitable treatment; encryption enabled only before disposal does not retroactively protect those remnants. NIST SP 800-88 Rev. 2 section 3.2.2 footnote 10 qualifies the prior-plaintext condition by the last appropriate sanitization. [nist-r2] Sanitizing a wrapping or master key also requires eliminating lower-level keys and any previously unwrapped copies that remain usable, including copies in memory or encryption-engine registers; external key copies must be accounted for. [nist-r2]

Advantages:
- Can avoid a full-media rewrite when its cryptographic prerequisites are satisfied. (sources: [nist-r2])

Limitations:
- Backups or escrow copies of keys need separate assessment; ciphertext remains, so required long-term confidentiality also matters. (sources: [nist-r2])

Related terms:
- [self-encrypting-drive](https://hesela.dev/terms/self-encrypting-drive/)
- [sanitize-nvme](https://hesela.dev/terms/sanitize-nvme/)
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [secure-erase](https://hesela.dev/terms/secure-erase/)
- [purge-sanitization](https://hesela.dev/terms/purge-sanitization/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, sections 3 and 4.5. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-10)

### Cryptographic hash function

URL: https://hesela.dev/terms/cryptographic-hash/
Also known as: Cryptographic digest function
Status: shipping

Record updated: 2026-10-12

A cryptographic hash function deterministically produces a digest and is designed to resist preimage, second-preimage and collision attacks.

Note: Preimage search starts from a target digest; second-preimage search starts from a specified input; collision search may choose both distinct inputs. Designed resistance is not a promise that collisions do not exist. [nist-hash] An unkeyed digest does not authenticate its own origin: replacing both data and the expected digest can preserve a match. HMAC adds a shared secret to authentication; hashing is not encryption. [rfc2104]

Limitations:
- Algorithm choice, output length and known attacks determine useful security; a matching digest is not proof of storage durability. (sources: [nist-hash], [hesela-integrity])

Related terms:
- [checksum](https://hesela.dev/terms/checksum/)
- [hash-collision](https://hesela.dev/terms/hash-collision/)
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)
- [deduplication](https://hesela.dev/terms/deduplication/)

Citations:
- [nist-hash] NIST CSRC glossary: cryptographic hash function and security properties. https://csrc.nist.gov/glossary/term/cryptographic_hash_function (accessed 2026-10-12)
- [rfc2104] RFC 2104: HMAC, sections 1-2 (construction, not current algorithm selection advice). https://www.rfc-editor.org/rfc/rfc2104.html (accessed 2026-10-12)
- [hesela-integrity] Hesela: Why a valid checksum can still return the wrong data. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-12)

### Cryptographic nonce

URL: https://hesela.dev/terms/cryptographic-nonce/
Also known as: Nonce
Status: shipping

Record updated: 2026-10-15

A cryptographic nonce is an input value whose required uniqueness scope is specified by the cryptographic construction that uses it.

Note: For RFC 5116's AES-GCM profiles, encryption must not reuse a nonce under one key; repeated decryption is different. VM rollback can cause reuse by restoring earlier encryption state. Nonce handling therefore belongs in snapshot recovery reviews. [rfc5116] XTS sector-number tweaks have a different contract and must not be treated as GCM nonces. [broz2018]

Limitations:
- A nonce is not itself a freshness policy that rejects old, valid ciphertext. (sources: [rfc5116])

Related terms:
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)
- [xts-aes](https://hesela.dev/terms/xts-aes/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [replay-attack](https://hesela.dev/terms/replay-attack/)

Citations:
- [rfc5116] RFC 5116: nonce requirements, GCM reuse and VM rollback, sections 2.1, 3.1, 5.1.1 and 8. https://www.rfc-editor.org/rfc/rfc5116.html (accessed 2026-10-15)
- [broz2018] Broz, Patocka and Matyas: Practical cryptographic data integrity protection with full disk encryption, 2018, sections 2.4 and 3.3. https://arxiv.org/pdf/1807.00309v1 (accessed 2026-10-15)
- [hesela-encryption] Hesela: Nonce reuse is not ciphertext replay. https://hesela.com/analyses/checksums-identity-and-lost-writes/#nonce-reuse (accessed 2026-10-15)

### CXL memory expansion

URL: https://hesela.dev/terms/cxl-memory/
Status: shipping

Compute Express Link attaches byte-addressable memory or accelerators on PCIe, blurring DRAM and storage tiers.

Related terms:
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [storage-class-memory](https://hesela.dev/terms/storage-class-memory/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] CXL memory expansion. https://en.wikipedia.org/wiki/Compute_Express_Link (accessed 2026-03-26)

### DAT cartridge

URL: https://hesela.dev/terms/dat-cartridge/
Status: eol

Digital Audio Tape format adapted for small-office digital backup in the 1990s.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [helical-scan](https://hesela.dev/terms/helical-scan/)

Citations:
- [c1] DAT cartridge. https://en.wikipedia.org/wiki/Digital_Audio_Tape (accessed 2026-03-26)

### Flash data retention

URL: https://hesela.dev/terms/data-retention/
Status: shipping

Record updated: 2026-10-13

Flash data retention is the ability of programmed NAND data to remain recoverable over time without refresh under specified wear, storage and read conditions.

Note: Retention age measures time since programming, not drive power-on age. Early retention loss and read-reference adaptation complicate interpreting error behavior from wear alone. Programming temperature, storage-temperature history and reading temperature are distinct conditions; a near-zero net threshold shift can conceal opposing charge-loss and channel contributions in the studied 3D NAND device [an2023].

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [qlc](https://hesela.dev/terms/qlc/)
- [early-retention-loss](https://hesela.dev/terms/early-retention-loss/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [read-disturb](https://hesela.dev/terms/read-disturb/)
- [retention-interference](https://hesela.dev/terms/retention-interference/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)
- [cross-temperature-effect](https://hesela.dev/terms/cross-temperature-effect/)
- [read-reference-voltage](https://hesela.dev/terms/read-reference-voltage/)

Citations:
- [luo] Luo, Ghose, Cai, Haratsch and Mutlu. Improving 3D NAND Flash Memory Lifetime by Tolerating Early Retention Loss and Process Variation. POMACS 2018, sections 4.1, 4.3 and 4.4. https://ghose.cs.illinois.edu/papers/18sigmetrics_3dflash.pdf (accessed 2026-10-11)
- [c1] Flash data retention. https://en.wikipedia.org/wiki/Flash_memory (accessed 2026-03-26)
- [hesela] Hesela: NAND read-retry and evidence boundaries. https://hesela.com/analyses/nand-read-retry-latency/ (accessed 2026-10-11)
- [heatwatch] Luo, Ghose, Cai, Haratsch and Mutlu. HeatWatch. HPCA 2018, sections 3.1-3.4 and 4.2. DOI: 10.1109/HPCA.2018.00050. https://ghose.cs.illinois.edu/papers/18hpca_heatwatch.pdf (accessed 2026-10-11)
- [hesela3d] Hesela: 3D NAND retention, cell architecture and evidence limits. https://hesela.com/analyses/3d-nand-retention-evidence/ (accessed 2026-10-11)
- [an2023] An, Yoon, Go, Park, Kim, Kim and Lee. Effects of Poly-Si Grain Boundary on Retention Characteristics under Cross-Temperature Conditions in 3-D NAND Flash Memory. Micromachines 14(12), 2199 (2023), sections 2.1-2.2. DOI: 10.3390/mi14122199.. https://doi.org/10.3390/mi14122199 (accessed 2026-10-13)

### Data sanitization

URL: https://hesela.dev/terms/data-sanitization/
Status: shipping

Record updated: 2026-10-14

Media sanitization is a process that makes recovery of target data infeasible for a specified level of effort.

Note: NIST SP 800-88 Rev. 2 (September 2025) supersedes Rev. 1 and distinguishes clear, purge and destroy. Choose a method for the information sensitivity, media and intended reuse. Verification checks the operation's outcome; validation decides whether the evidence and remaining confidentiality risk are acceptable. For clear and purge, the guidance does not require elaborate post-sanitization content sampling unless organizational policy does. The method (clear, purge or destroy) is distinct from a technology-specific technique; Rev. 2 leaves most such technique details to standards such as IEEE 2883 or another standard accepted by organizational policy. [nist-r2]

Advantages:
- A documented sanitization record connects device identity, technique, tool version, verification and validation. (sources: [nist-r2])

Limitations:
- A success message alone is not a universal certification of sanitization; investigate errors, anomalies and unsuitable techniques before release. (sources: [nist-r2])

Related terms:
- [secure-erase](https://hesela.dev/terms/secure-erase/)
- [sanitize-nvme](https://hesela.dev/terms/sanitize-nvme/)
- [cryptographic-erase](https://hesela.dev/terms/cryptographic-erase/)
- [trim](https://hesela.dev/terms/trim/)
- [clear-sanitization](https://hesela.dev/terms/clear-sanitization/)
- [purge-sanitization](https://hesela.dev/terms/purge-sanitization/)
- [destroy-sanitization](https://hesela.dev/terms/destroy-sanitization/)
- [sanitization-verification](https://hesela.dev/terms/sanitization-verification/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, sections 3 and 4.5. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-10)

### Data scrubbing

URL: https://hesela.dev/terms/data-scrubbing/
Also known as: Disk scrubbing, Storage scrubbing
Status: shipping

Record updated: 2026-10-16

Data scrubbing is proactive verification of stored data to discover errors before ordinary access requires the affected content.

Note: Specify the verification layer and repair behavior: media verification, parity checks and filesystem checksum scans are not equivalent. Btrfs mounting can replay a tree log even when the mount is read-only; this is a separate write boundary from the later scrub. [btrfs-mount]

Limitations:
- Detection alone does not supply a valid replacement copy; repair depends on available redundancy. (sources: [zfs])
- Linux MD check is not guaranteed to be read-only for every RAID level. (sources: [md])
- Btrfs read-only scrub on a read-write mount can still write internally; it is not a full filesystem consistency check. (sources: [btrfs-scrub])
- Btrfs status can describe an old or cancelled run; resume does not initiate a new pass after a completed scrub. (sources: [btrfs-scrub])

Related terms:
- [latent-sector-error](https://hesela.dev/terms/latent-sector-error/)
- [staggered-scrubbing](https://hesela.dev/terms/staggered-scrubbing/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [checksum](https://hesela.dev/terms/checksum/)
- [resilver](https://hesela.dev/terms/resilver/)
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)
- [btrfs-nodatasum](https://hesela.dev/terms/btrfs-nodatasum/)
- [filesystem-consistency-invariant](https://hesela.dev/terms/filesystem-consistency-invariant/)
- [btrfs-tree-log](https://hesela.dev/terms/btrfs-tree-log/)
- [adaptive-scrubbing](https://hesela.dev/terms/adaptive-scrubbing/)
- [mean-time-to-detection](https://hesela.dev/terms/mean-time-to-detection/)
- [zfs-error-scrub](https://hesela.dev/terms/zfs-error-scrub/)

Citations:
- [zfs] OpenZFS master documentation: zpool-scrub(8), description and operation boundaries (retrieved 11 October 2026).. https://openzfs.github.io/openzfs-docs/man/master/8/zpool-scrub.8.html (accessed 2026-10-11)
- [md] Linux kernel documentation: RAID arrays, sync_action and mismatch_cnt (retrieved 11 October 2026).. https://docs.kernel.org/admin-guide/md.html (accessed 2026-10-11)
- [hesela-scrub] Hesela: Scrubbing, detection time and repair boundaries. https://hesela.com/analyses/scrubbing-detection-not-durability/ (accessed 2026-10-11)
- [btrfs-scrub] Btrfs documentation: btrfs-scrub(8), checksum exclusions and read-only limitations. https://btrfs.readthedocs.io/en/latest/btrfs-scrub.html (accessed 2026-10-16)
- [btrfs-mount] Btrfs documentation: btrfs(5), tree logging and rescue mount options. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html (accessed 2026-10-15)

### Database checkpoint

URL: https://hesela.dev/terms/database-checkpoint/
Also known as: WAL checkpoint
Status: shipping

Record updated: 2026-10-14

A database checkpoint records engine-defined recovery state to bound or reduce the work needed after a crash.

Note: PostgreSQL recovery uses the redo position associated with a checkpoint. SQLite checkpointing transfers committed page content from WAL to the main database file, and readers can delay completion. These mechanisms are not identical, and a checkpoint does not create an independent backup. ARIES fuzzy checkpoints record recovery metadata without requiring dirty-page writes during the checkpoint. In our controlled WAL experiment, PASSIVE returned busy=0 while backfill was incomplete; ending the read transaction allowed completion without closing its connection. [hesela-readers]

Advantages:
- Can reduce the amount of log replay required after a crash. (sources: [pg-checkpoints])

Limitations:
- More frequent PostgreSQL checkpoints can increase data-page flushing and full-page-image WAL traffic. (sources: [pg-checkpoints])

Related terms:
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [full-page-write](https://hesela.dev/terms/full-page-write/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [fuzzy-checkpoint](https://hesela.dev/terms/fuzzy-checkpoint/)
- [rollback-journal](https://hesela.dev/terms/rollback-journal/)
- [sqlite-super-journal](https://hesela.dev/terms/sqlite-super-journal/)
- [checkpoint-starvation](https://hesela.dev/terms/checkpoint-starvation/)
- [sqlite-wal-end-mark](https://hesela.dev/terms/sqlite-wal-end-mark/)

Citations:
- [pg-checkpoints] PostgreSQL 18: WAL Configuration. https://www.postgresql.org/docs/18/wal-configuration.html (accessed 2026-10-11)
- [pg-archive] PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery. https://www.postgresql.org/docs/18/continuous-archiving.html (accessed 2026-10-11)
- [sqlite-wal] SQLite: Write-Ahead Logging (unversioned documentation). https://sqlite.org/wal.html (accessed 2026-10-11)
- [hesela-wal] WAL, checkpoints and torn pages: three different recovery guarantees. https://hesela.com/analyses/wal-checkpoints-torn-pages/ (accessed 2026-10-11)
- [aries] Mohan et al. ARIES. ACM TODS 17(1), 1992, pp. 121-122, section 5.4.. https://www.cs.cmu.edu/~15849g/readings/mohan92.pdf (accessed 2026-10-12)
- [hesela-readers] Hesela: SQLite WAL checkpoint starvation observations. https://hesela.com/analyses/sqlite-wal-checkpoint-starvation/ (accessed 2026-10-14)

### Database write amplification

URL: https://hesela.dev/terms/database-write-amplification/
Status: shipping

Record updated: 2026-10-14

Database byte write amplification is storage-engine output bytes written divided by logical input bytes over a stated interval and accounting boundary.

Note: Specify whether input counts keys, values or both, and whether output includes WAL, compaction and value-store cleaning. This ratio is distinct from host-to-NAND write amplification. [wisckey]

Related terms:
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [key-value-separation](https://hesela.dev/terms/key-value-separation/)
- [compaction](https://hesela.dev/terms/compaction/)
- [read-amplification](https://hesela.dev/terms/read-amplification/)
- [space-amplification](https://hesela.dev/terms/space-amplification/)

Citations:
- [wisckey] Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau and Remzi H. Arpaci-Dusseau. WiscKey: Separating Keys from Values in SSD-conscious Storage. USENIX FAST 2016, pp. 133-148, sections 3.2-3.3 and 4.. https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf (accessed 2026-10-12)
- [hesela-kv] Key-value separation: the cleaning bill moves elsewhere. https://hesela.com/analyses/key-value-separation-cleaning-cost/ (accessed 2026-10-12)

### Direct Access

URL: https://hesela.dev/terms/dax/
Also known as: DAX, filesystem DAX
Status: shipping

Record updated: 2026-10-13

Direct Access is a Linux mechanism that lets suitable memory-like storage serve file data without an intervening page-cache copy.

Note: Filesystem DAX can map backing storage into userspace, but it does not by itself flush CPU caches or establish application crash consistency. The persistent FS_XFLAG_DAX preference and active S_DAX state are distinct; statx exposes the latter through STATX_ATTR_DAX. [dax-docs] MAP_SYNC adds a supported mapping guarantee used with appropriate CPU instructions, rather than making every store automatically durable. [mmap-docs]

Related terms:
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)
- [map-sync](https://hesela.dev/terms/map-sync/)
- [persistence-domain](https://hesela.dev/terms/persistence-domain/)

Citations:
- [dax-docs] Linux kernel documentation. Direct Access for files: motivation and S_DAX state.. https://docs.kernel.org/filesystems/dax.html (accessed 2026-10-13)
- [mmap-docs] Linux man-pages. mmap(2), MAP_SYNC and MAP_SHARED_VALIDATE.. https://man7.org/linux/man-pages/man2/mmap.2.html (accessed 2026-10-13)
- [hesela-pmem] Hesela. Persistent memory: DAX is not a durable commit.. https://hesela.com/analyses/pmem-persistence-domains-dax/ (accessed 2026-10-13)

### Deallocated read behavior

URL: https://hesela.dev/terms/deallocated-read-behavior/
Also known as: Read after deallocation
Status: shipping

The interface-defined data or error returned when a host reads a deallocated logical block.

Note: In NVMe 1.4a, DLFEAT describes deallocated data values and DULBE controls the supported deallocated/unwritten-block error. This concerns the logical interface, not direct inspection of physical media.

Limitations:
- Linux discard_zeroes_data always returns zero and should not be used to infer readback semantics. (sources: [linux-abi])

Related terms:
- [discard](https://hesela.dev/terms/discard/)
- [trim](https://hesela.dev/terms/trim/)
- [scsi-unmap](https://hesela.dev/terms/scsi-unmap/)
- [nvme](https://hesela.dev/terms/nvme/)
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)

Citations:
- [nvme-1-4a] NVM Express 1.4a: sections 6.7, 6.7.1.1 and Figure 247. https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4a-2020.03.09-Ratified.pdf (accessed 2026-10-11)
- [linux-abi] Linux 6.12: stable sysfs block ABI, discard attributes. https://raw.githubusercontent.com/torvalds/linux/v6.12/Documentation/ABI/stable/sysfs-block (accessed 2026-10-11)
- [hesela-discard] Hesela: Discard is not zeroing. https://hesela.com/analyses/discard-is-not-zeroing/ (accessed 2026-10-11)

### Data deduplication

URL: https://hesela.dev/terms/deduplication/
Also known as: dedup
Status: shipping

Record updated: 2026-10-12

Data deduplication replaces duplicate content with references to shared stored blocks or chunks within a defined matching scope.

Note: Sharing content does not determine physical replica count or guarantee fast restores. Restore locality and cache behavior must be assessed separately from capacity savings. Matching scope, index cost and handling of existing data are implementation-specific; OpenZFS documents these operational boundaries. [openzfs-dedup] [hesela-dedup-restore] Chunk boundaries are another independent choice. In Restic, copying snapshots between repositories with different chunker parameters can reduce reuse; the documented setup copies parameters when initializing a destination. [restic-copy]

Related terms:
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [object-storage](https://hesela.dev/terms/object-storage/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)
- [chunk-fragmentation](https://hesela.dev/terms/chunk-fragmentation/)
- [container-capping](https://hesela.dev/terms/container-capping/)
- [forward-assembly-area](https://hesela.dev/terms/forward-assembly-area/)
- [content-defined-chunking](https://hesela.dev/terms/content-defined-chunking/)
- [rolling-hash](https://hesela.dev/terms/rolling-hash/)
- [cryptographic-hash](https://hesela.dev/terms/cryptographic-hash/)
- [hash-collision](https://hesela.dev/terms/hash-collision/)

Citations:
- [c1] Data deduplication. https://en.wikipedia.org/wiki/Data_deduplication (accessed 2026-03-26)
- [openzfs-dedup] OpenZFS documentation: Deduplication. https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Data%20Storage/Deduplication.html (accessed 2026-10-11)
- [hesela-dedup-restore] Deduplication ratio does not predict restore cost. https://hesela.com/analyses/deduplication-restore-fragmentation/ (accessed 2026-10-11)
- [restic-copy] Restic project. Working with repositories: Ensuring deduplication for copied snapshots. Documentation displayed as version 0.19.1.. https://restic.readthedocs.io/en/stable/045_working_with_repos.html#ensuring-deduplication-for-copied-snapshots (accessed 2026-10-12)
- [hesela-cdc] Content-defined chunking: boundaries are not identity. https://hesela.com/analyses/content-defined-chunking-boundaries/ (accessed 2026-10-12)

### Disk defect skipping

URL: https://hesela.dev/terms/defect-skipping/
Also known as: IBM 3340 defect skipping
Status: unknown

Record updated: 2026-10-11

Disk defect skipping formats a record around a known defective medium region so that normal reads bypass a gap instead of storing customer data there.

Note: In the IBM 3340 design, factory tests located defects and the track home address recorded their displacement. Formatting either split a record field or enlarged an existing gap. This is distinct from correcting corrupted bits or relocating a logical sector to spare storage. Mulvany (1974, pp. 502-504) reports 128 bytes reserved on each 3348 track and a maximum allowed defect length of 16 bytes. Formatting the affected record required an extra revolution; subsequent normal reads and update writes did not incur that formatting step. These are constraints of that design, not specifications for current HDDs or a field failure-rate measurement.

Advantages:
- The controller attachment microprogram hid the gap handling from system and user software. (sources: [mulvany1974])

Limitations:
- Factory-known defect avoidance did not eliminate ECC or provide an unlimited mechanism for newly developing defects. (sources: [mulvany1974])

Related terms:
- [winchester-architecture](https://hesela.dev/terms/winchester-architecture/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [count-key-data](https://hesela.dev/terms/count-key-data/)

Citations:
- [mulvany1974] R. B. Mulvany, Engineering Design of a Disk Storage Facility with Data Modules, IBM J. Res. Dev. 18(6), 489-505 (1974); pp. 489-494, 502-504. https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/IBM_Journal_of_Research_and_Development/186/ibmrd1806D.pdf (accessed 2026-10-11)

### Degaussing

URL: https://hesela.dev/terms/degaussing/
Status: shipping

Record updated: 2026-10-14

Degaussing uses a magnetic field to disrupt recorded magnetization and can sanitize suitable magnetic media when the process is matched to the medium.

Note: NIST SP 800-88 Rev. 2 section 3.1.2 treats degaussing as a possible physical purge technique, not an approved destroy technique. The field must be matched to the medium's coercivity; insufficient strength can leave data recoverable. Damage to servo tracks may make a drive inoperable without sanitizing its data. Degaussing does not sanitize flash, including flash components in hybrid devices. [nist-r2]

Advantages:
- Can provide a physical purge route for suitable magnetic media without relying on the host data interface. (sources: [nist-r2])

Limitations:
- Not suitable for flash; loss of device usability is not proof of successful sanitization. (sources: [nist-r2])

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [purge-sanitization](https://hesela.dev/terms/purge-sanitization/)
- [destroy-sanitization](https://hesela.dev/terms/destroy-sanitization/)
- [sanitization-verification](https://hesela.dev/terms/sanitization-verification/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)

Citations:
- [c1] Degaussing. https://en.wikipedia.org/wiki/Degaussing (accessed 2026-03-26)
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), section 3.1.2, printed page 10. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)

### Degraded array

URL: https://hesela.dev/terms/degraded-array/
Also known as: Degraded RAID, Degraded mode
Status: shipping

Record updated: 2026-10-15

A degraded array is a redundant storage array operating with less than its configured healthy redundancy because one or more members are unavailable or not fully synchronized.

Note: Degraded does not mean that every additional failure is survivable: remaining tolerance depends on the redundancy group and which members or blocks are affected [zconcepts]. In Linux MD, degraded counts missing members and decreases as devices become active; a dirty and degraded RAID5 or RAID6 array may have untrustworthy parity, so normal assembly can be refused [md]. A one-member-degraded RAID 6 and a one-member-degraded RAID 5 do not have the same remaining protection. Record the level, missing members and unreadable fragments in the affected stripe before interpreting a read error [hesela-parity].

Limitations:
- Continued access is not evidence that every stored block is readable or that full redundancy has returned. (sources: [zconcepts])

Related terms:
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)
- [hot-spare](https://hesela.dev/terms/hot-spare/)
- [resilver](https://hesela.dev/terms/resilver/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [raid-6](https://hesela.dev/terms/raid-6/)
- [raid-10](https://hesela.dev/terms/raid-10/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)

Citations:
- [zconcepts] OpenZFS 2.3: zpoolconcepts(7), device failure and hot spares. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpoolconcepts.7.html (accessed 2026-10-13)
- [md] Linux 6.12 documentation: RAID arrays, recovery, resync and degraded state. https://docs.kernel.org/6.12/admin-guide/md.html (accessed 2026-10-13)
- [hesela-rebuild] Hesela: RAID rebuild read-error models and resilver boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/ (accessed 2026-10-13)
- [hesela-parity] Hesela: RAID 5/6 capacity and per-stripe recovery boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#parity-budget-heading (accessed 2026-10-15)

### Delayed allocation

URL: https://hesela.dev/terms/delayed-allocation/
Also known as: delalloc
Status: shipping

Record updated: 2026-10-16

A filesystem allocation strategy that defers choosing physical storage locations for data already accepted into its buffered write path.

Note: Linux FIEMAP marks such extents DELALLOC and UNKNOWN; UNKNOWN alone does not identify delayed allocation. An unwritten extent already has allocation. Deferred placement does not by itself establish whether accounting space was reserved, nor prove persistence. Linux v6.8 ext4_file_getattr includes reserved delayed-allocation blocks in the reported block count. In Hesela's same-host observation, this count stayed unchanged while synchronization removed DELALLOC from the returned mapping.

Related terms:
- [file-extent](https://hesela.dev/terms/file-extent/)
- [unwritten-extent](https://hesela.dev/terms/unwritten-extent/)
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [buffered-io](https://hesela.dev/terms/buffered-io/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [fsync](https://hesela.dev/terms/fsync/)
- [fiemap](https://hesela.dev/terms/fiemap/)

Citations:
- [fiemap] Linux 6.12: FIEMAP extent states and mapping flags. https://docs.kernel.org/6.12/filesystems/fiemap.html (accessed 2026-10-16)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-16)
- [ext4-getattr] Linux v6.8 source: ext4_file_getattr includes delayed-allocation reservations. https://github.com/torvalds/linux/blob/v6.8/fs/ext4/inode.c#L5215-L5244 (accessed 2026-10-16)
- [hesela-observer-data] Hesela: nine-file FIEMAP observation with code and environment. https://hesela.dev/research/fiemap-observer.json (accessed 2026-10-16)

### Delete marker

URL: https://hesela.dev/terms/delete-marker/
Also known as: S3 delete marker
Status: shipping

Record updated: 2026-10-15

A delete marker is a payload-free S3 version that makes a key appear deleted when the marker is current.

Note: Scope: S3 general-purpose buckets. A marker has a key and version ID, but no object data or ACL. A current marker produces a documented 404 on GET without versionId; explicitly requesting the marker version produces 405. Both carry x-amz-delete-marker: true. [s3-markers]

Advantages:
- Version-aware listing distinguishes delete markers from retained data versions that an ordinary current-object listing does not expose. (sources: [s3-list-versions])

Limitations:
- In a suspended bucket, a simple DELETE replaces any null data version with a null marker; that payload is not retained by the marker. (sources: [s3-suspended-delete])
- Removing a current marker can expose an older version, but cannot recover permanently removed bytes; another remaining marker can still hide data. (sources: [s3-marker-removal])
- Access restrictions can return authorization errors, so a bare HTTP status does not establish the complete version history. (sources: [get])

Related terms:
- [object-versioning](https://hesela.dev/terms/object-versioning/)
- [object-version-id](https://hesela.dev/terms/object-version-id/)
- [conditional-write](https://hesela.dev/terms/conditional-write/)

Citations:
- [s3-markers] Amazon S3: Working with delete markers. https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeleteMarker.html (accessed 2026-10-15)
- [s3-list-versions] Amazon S3 API: ListObjectVersions. https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectVersions.html (accessed 2026-10-15)
- [s3-suspended-delete] Amazon S3: Deleting objects from versioning-suspended buckets. https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectsfromVersioningSuspendedBuckets.html (accessed 2026-10-15)
- [s3-marker-removal] Amazon S3: Managing delete markers. https://docs.aws.amazon.com/AmazonS3/latest/userguide/ManagingDelMarkers.html (accessed 2026-10-15)
- [get] Amazon S3 API: GetObject. https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html (accessed 2026-10-15)
- [hesela-object] Hesela: Object ETags, checksums and conditional writes. https://hesela.com/analyses/object-etags-checksums-conditional-writes/ (accessed 2026-10-15)

### Delete persistence latency

URL: https://hesela.dev/terms/delete-persistence-latency/
Status: shipping

Record updated: 2026-10-12

In delete-aware LSM research, delete persistence latency is the delay from inserting a tombstone to removing the entries it invalidates through compaction.

Note: This is a reclamation metric, not the time to durably log a delete or erase every physical copy.

Related terms:
- [lsm-tombstone](https://hesela.dev/terms/lsm-tombstone/)
- [range-tombstone](https://hesela.dev/terms/range-tombstone/)
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)

Citations:
- [lethe] Subhadeep Sarkar, Tarikul Islam Papon, Dimitris Staratzis and Manos Athanassoulis. Lethe: A Tunable Delete-Aware LSM Engine. SIGMOD 2020. Updated manuscript arXiv:2006.04777v4, sections 3-5. DOI: 10.1145/3318464.3389757.. https://arxiv.org/pdf/2006.04777v4 (accessed 2026-10-12)
- [writes] RocksDB project. Basic Operations: synchronous and non-sync writes.. https://github.com/facebook/rocksdb/wiki/Basic-Operations (accessed 2026-10-12)
- [hesela] LSM tombstones: deleted is not yet reclaimed. https://hesela.com/analyses/lsm-tombstones-delete-persistence/ (accessed 2026-10-12)

### Destroy sanitization

URL: https://hesela.dev/terms/destroy-sanitization/
Also known as: Destroy sanitization method
Status: shipping

Record updated: 2026-10-14

Destroy sanitization makes target-data recovery infeasible even with current state-of-the-art laboratory techniques and leaves the medium incapable of storing data again.

Note: NIST SP 800-88 Rev. 2 section 3.1.3 requires both recovery resistance and loss of storage usability. A broken enclosure or controller does not show that the data-bearing medium was sanitized. Partial damage, including a drilled hole, can leave recoverable portions; suitable destruction depends on the medium and applicable technique requirements. Degaussing is not an approved destroy technique in the cited revision. [nist-r2]

Advantages:
- Can address media for which an appropriate logical sanitization technique cannot be applied. (sources: [nist-r2])

Limitations:
- Precludes reuse of the data-bearing medium, and visible damage alone is not evidence that the required destruction outcome was achieved. (sources: [nist-r2])

Related terms:
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [clear-sanitization](https://hesela.dev/terms/clear-sanitization/)
- [purge-sanitization](https://hesela.dev/terms/purge-sanitization/)
- [sanitization-verification](https://hesela.dev/terms/sanitization-verification/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, 3.1.2-3.1.3 and 4.5.1, printed pages 10-11 and 24. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-14)

### Device-managed SMR (DM-SMR)

URL: https://hesela.dev/terms/device-managed-smr/
Also known as: drive-managed SMR
Status: shipping

Record updated: 2026-10-15

An SMR HDD that presents a conventional LBA interface while the firmware relocates writes across shingled bands.

Note: Drive-managed SMR exposes a conventional block interface while firmware handles relocation into overlapping tracks [zoned]. Its persistent media staging area is distinct from the volatile write buffer. Cleaning can occur during idle periods or while requests are waiting; a slowdown alone does not identify a command failure [analysis].

Advantages:
- Works with legacy software unaware of zoned semantics. (sources: [zoned])

Limitations:
- Sustained random write can trigger internal garbage collection and latency spikes. (sources: [zoned])

Related terms:
- [smr](https://hesela.dev/terms/smr/)
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [smr-persistent-cache](https://hesela.dev/terms/smr-persistent-cache/)
- [garbage-collection-smr](https://hesela.dev/terms/garbage-collection-smr/)
- [shingled-band](https://hesela.dev/terms/shingled-band/)

Citations:
- [c1] Shingled magnetic recording. https://en.wikipedia.org/wiki/Shingled_magnetic_recording (accessed 2026-03-26)
- [n2] Zoned Storage — SMR disk models (drive-managed vs zoned). https://zonedstorage.io/docs/getting-started/smr-disk (accessed 2026-10-07)
- [n3] Zoned Storage — SMR introduction (drive-managed model). https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-07)
- [n4] Western Digital — WD Red SMR vs CMR NAS drive information. https://support-en.wd.com/app/answers/detailweb/a_id/29458 (accessed 2026-10-07)
- [skylight] Aghayev and Desnoyers: Skylight, FAST 2015, sections 4.5-4.6. https://www.usenix.org/system/files/conference/fast15/fast15-paper-aghayev.pdf (accessed 2026-10-15)
- [zoned] Zoned Storage: Shingled Magnetic Recording Hard Disks. https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-15)
- [analysis] Hesela: SMR stalls, cache limits and the errors SMART can miss. https://hesela.com/analyses/smr-drive-failure-signatures/ (accessed 2026-10-15)

### NAND die stacking

URL: https://hesela.dev/terms/die-stacking/
Status: shipping

Stacking multiple flash dies in one package to increase capacity per socket.

Related terms:
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [v-nand](https://hesela.dev/terms/v-nand/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] NAND die stacking. https://en.wikipedia.org/wiki/3D_NAND (accessed 2026-03-26)

### Differential backup

URL: https://hesela.dev/terms/differential-backup/
Status: shipping

Record updated: 2026-10-14

A differential backup captures changes accumulated since its designated full-backup base, rather than only changes since the preceding differential backup.

Note: In SQL Server, changed extents are tracked against the differential base; COPY_ONLY full backups do not reset that base. [sql-differential] Terminology varies: SNIA's differential incremental backup instead refers to changes since the latest full or incremental backup, so it is not used here as an alias. [snia-differential]

Advantages:
- SQL Server restores the matching base and selected differential without earlier differentials. (sources: [sql-differential])

Limitations:
- The matching differential base must be retained; the newest full backup is not necessarily that base. (sources: [sql-differential])

Related terms:
- [full-backup](https://hesela.dev/terms/full-backup/)
- [incremental-backup](https://hesela.dev/terms/incremental-backup/)
- [backup](https://hesela.dev/terms/backup/)
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)
- [restore-test](https://hesela.dev/terms/restore-test/)

Citations:
- [sql-differential] Microsoft SQL Server: Differential backups and differential bases. https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/differential-backups-sql-server?view=sql-server-ver17 (accessed 2026-10-14)
- [snia-differential] SNIA Dictionary: differential incremental backup. https://www.snia.org/education/online-dictionary/term/differential-incremental-backup (accessed 2026-10-14)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-14)

### Differential observability

URL: https://hesela.dev/terms/differential-observability/
Status: unknown

Record updated: 2026-10-13

Differential observability is a difference between entities' observations of the same system's health.

Note: The gray-failure case is asymmetric: the application observes trouble and the internal observer does not; a detector noticing a problem before an application is affected is a different case. [huang-hotos17]

Related terms:
- [gray-failure](https://hesela.dev/terms/gray-failure/)
- [fail-slow](https://hesela.dev/terms/fail-slow/)

Citations:
- [huang-hotos17] Huang et al., Gray Failure: The Achilles' Heel of Cloud-Scale Systems, HotOS 2017, section 3; DOI 10.1145/3102980.3103005.. https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/paper-1.pdf (accessed 2026-10-13)
- [hesela-observers] Hesela: Fail-slow NVMe SSDs: what SMART and heartbeats miss. https://hesela.com/analyses/nvme-fail-slow-unseen-by-smart/ (accessed 2026-10-13)

### Direct-I/O alignment

URL: https://hesela.dev/terms/direct-io-alignment/
Also known as: DIO alignment
Status: shipping

Record updated: 2026-10-14

Direct-I/O alignment is the per-file constraint on memory addresses, file offsets and I/O segment lengths used for direct transfers.

Note: On Linux, inspect the returned statx mask before interpreting alignment fields: an absent STATX_DIOALIGN bit means unknown, whereas reported zero base fields mean unsupported direct I/O. A reported nonzero read-specific field can relax read offset and length requirements without relaxing memory alignment. [statx-2]

Advantages:
- Makes direct-transfer eligibility explicit instead of assuming a universal sector size.

Limitations:
- Alignment metadata does not prove execution mode, atomicity or durability.

Related terms:
- [direct-io](https://hesela.dev/terms/direct-io/)
- [buffered-io](https://hesela.dev/terms/buffered-io/)
- [page-cache](https://hesela.dev/terms/page-cache/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)

Citations:
- [statx-2] Linux man-pages: statx(2), returned masks and direct-I/O alignment fields.. https://man7.org/linux/man-pages/man2/statx.2.html (accessed 2026-10-14)

### Direct I/O

URL: https://hesela.dev/terms/direct-io/
Also known as: O_DIRECT
Status: shipping

Record updated: 2026-10-14

Direct I/O is a file-access mode, such as Linux O_DIRECT, that requests I/O through user-space buffers while minimizing use of the local operating-system page cache.

Note: On Linux, O_DIRECT (supported since kernel 2.4.10) tries to minimize cache effects by doing I/O directly to and from user-space buffers; performance depends on the workload, so the manual recommends treating it as an optional optimization rather than a default. It is not a durability guarantee: on its own it makes an effort to transfer data synchronously but does not give the guarantees of O_SYNC, which must be added to guarantee that data and necessary metadata are transferred. Alignment rules vary by filesystem and kernel version and may be absent entirely: Linux 2.4 generally required offsets, lengths and buffer addresses to be multiples of the filesystem block size (typically 4096 bytes), Linux 2.6.0 relaxed this to the device logical block size (typically 512 bytes), and since Linux 6.1 statx() with STATX_DIOALIGN can report the restrictions. Misaligned requests can fail with EINVAL or fall back to buffered I/O, and filesystems that do not implement the flag make open() fail with EINVAL. With NFS the flag cannot be passed to the server, so only the client page cache is bypassed. The man page recommends treating O_DIRECT as a performance option that is disabled by default. OpenZFS v2.3 separately documents verification of in-flight Direct I/O buffers and reports these errors with zpool status -d; such an event does not alone identify media damage. [openzfs-dio] Read returned statx mask bits before interpreting fields: an absent STATX_DIOALIGN bit leaves support unknown; reported zero base alignment fields mean unsupported direct I/O. Read-specific alignment does not relax memory-buffer alignment. [statx-2]

Advantages:
- Avoids double buffering when an application, such as a database, manages its own cache
- Can bypass the local page cache where the filesystem supports direct I/O; remote-server and device caches are separate.
- Linux 6.1 and later can report alignment requirements per file via statx() STATX_DIOALIGN

Limitations:
- Performance depends on request sizes, caching and concurrency; compare equivalent workloads and completion requirements.
- Not a durability guarantee by itself; O_SYNC must be added to guarantee data and metadata transfer
- Offset, length and buffer alignment rules vary by filesystem and kernel; misaligned I/O can fail with EINVAL or fall back to buffered I/O
- Mixing O_DIRECT with buffered I/O or mmap on the same file is discouraged, and private-buffer O_DIRECT I/O must not run concurrently with fork()

Related terms:
- [block-storage](https://hesela.dev/terms/block-storage/)
- [ssd](https://hesela.dev/terms/ssd/)
- [fsync](https://hesela.dev/terms/fsync/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [write-through-cache](https://hesela.dev/terms/write-through-cache/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)
- [512e](https://hesela.dev/terms/512e/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)
- [nvme](https://hesela.dev/terms/nvme/)
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [fault-injection](https://hesela.dev/terms/fault-injection/)
- [direct-io-alignment](https://hesela.dev/terms/direct-io-alignment/)
- [buffered-io](https://hesela.dev/terms/buffered-io/)
- [page-cache](https://hesela.dev/terms/page-cache/)

Citations:
- [c1] open(2) — open, openat, creat (Linux man-pages, O_DIRECT section; Debian bookworm manpages-dev). https://manpages.debian.org/bookworm/manpages-dev/open.2.en.html (accessed 2026-10-11)
- [open-current] Linux man-pages open(2), Debian trixie: O_DIRECT and NFS client/server cache scope.. https://manpages.debian.org/trixie/manpages-dev/open.2.en.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)
- [openzfs-dio] OpenZFS v2.3 zfs(4), zfs_vdev_direct_write_verify: in-flight buffer verification. https://openzfs.github.io/openzfs-docs/man/v2.3/4/zfs.4.html#zfs_vdev_direct_write_verify (accessed 2026-10-14)
- [statx-2] Linux man-pages: statx(2), returned masks and direct-I/O alignment fields.. https://man7.org/linux/man-pages/man2/statx.2.html (accessed 2026-10-14)
- [hesela-alignment] O_DIRECT alignment: query the file, not a fixed block size. https://hesela.com/analyses/o-direct-alignment-by-kernel/ (accessed 2026-10-14)

### Directory fsync

URL: https://hesela.dev/terms/directory-fsync/
Also known as: directory synchronization, parent-directory fsync
Status: shipping

Record updated: 2026-10-15

Directory fsync is synchronization of a directory descriptor to persist directory state, including changes to the names through which files are reached.

Note: On Linux, a file sync does not necessarily persist its directory entry. Keep the name-persistence boundary separate from content persistence when reviewing replacement protocols; directory synchronization is not a transaction across arbitrary files.

Related terms:
- [fsync](https://hesela.dev/terms/fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [atomic-rename](https://hesela.dev/terms/atomic-rename/)
- [hard-link](https://hesela.dev/terms/hard-link/)
- [unlink](https://hesela.dev/terms/unlink/)

Citations:
- [fsync-api] Linux man-pages 6.19, fsync(2): DESCRIPTION and error handling.. https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-11)
- [hesela-rename] Hesela: Atomic rename is not a durable commit. https://hesela.com/analyses/atomic-rename-directory-durability/ (accessed 2026-10-11)

### Discard

URL: https://hesela.dev/terms/discard/
Status: shipping

Record updated: 2026-10-15

A block-storage request indicating that specified logical ranges are no longer needed by the caller.

Note: Linux discard is a storage-stack operation, not a synonym for one wire command. Filesystem-aware fstrim selects unused blocks, while direct blkdiscard acts on device ranges and can destroy live data. A verbose fstrim byte count describes potential discard, not a measurement of newly reclaimed physical space. Passing discard through an encrypted mapping can expose used-space information when discarded ranges remain identifiable; this is not the same as revealing plaintext. Linux v6.12 dm-crypt makes forwarding optional. [dm-crypt-source]

Advantages:
- Allows unused filesystem ranges to be reported without selecting live file data. (sources: [fstrim])

Limitations:
- Zero-filling and secure discard are separate blkdiscard operations; ordinary discard proves neither. (sources: [blkdiscard])

Related terms:
- [trim](https://hesela.dev/terms/trim/)
- [scsi-unmap](https://hesela.dev/terms/scsi-unmap/)
- [nvme](https://hesela.dev/terms/nvme/)
- [unmap](https://hesela.dev/terms/unmap/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [deallocated-read-behavior](https://hesela.dev/terms/deallocated-read-behavior/)
- [dm-crypt](https://hesela.dev/terms/dm-crypt/)

Citations:
- [fstrim] util-linux 2.41.2: fstrim manual, verbose output. https://raw.githubusercontent.com/util-linux/util-linux/v2.41.2/sys-utils/fstrim.8.adoc (accessed 2026-10-11)
- [blkdiscard] util-linux 2.41.2: blkdiscard manual. https://raw.githubusercontent.com/util-linux/util-linux/v2.41.2/sys-utils/blkdiscard.8.adoc (accessed 2026-10-11)
- [hesela-discard] Hesela: Discard is not zeroing. https://hesela.com/analyses/discard-is-not-zeroing/ (accessed 2026-10-11)
- [dm-crypt-source] Linux v6.12: dm-crypt, encryption target, integrity metadata and allow_discards. https://docs.kernel.org/6.12/admin-guide/device-mapper/dm-crypt.html (accessed 2026-10-15)

### Disk shelf

URL: https://hesela.dev/terms/disk-shelf/
Status: shipping

An enclosure providing power, cooling, and SAS/NVMe connectivity to many drives.

Related terms:
- [jbod](https://hesela.dev/terms/jbod/)
- [sas-expander](https://hesela.dev/terms/sas-expander/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)

Citations:
- [c1] Disk shelf. https://en.wikipedia.org/wiki/Disk_array (accessed 2026-03-26)

### Distributed snapshot

URL: https://hesela.dev/terms/distributed-snapshot/
Also known as: global-state snapshot
Status: shipping

Record updated: 2026-10-13

A distributed snapshot records a coordinated global state of participating processes and their communication channels.

Note: In the Chandy-Lamport model, channels are reliable and FIFO with finite delivery delays. Channel state includes messages sent but not yet received at the recorded boundaries. This is not a filesystem snapshot or, by itself, a durable backup.

Related terms:
- [snapshot](https://hesela.dev/terms/snapshot/)
- [application-consistent-snapshot](https://hesela.dev/terms/application-consistent-snapshot/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [backup](https://hesela.dev/terms/backup/)

Citations:
- [chandy-lamport] Chandy and Lamport (1985): Distributed Snapshots: Determining Global States of Distributed Systems, sections 2-4, ACM TOCS 3(1), 63-75. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/Determining-Global-States-of-a-Distributed-System.pdf (accessed 2026-10-13)
- [hesela-recovery] Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-13)

### Distributed spare

URL: https://hesela.dev/terms/distributed-spare/
Also known as: distributed hot spare
Status: shipping

Record updated: 2026-10-13

A distributed spare is replacement capacity spread across multiple devices rather than reserved on a single dedicated spare device.

Note: It permits reconstruction writes to use multiple destinations; placement constraints and reserved capacity still apply.

Related terms:
- [parity-declustering](https://hesela.dev/terms/parity-declustering/)
- [raid](https://hesela.dev/terms/raid/)
- [hot-spare](https://hesela.dev/terms/hot-spare/)
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)

Citations:
- [openzfs] OpenZFS: dRAID how-to, Introduction and Rebuilding to a Distributed Spare (living documentation, functionality introduced in 2.1.0).. https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Pool%20Structure/dRAID%20Howto.html (accessed 2026-10-13)
- [hesela-declustering] Parity declustering: less load per disk, not fewer reads. https://hesela.com/analyses/parity-declustering-rebuild-load/ (accessed 2026-10-13)

### DLT

URL: https://hesela.dev/terms/dlt/
Status: eol

Digital Linear Tape, a mid-range backup cartridge family superseded by LTO in many sites.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)

Citations:
- [c1] DLT. https://en.wikipedia.org/wiki/Digital_Linear_Tape (accessed 2026-03-26)

### dm-crypt

URL: https://hesela.dev/terms/dm-crypt/
Status: shipping

Record updated: 2026-10-15

dm-crypt is a Linux device-mapper target that transparently encrypts and decrypts block-device I/O using the kernel cryptographic API.

Note: The target is distinct from LUKS metadata and from the userspace cryptsetup utility. Its selected cipher and integrity configuration determine the protection. Linux v6.12 ignores discard by default; allow_discards forwards it and may expose allocation information if discarded ranges can later be identified. [dm-crypt-source]

Limitations:
- An encryption mapping is not evidence that authentication is enabled. (sources: [dm-crypt-source], [cryptsetup-source])

Related terms:
- [luks](https://hesela.dev/terms/luks/)
- [xts-aes](https://hesela.dev/terms/xts-aes/)
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)
- [discard](https://hesela.dev/terms/discard/)
- [block-storage](https://hesela.dev/terms/block-storage/)

Citations:
- [dm-crypt-source] Linux v6.12: dm-crypt, encryption target, integrity metadata and allow_discards. https://docs.kernel.org/6.12/admin-guide/device-mapper/dm-crypt.html (accessed 2026-10-15)
- [cryptsetup-source] cryptsetup v2.8.1: LUKS extension and experimental authenticated disk encryption. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.1/man/cryptsetup.8.adoc (accessed 2026-10-15)
- [hesela-encryption] Hesela: Encryption is not authentication. https://hesela.com/analyses/checksums-identity-and-lost-writes/#encryption-boundaries (accessed 2026-10-15)

### dm-integrity recovery mode

URL: https://hesela.dev/terms/dm-integrity-recovery-mode/
Also known as: dm-integrity R mode
Status: shipping

Record updated: 2026-10-15

dm-integrity recovery mode is a Linux device-mapper access mode that bypasses integrity checks and journal replay while disallowing writes through the mapping.

Note: Linux v6.12 documents this mode for recovery when ordinary activation fails; obtaining bytes does not authenticate them. [dm-integrity-source] The v6.12 sync_rw_sb implementation also skips superblock MAC checking in this mode. [integrity-code] It is distinct from normal verified read-only access and from recalculation, which generates replacement tags. [hesela-recovery]

Limitations:
- The mode does not establish freshness, repair content or prove that all other paths to the underlying storage are write-blocked. (sources: [hesela-recovery])

Related terms:
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)
- [block-device-read-only](https://hesela.dev/terms/block-device-read-only/)
- [read-only-mount](https://hesela.dev/terms/read-only-mount/)
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)

Citations:
- [dm-integrity-source] Linux v6.12 documentation: dm-integrity, integrity-tag ownership and journal/direct modes. https://docs.kernel.org/6.12/admin-guide/device-mapper/dm-integrity.html (accessed 2026-10-15)
- [integrity-code] Linux v6.12 dm-integrity.c: dm_integrity_disable_recalculate and sync_rw_sb. https://github.com/torvalds/linux/blob/v6.12/drivers/md/dm-integrity.c (accessed 2026-10-15)
- [hesela-recovery] Hesela: Recovery can stop checking the evidence. https://hesela.com/analyses/checksums-identity-and-lost-writes/#integrity-recovery (accessed 2026-10-15)

### dm-integrity

URL: https://hesela.dev/terms/dm-integrity/
Status: shipping

Record updated: 2026-10-15

dm-integrity is a Linux device-mapper target that stores per-block integrity tags and can generate and verify them when configured with an internal hash.

Note: An upper layer supplying the tags is responsible for checking them; an internal CRC or HMAC has a different threat model. [dm-integrity-source] In authenticated dm-crypt configurations, dm-crypt generates and checks the tags while dm-integrity provides their storage. This does not make every dm-integrity configuration authenticated or encrypted. [dm-crypt-source] Bitmap mode can miss corruption coincident with a crash because dirty-region tags are regenerated. [integritysetup-source] Recovery mode bypasses checking rather than verifying a read-only view. [dm-integrity-source] Journal MAC checks journal addressing; internal-hash replay checks block tags. Superblock read verification requires the configured journal MAC and persisted fixed-HMAC flag, outside recovery mode; a CRC is not adversarial authentication. [integrity-code]

Limitations:
- Journaled mode couples data and tag updates; direct mode can leave mismatches after a crash. This is not application-level transaction atomicity. (sources: [dm-integrity-source])
- Internal hashing does not itself authenticate the superblock. The Linux v6.12 recalculation guard distinguishes data keys, journal keys and the fixed-HMAC format; the legacy override bypasses this guard. Recalculation is not authentication of earlier contents. (sources: [integrity-code], [integrity-fix])

Related terms:
- [checksum](https://hesela.dev/terms/checksum/)
- [dm-verity](https://hesela.dev/terms/dm-verity/)
- [fs-verity](https://hesela.dev/terms/fs-verity/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [dm-crypt](https://hesela.dev/terms/dm-crypt/)
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)
- [dm-integrity-recovery-mode](https://hesela.dev/terms/dm-integrity-recovery-mode/)
- [replay-attack](https://hesela.dev/terms/replay-attack/)
- [rollback-protection](https://hesela.dev/terms/rollback-protection/)

Citations:
- [dm-integrity-source] Linux v6.12 documentation: dm-integrity, integrity-tag ownership and journal/direct modes. https://docs.kernel.org/6.12/admin-guide/device-mapper/dm-integrity.html (accessed 2026-10-15)
- [hesela-integrity] Hesela: Why a valid checksum can still return the wrong data. https://hesela.com/analyses/checksums-identity-and-lost-writes/#linux-verity (accessed 2026-10-15)
- [dm-crypt-source] Linux v6.12: dm-crypt, encryption target, integrity metadata and allow_discards. https://docs.kernel.org/6.12/admin-guide/device-mapper/dm-crypt.html (accessed 2026-10-15)
- [integritysetup-source] cryptsetup v2.8.1: integritysetup, bitmap mode, recalculation, recovery and legacy options. https://raw.githubusercontent.com/mbroz/cryptsetup/v2.8.1/man/integritysetup.8.adoc (accessed 2026-10-15)
- [integrity-code] Linux v6.12 dm-integrity.c: block checks, journal section MAC, superblock verification and recalculation guard. https://github.com/torvalds/linux/blob/v6.12/drivers/md/dm-integrity.c (accessed 2026-10-15)
- [integrity-fix] cryptsetup merge request 128 (2021): HMAC recalculation fix and separate journal/superblock authentication. https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/128 (accessed 2026-10-15)
- [hesela-recovery] Hesela: Recovery can stop checking the evidence. https://hesela.com/analyses/checksums-identity-and-lost-writes/#integrity-recovery (accessed 2026-10-15)
- [hesela-journal] Hesela: The journal needs its own protection boundary. https://hesela.com/analyses/checksums-identity-and-lost-writes/#journal-authentication (accessed 2026-10-15)

### dm-verity

URL: https://hesela.dev/terms/dm-verity/
Status: shipping

Record updated: 2026-10-15

dm-verity is a Linux device-mapper target that verifies a read-only block mapping against a trusted cryptographic root hash.

Note: Authentication of the root is external to ordinary block checking. Optional FEC repairs are checked against the hashes. [dm-verity-source]

Limitations:
- ignore_corruption permits reads after detected corruption; check_at_most_once reduces protection against online changes. (sources: [dm-verity-source])

Related terms:
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)
- [fs-verity](https://hesela.dev/terms/fs-verity/)
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)
- [rollback-protection](https://hesela.dev/terms/rollback-protection/)

Citations:
- [dm-verity-source] Linux v6.12 documentation: dm-verity, parameters, failure policies and hash-tree format. https://docs.kernel.org/6.12/admin-guide/device-mapper/verity.html (accessed 2026-10-15)
- [hesela-integrity] Hesela: Why a valid checksum can still return the wrong data. https://hesela.com/analyses/checksums-identity-and-lost-writes/#linux-verity (accessed 2026-10-15)

### SSD DRAM cache

URL: https://hesela.dev/terms/dram-cache-ssd/
Status: shipping

Record updated: 2026-10-12

SSD DRAM is volatile working memory that can hold address mappings, controller metadata or buffered user data, depending on the design.

Note: DRAM is not itself power-loss protection. Persistence depends on the controller's recovery design and any protection for in-flight data, not simply on the presence of a DRAM chip.

Related terms:
- [ssd](https://hesela.dev/terms/ssd/)
- [ftl](https://hesela.dev/terms/ftl/)
- [hmb](https://hesela.dev/terms/hmb/)
- [mapping-cache](https://hesela.dev/terms/mapping-cache/)
- [translation-page](https://hesela.dev/terms/translation-page/)

Citations:
- [agrawal] Nitin Agrawal, Vijayan Prabhakaran, Ted Wobber, John D. Davis, Mark Manasse and Rina Panigrahy. Design Tradeoffs for SSD Performance. USENIX ATC 2008, pp. 57-70, sections 3.1, 3.4 and 4.. https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal.pdf (accessed 2026-10-12)
- [micron] Micron. How Micron SSDs Handle Unexpected Power Loss, p. 3: client and enterprise countermeasures. Historical M500-era examples, not all current SSDs.. https://assets.micron.com/adobe/assets/urn%3Aaaid%3Aaem%3A1f5ebe25-dc19-4e6f-89d2-31a2c6b69548/original/as/ssd-power-loss-protection-white-paper-lo.pdf (accessed 2026-10-12)
- [hesela] SSD mapping caches: why DRAM size is not a speed rating. https://hesela.com/analyses/ssd-mapping-cache-hmb/ (accessed 2026-10-12)

### Drive-day

URL: https://hesela.dev/terms/drive-day/
Status: shipping

Record updated: 2026-10-12

A drive-day is one drive observed in operation for one day, used as a unit of fleet exposure.

Note: Exposure is additive: 100 drives observed for 10 days contribute 1,000 drive-days. Count only the time covered by the selected observation rule; a fleet's end-of-period headcount is not its exposure. Daily-presence records and SMART power-on hours measure different things and must not be silently substituted.

Related terms:
- [afr](https://hesela.dev/terms/afr/)
- [smart](https://hesela.dev/terms/smart/)
- [right-censoring](https://hesela.dev/terms/right-censoring/)
- [left-truncation](https://hesela.dev/terms/left-truncation/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [annual-replacement-rate](https://hesela.dev/terms/annual-replacement-rate/)

Citations:
- [bb-exposure] Backblaze: 10 Stories From 10 Years of Drive Stats Data, sections 3-4. https://www.backblaze.com/blog/10-stories-from-10-years-of-drive-stats-data/ (accessed 2026-10-10)
- [hesela-methods] Hesela: AFR is a rate, not a one-year failure probability. https://hesela.com/analyses/afr-rate-not-probability/ (accessed 2026-10-10)
- [hesela-age-audit] Hesela: Missing SMART ages and the limits of drive-age comparisons. https://hesela.com/analyses/backblaze-age-missing-data-audit/ (accessed 2026-10-11)

### Drive firmware revision

URL: https://hesela.dev/terms/drive-firmware-revision/
Also known as: drive firmware version
Status: shipping

Record updated: 2026-10-16

A drive firmware revision is the vendor-assigned version identifier reported for the firmware running on a storage drive.

Note: Interpret the identifier with the exact model and OEM/platform, not as a globally comparable number. HPE's separate 32K and 40K issue packages are explicitly not interchangeable. [hpe-guide] Inventory should establish the running revision; Cisco documents management and inquiry paths for its affected drives. [ciscofn] A downloaded update package alone does not demonstrate that the device is remediated. A serial-number advisory lookup may be a historical applicability list rather than a live remediation record: Cisco's 28,224-hour FAQ says its list is not updated after software fixes. [ciscossd]

Related terms:
- [power-on-hours](https://hesela.dev/terms/power-on-hours/)
- [smart](https://hesela.dev/terms/smart/)
- [ssd](https://hesela.dev/terms/ssd/)
- [sas](https://hesela.dev/terms/sas/)

Citations:
- [hpe-guide] HPE SAS SSD remediation guide: separate 32K/40K issues, affected-model matrices and firmware applicability. https://www.hpe.com/us/en/services/sas-ssd-advisory.html (accessed 2026-10-16)
- [dell-d417] Dell D417 release notes, 13 February 2020: logging circular-buffer-index assertion fix. https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=8H6HJ (accessed 2026-10-16)
- [ciscofn] Cisco FN70545, revision 2.0: 40,000-hour failure, C405 firmware and runtime collection. https://www.cisco.com/c/en/us/support/docs/field-notices/705/fn70545.html (accessed 2026-10-16)
- [ciscossd] Cisco SSD issue FAQ: historical serial-number lookup and revision-based identification. https://sec.cloudapps.cisco.com/security/center/resources/ssd (accessed 2026-10-16)

### Drum memory

URL: https://hesela.dev/terms/drum-memory/
Status: eol

Early rotating magnetic drum storage where data was recorded on the outer surface of a metal cylinder.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [ramac](https://hesela.dev/terms/ramac/)

Citations:
- [c1] Drum memory. https://en.wikipedia.org/wiki/Drum_memory (accessed 2026-03-26)

### Dual-actuator HDD

URL: https://hesela.dev/terms/dual-actuator/
Also known as: Mach.2, multi-actuator
Status: shipping

Record updated: 2026-10-16

A dual-actuator HDD is a hard drive with two independently positioning head assemblies that can service different data regions concurrently.

Note: Seagate Exos 2X SAS exposes two LUNs; Exos 2X SATA exposes one device with actuator-specific LBA ranges. The SATA manual documents the Concurrent Positioning Ranges log at 47h. Parallelism is not a guaranteed throughput multiplier, and the two regions remain in one physical-drive failure domain. Dual-stage actuation instead combines coarse and fine head positioning; both designs can coexist. Independent positioning does not mean mechanical isolation: Chen et al. (2021) numerically study vibration coupling, not application throughput or field reliability.

Advantages:
- Concurrent access can increase aggregate throughput when requests reach both actuators. (sources: [n4])

Limitations:
- Copies kept only on the two actuators do not protect against total failure of their shared HDD. (sources: [n4])

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [helium-hdd](https://hesela.dev/terms/helium-hdd/)
- [sas](https://hesela.dev/terms/sas/)
- [sata](https://hesela.dev/terms/sata/)
- [independent-access-range](https://hesela.dev/terms/independent-access-range/)
- [concurrent-positioning-range](https://hesela.dev/terms/concurrent-positioning-range/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [dual-stage-actuator](https://hesela.dev/terms/dual-stage-actuator/)

Citations:
- [n4] Seagate MACH.2 FAQ, SC702.2-2306US: presentation and shared-drive redundancy. https://www.seagate.com/files/www-content/solutions/mach-2-multi-actuator-hard-drive/files/sc702.2-2101us-mach-2-faq.pdf (accessed 2026-10-16)
- [sata-manual] Seagate Exos 2X18 SATA product manual, Rev. A, sections 1.0 and 2.2.1. https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/manuals/exos-x-2x18/pdf/203859600a.pdf (accessed 2026-10-16)
- [hesela-card] Hesela: dual-actuator HDD host presentation and Linux discovery. https://hesela.com/tech/dual-actuator/ (accessed 2026-10-16)
- [dual-coupling-chen] Chen, Prakash and Horowitz (2021), Adaptive Feedforward Reference Design for Active Vibration Rejection in Multi-Actuator Hard Disk Drives, arXiv:2110.05669v1, sections I-IV. https://arxiv.org/abs/2110.05669v1 (accessed 2026-10-16)

### Dual-port drive

URL: https://hesela.dev/terms/dual-port/
Status: shipping

A drive with two independent data paths to the same media for multipath HA in arrays.

Related terms:
- [sas](https://hesela.dev/terms/sas/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [alua](https://hesela.dev/terms/alua/)

Citations:
- [c1] Dual-port drive. https://en.wikipedia.org/wiki/Multipath_I/O (accessed 2026-03-26)

### Dual-stage actuator (HDD)

URL: https://hesela.dev/terms/dual-stage-actuator/
Also known as: dual-stage servo, DSA
Status: shipping

Record updated: 2026-10-16

A dual-stage HDD actuator combines a coarse positioning stage with a fine positioning stage to control the read/write head.

Note: A voice-coil motor provides long-range motion while a secondary microactuator corrects finer motion near the head. Toshiba's 2011 prototype uses piezoelectric suspension elements; Seagate's 2017 SkyHawk paper documents VCM and PZT stages in a product. Two servo stages do not imply two independently addressable LBA regions or two LUNs. A multi-actuator drive may use dual-stage positioning within each assembly.

Limitations:
- Servo bandwidth or positioning accuracy is not a direct measure of host IOPS, sequential transfer rate or field reliability. (sources: [dual-stage-toshiba])

Related terms:
- [dual-actuator](https://hesela.dev/terms/dual-actuator/)
- [hdd](https://hesela.dev/terms/hdd/)
- [areal-density](https://hesela.dev/terms/areal-density/)

Citations:
- [dual-stage-toshiba] Sasaki and Hara, Toshiba Review 66(11), 2011: dual-stage actuator prototype, sections 2-3. https://toshiba.semicon-storage.com/content/dam/toshiba-ss-v3/master/en/storage/technology-center/ToshibaReview_vol66n11.pdf (accessed 2026-10-16)
- [seagate-skyhawk] Seagate ImagePerfect technology paper TP694.1-1701US, January 2017, page 3: VCM/PZT dual-stage actuation. https://www.seagate.com/files/www-content/product-content/skyhawk/files/image-perfect-smart-safe-solution-cb4-tp694-1-1701us.pdf (accessed 2026-10-16)
- [dual-coupling-chen] Chen, Prakash and Horowitz (2021), Adaptive Feedforward Reference Design for Active Vibration Rejection in Multi-Actuator Hard Disk Drives, arXiv:2110.05669v1, sections I-IV. https://arxiv.org/abs/2110.05669v1 (accessed 2026-10-16)

### DVD PI Sum8

URL: https://hesela.dev/terms/dvd-pi-sum8/
Also known as: PI Sum 8
Status: unknown

Record updated: 2026-10-15

DVD PI Sum8 counts parity-inner rows containing errors over eight consecutive ECC blocks before correction.

Note: The NIST studies describe a threshold of 280 PI errors in this eight-block window [nist2004]. The denominator is not seconds, and the count is neither uncorrectable files nor CD BLER. Record the aggregation window with the value; an unspecified PI count cannot be compared reliably.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [optical-bler](https://hesela.dev/terms/optical-bler/)

Citations:
- [nist2004] Slattery, Lu, Zheng, Byers and Tang. Stability Comparison of Recordable Optical Discs: A Study of Error Rates in Harsh Conditions. J. Res. NIST 109(5), 517-524 (2004), sections 2-4.. https://nvlpubs.nist.gov/nistpubs/jres/109/5/j95sla.pdf (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates, error thresholds and uncertainty. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### DWPD

URL: https://hesela.dev/terms/dwpd/
Status: shipping

Drive Writes Per Day rating expresses how many full-capacity writes an enterprise SSD can sustain daily for a warranty period.

Related terms:
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [tbw](https://hesela.dev/terms/tbw/)
- [program-erase-cycle](https://hesela.dev/terms/program-erase-cycle/)

Citations:
- [c1] DWPD. https://en.wikipedia.org/wiki/Solid-state_drive (accessed 2026-03-26)

### Dynamic layout score

URL: https://hesela.dev/terms/dynamic-layout-score/
Status: research

Record updated: 2026-10-14

Dynamic layout score is a workload-specific locality measure based on the fraction of traced filesystem block requests that are contiguous in logical block address space.

Note: Conway and colleagues used blktrace observations to include metadata and cross-file accesses, beyond a per-file layout measure. The score describes an observed access sequence, not an intrinsic property of a device.

Limitations:
- It does not distinguish small address gaps from large ones.
- It is not throughput, a percentile latency or a NAND physical-placement measurement.

Related terms:
- [filesystem-aging](https://hesela.dev/terms/filesystem-aging/)
- [free-space-fragmentation](https://hesela.dev/terms/free-space-fragmentation/)

Citations:
- [conway17] Conway et al. File Systems Fated for Senescence? Nonsense, Says Science! FAST 2017, pp. 45-58, sections 3.3, 4 and 6.. https://www.usenix.org/system/files/conference/fast17/fast17-conway.pdf (accessed 2026-10-14)

### E1.S

URL: https://hesela.dev/terms/e1-s/
Also known as: E1.S SSD
Status: shipping

A short EDSFF SSD form factor aimed at 1U servers with power and thermal profiles between M.2 and U.2.

Related terms:
- [edsff](https://hesela.dev/terms/edsff/)
- [nvme](https://hesela.dev/terms/nvme/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] Enterprise and Data Center SSD Form Factor. https://en.wikipedia.org/wiki/Enterprise_and_Data_Center_SSD_Form_Factor (accessed 2026-03-26)

### Extended Asynchronous DRAM Refresh

URL: https://hesela.dev/terms/eadr/
Also known as: eADR, enhanced ADR
Status: shipping

Record updated: 2026-10-13

Extended Asynchronous DRAM Refresh is a platform capability that extends persistent-memory power-fail protection to CPU caches.

Note: Intel's third-generation Xeon overview states that supported, detected eADR removes explicit cache-flush requirements but still requires SFENCE and adequate platform stored energy. This is a system capability, not a guarantee inferred solely from a CPU model. [intel-eadr] PMDK's byte persistence granularity still permits ordering barriers; a larger persistence domain is not an application transaction. [pmdk-granularity]

Related terms:
- [adr](https://hesela.dev/terms/adr/)
- [persistence-domain](https://hesela.dev/terms/persistence-domain/)
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [intel-eadr] Intel. Third Generation Xeon Processor Scalable Family on Two Socket Platforms: eADR.. https://www.intel.com/content/www/us/en/developer/articles/technical/third-generation-xeon-scalable-family-overview.html (accessed 2026-10-13)
- [pmdk-granularity] PMDK 1.13.1. libpmem2(7), GRANULARITY (pinned source documentation).. https://github.com/pmem/pmdk/blob/1.13.1/doc/libpmem2/libpmem2.7.md (accessed 2026-10-13)
- [hesela-pmem] Hesela. Persistent memory: DAX is not a durable commit.. https://hesela.com/analyses/pmem-persistence-domains-dax/ (accessed 2026-10-13)

### Early retention loss

URL: https://hesela.dev/terms/early-retention-loss/
Status: shipping

Early retention loss is the rapid initial charge-loss behavior observed after programming some NAND cells.

Note: This describes the initial evolution of charge after programming, not a deadline at which a whole SSD loses files. The cited 2018 measurements used single-vendor 3D MLC chips; raw errors before ECC are not host-visible data-loss events.

Related terms:
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [charge-trap-flash](https://hesela.dev/terms/charge-trap-flash/)
- [data-retention](https://hesela.dev/terms/data-retention/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [retention-interference](https://hesela.dev/terms/retention-interference/)

Citations:
- [luo] Luo, Ghose, Cai, Haratsch and Mutlu. Improving 3D NAND Flash Memory Lifetime by Tolerating Early Retention Loss and Process Variation. POMACS 2018, sections 4.1, 4.3 and 4.4. https://ghose.cs.illinois.edu/papers/18sigmetrics_3dflash.pdf (accessed 2026-10-11)
- [hesela] Hesela: NAND read-retry and evidence boundaries. https://hesela.com/analyses/nand-read-retry-latency/ (accessed 2026-10-11)
- [hesela3d] Hesela: 3D NAND retention, cell architecture and evidence limits. https://hesela.com/analyses/3d-nand-retention-evidence/ (accessed 2026-10-11)

### EDSFF

URL: https://hesela.dev/terms/edsff/
Also known as: E3.S, E1.L, Enterprise & Data Center SSD Form Factor
Status: shipping

Recorded firstSeen: 2020 (sources: [c1])

A family of ruler and short SSD form factors for dense NVMe deployment in servers and JBOD enclosures.

Related terms:
- [e1-s](https://hesela.dev/terms/e1-s/)
- [nvme](https://hesela.dev/terms/nvme/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] Enterprise and Data Center SSD Form Factor. https://en.wikipedia.org/wiki/Enterprise_and_Data_Center_SSD_Form_Factor (accessed 2026-03-26)

### End-to-end data protection

URL: https://hesela.dev/terms/end-to-end-data-protection/
Status: shipping

Record updated: 2026-10-12

End-to-end data protection is an integrity scheme whose generation and verification points span an explicitly defined data path.

Note: Name both endpoints. Metadata generated below the application cannot by itself validate what happened before generation; a consistently sealed wrong payload can pass. This is distinct from persistence, freshness and successful recovery after damage.

Related terms:
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [protection-information](https://hesela.dev/terms/protection-information/)
- [lost-write](https://hesela.dev/terms/lost-write/)
- [misdirected-write](https://hesela.dev/terms/misdirected-write/)
- [checksum](https://hesela.dev/terms/checksum/)
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)

Citations:
- [c1] End-to-end data protection. https://en.wikipedia.org/wiki/End-to-end_data_integrity (accessed 2026-03-26)
- [linux] Linux kernel documentation: Data Integrity, protection boundaries and automatic metadata generation.. https://docs.kernel.org/block/data-integrity.html (accessed 2026-10-11)
- [hesela-integrity] Hesela: checksum, identity and freshness boundaries with executable synthetic examples. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-11)

### Enterprise SSD

URL: https://hesela.dev/terms/enterprise-ssd/
Also known as: datacenter SSD
Status: shipping

Record updated: 2026-10-15

An enterprise SSD is a solid-state drive intended for server, storage-array or other multi-user storage environments.

Note: SNIA SSS PTS 2.0.2 defines enterprise by deployment environment, not a universal product certification [snia-pts]. SNIA's NVMe classification separates enterprise-server and enterprise-storage profiles and allows exceptions; dual ports are not implied by every enterprise label [snia-classification]. Verify the exact model's endurance workload, persistence contract and supported ports. Hardware energy reserve and firmware recovery can protect different data and metadata, so a generic PLP claim needs its documented scope [kingston-plp].

Limitations:
- Performance-test methodology is not a reliability, availability or data-integrity certification. (sources: [snia-pts])
- An endurance rating is workload-dependent, not an exact failure date. (sources: [snia-endurance])

Related terms:
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [nvme](https://hesela.dev/terms/nvme/)
- [sas](https://hesela.dev/terms/sas/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [ftl](https://hesela.dev/terms/ftl/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)
- [ssd](https://hesela.dev/terms/ssd/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)
- [ssd-steady-state](https://hesela.dev/terms/ssd-steady-state/)

Citations:
- [snia-pts] SNIA: Solid State Storage Performance Test Specification 2.0.2, 1 October 2020. Sections 1.3, 1.5, 2.1.6-2.1.7 and 3.1.. https://www.snia.org/sites/default/files/2025-02/SNIA-SSS-PTS-2.0.2.pdf (accessed 2026-10-15)
- [snia-classification] SNIA: NVMe SSD Classification. Enterprise-server and enterprise-storage profiles have different port expectations; profiles allow exceptions.. https://www.snia.org/node/13864 (accessed 2026-10-15)
- [kingston-plp] Kingston: SSD Power Loss Protection. Hardware and firmware protection scope.. https://www.kingston.com/unitedkingdom/en/blog/servers-and-data-centers/ssd-power-loss-protection (accessed 2026-10-15)
- [snia-endurance] SNIA: Endurance of NVMe, SAS, and SATA SSDs. Endurance, workload and deallocation.. https://www.snia.org/sites/default/files/SSSI/NVMe_SAS_SATA_Endurance_White_Paper.pdf (accessed 2026-10-15)

### Entity tag

URL: https://hesela.dev/terms/entity-tag/
Also known as: ETag, HTTP entity tag
Status: shipping

Record updated: 2026-10-15

An entity tag is an opaque HTTP validator assigned by a server to a selected representation for cache validation and conditional requests.

Note: An ETag identifies a representation within the server's validation rules; it is not a portable file digest, a deduplication key, or a monotonically increasing version counter. Preserve the returned value when sending a conditional request rather than deriving one from the object's bytes. In Amazon S3, ETags and explicitly named checksum fields serve different purposes.

Advantages:
- HTTP conditional requests can validate cached representations or reject a write when the supplied validator no longer matches the current representation. (sources: [c1])
- Amazon S3 PutObject and CompleteMultipartUpload accept an existing object's ETag through If-Match for a server-side write precondition. (sources: [c3])

Limitations:
- In S3 general-purpose buckets, an ETag can equal the object-data MD5 for supported single-part operations with plaintext or SSE-S3 encryption, but multipart upload and SSE-KMS or SSE-C do not provide that MD5 guarantee. (sources: [c2])
- S3 ETags reflect object contents, not metadata; matching ETags are not proof that no intervening write or metadata change occurred. (sources: [c2], [c4])
- HTTP If-Match requires strong comparison, so a weak validator such as W/"example" cannot establish a strong match. (sources: [c1])

Related terms:
- [object-storage](https://hesela.dev/terms/object-storage/)
- [conditional-write](https://hesela.dev/terms/conditional-write/)
- [multipart-upload](https://hesela.dev/terms/multipart-upload/)
- [object-version-id](https://hesela.dev/terms/object-version-id/)

Citations:
- [c1] RFC 9110: HTTP Semantics, entity tags and conditional requests. https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.3 (accessed 2026-10-12)
- [c2] Amazon S3 API Reference: Object, ETag semantics. https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html (accessed 2026-10-12)
- [c3] Amazon S3: How to prevent object overwrites with conditional writes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html (accessed 2026-10-12)
- [c4] Object ETags: checksums and conditional writes are different. https://hesela.com/analyses/object-etags-checksums-conditional-writes/ (accessed 2026-10-12)

### Energy-assisted perpendicular magnetic recording (ePMR)

URL: https://hesela.dev/terms/epmr/
Also known as: ePMR, Energy-assisted PMR
Status: shipping

Record updated: 2026-10-16

Energy-assisted perpendicular magnetic recording (ePMR) is Western Digital's write-assist approach in which a DC bias through the write pole makes the write field more consistent, reducing recording jitter.

Note: Western Digital describes the bias as favoring a path for magnetization reversal in the write head [wd-recording-technologies]. This is distinct from MAS-MAMR's microwave-assisted reversal in the recording medium. ePMR is one approach within energy-assisted magnetic recording, not an alias for all EAMR or MAMR; it also does not specify CMR versus SMR track layout [wd-recording-technologies].

Limitations:
- The term identifies Western Digital's described write-assist mechanism, not a universal performance or capacity guarantee.

Related terms:
- [mamr](https://hesela.dev/terms/mamr/)
- [fc-mamr](https://hesela.dev/terms/fc-mamr/)
- [mas-mamr](https://hesela.dev/terms/mas-mamr/)
- [pmr](https://hesela.dev/terms/pmr/)

Citations:
- [wd-recording-technologies] Western Digital: Recording Technologies, pp. 3-5. https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/tech-brief/tech-brief-recording-technologies.pdf (accessed 2026-10-16)

### Erasure coding

URL: https://hesela.dev/terms/erasure-coding/
Status: shipping

Record updated: 2026-10-15

Erasure coding encodes data with redundancy so that missing fragments at known locations can be reconstructed from a sufficient, code-dependent set of surviving fragments.

Note: In systematic storage codes, data fragments are accompanied by coding fragments. Storage factor is total encoded bytes divided by payload bytes, while repair cost also depends on the code and failure pattern. Recovery guarantees must be matched to fragment placement and failure domains. Local parity does not generally confer the same any-subset recovery guarantee as an MDS Reed-Solomon code. Surviving fragments must be correct and belong to the expected codeword. An erasure-only decoder assumes known missing positions; accepting silently damaged input is a different fault model. [rfc5510]

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [cold-archive](https://hesela.dev/terms/cold-archive/)
- [object-storage](https://hesela.dev/terms/object-storage/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [locally-repairable-code](https://hesela.dev/terms/locally-repairable-code/)
- [repair-locality](https://hesela.dev/terms/repair-locality/)
- [repair-read-amplification](https://hesela.dev/terms/repair-read-amplification/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [crush-placement](https://hesela.dev/terms/crush-placement/)
- [maximum-distance-separable-code](https://hesela.dev/terms/maximum-distance-separable-code/)
- [systematic-code](https://hesela.dev/terms/systematic-code/)
- [mean-time-to-data-loss](https://hesela.dev/terms/mean-time-to-data-loss/)
- [normalized-magnitude-data-loss](https://hesela.dev/terms/normalized-magnitude-data-loss/)

Citations:
- [c1] Erasure coding. https://en.wikipedia.org/wiki/Erasure_coding (accessed 2026-03-26)
- [ceph-ec] Ceph Reef: Erasure code, overhead and failure-domain placement. https://docs.ceph.com/en/reef/rados/operations/erasure-code/ (accessed 2026-10-11)
- [hesela-lrc] Local repair is not whole-node repair. https://hesela.com/analyses/lrc-repair-costs-locality/ (accessed 2026-10-11)
- [rfc5510] Lacan, Roca, Peltotalo and Peltotalo. RFC 5510 (2009), sections 3.1, 8.2-8.4: systematic encoding and the erasure-channel assumption.. https://www.rfc-editor.org/rfc/rfc5510.html (accessed 2026-10-13)

### Error-and-erasure decoding

URL: https://hesela.dev/terms/error-and-erasure-decoding/
Also known as: Errors-and-erasures decoding, Bounded-distance error-and-erasure decoding
Status: shipping

Record updated: 2026-10-15

Error-and-erasure decoding reconstructs a codeword while accounting for both known erased positions and incorrect values at unknown positions.

Note: For minimum distance d, a suitable bounded-distance decoder guarantees unique recovery with e errors among the non-erased positions and s erasures when 2e + s < d; for an MDS code this is 2e + s <= n - k. [forney] An erasure-only matrix solver need not locate unknown errors. Outside the guarantee, a single candidate can still be wrong, as the reproducible Hesela example demonstrates. [hesela-errors]

Limitations:
- The bound is a universal unique-decoding guarantee, not a failure probability or a guarantee that every out-of-bound pattern is unrecoverable.
- Decoder capability, trusted positions and codeword identity must be established separately; a code family name is insufficient.

Related terms:
- [symbol-erasure](https://hesela.dev/terms/symbol-erasure/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [maximum-distance-separable-code](https://hesela.dev/terms/maximum-distance-separable-code/)
- [codeword](https://hesela.dev/terms/codeword/)
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)

Citations:
- [forney] G. David Forney. Principles of Digital Communication II, MIT 6.451 (2005), section 6.5.3: bounded-distance erasure-and-error correction.. https://ocw.mit.edu/courses/6-451-principles-of-digital-communication-ii-spring-2005/bb895c1dee9ce0b39d6846e0aa984981_MIT6_451S05_FullLecNotes.pdf (accessed 2026-10-15)
- [senger] Senger, Sidorenko, Schober, Bossert and Zyablov. Adaptive Single-Trial Error/Erasure Decoding of Reed-Solomon Codes (2011), arXiv:1104.0576v1, sections II-V. Full five-page version reviewed.. https://arxiv.org/pdf/1104.0576v1 (accessed 2026-10-15)
- [hesela-errors] Hesela: exact GF(7) errors-and-erasures examples, including an ambiguous observation and false-identification negative control.. https://hesela.com/analyses/reed-solomon-matrix-recovery-guarantees/#errors-erasures (accessed 2026-10-15)

### Error-correcting code

URL: https://hesela.dev/terms/error-correcting-code/
Also known as: ECC, error correction code
Status: shipping

Record updated: 2026-10-12

An error-correcting code adds structured redundancy to data so a decoder can detect and correct specified error patterns.

Note: Correction has limits set by the code and decoder. A decoder may declare failure or miscorrect; successful completion is not an unconditional integrity guarantee. NAND implementations can combine ECC with additional error-detection checks. [cai2017]

Limitations:
- The label ECC alone does not specify a correction budget or end-to-end data protection. (sources: [cai2017])

Related terms:
- [codeword](https://hesela.dev/terms/codeword/)
- [ldpc](https://hesela.dev/terms/ldpc/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [raw-bit-error-rate](https://hesela.dev/terms/raw-bit-error-rate/)
- [uncorrectable-bit-error-rate](https://hesela.dev/terms/uncorrectable-bit-error-rate/)
- [checksum](https://hesela.dev/terms/checksum/)
- [end-to-end-data-protection](https://hesela.dev/terms/end-to-end-data-protection/)

Citations:
- [snia-ecc] SNIA Dictionary: Error Correcting Code.. https://www.snia.org/education/online-dictionary/term/error-correcting-code (accessed 2026-10-12)
- [cai2017] Cai et al. Error Characterization, Mitigation, and Recovery in Flash Memory Based Solid-State Drives (2017), sections II.C and VI.C.. https://research.ece.cmu.edu/safari/pubs/1706.08642.pdf (accessed 2026-10-12)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence.. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-12)

### errseq_t

URL: https://hesela.dev/terms/errseq-t/
Also known as: errseq
Status: shipping

Record updated: 2026-10-15

errseq_t is a Linux kernel datatype that records an error and sequence state so observers can detect failures since their saved cursor.

Note: The 32-bit value records an error and sequence state, not an exact failure count or complete history. Advancing a cursor acknowledges observation, not repair. New observers skip an already-seen error but can still receive an unseen one; reopening is not a reliable historical-error check. The Linux generic writeback path keeps its cursor in the open file description, shared by duplicated descriptors. The pinned Linux v6.12 syncfs path uses a distinct filesystem-level f_sb_err cursor; observing that state does not advance the separate file-level f_wb_err cursor. [sync-source]

Limitations:
- Concurrent users of one observer cursor must serialize cursor updates.
- Finite sequence space can collide; this is not an unlimited event journal.

Related terms:
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [fsync](https://hesela.dev/terms/fsync/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [syncfs](https://hesela.dev/terms/syncfs/)

Citations:
- [linux-errseq] Linux kernel: The errseq_t datatype. https://docs.kernel.org/core-api/errseq.html (accessed 2026-10-13)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-10)
- [filemap-source] Linux v6.12: file_check_and_advance_wb_err in mm/filemap.c. https://github.com/torvalds/linux/blob/v6.12/mm/filemap.c (accessed 2026-10-13)
- [open-source] Linux v6.12: do_dentry_open in fs/open.c. https://github.com/torvalds/linux/blob/v6.12/fs/open.c (accessed 2026-10-13)
- [errseq-source] Linux v6.12: errseq_sample in lib/errseq.c. https://github.com/torvalds/linux/blob/v6.12/lib/errseq.c (accessed 2026-10-13)
- [sync-source] Linux v6.12: syncfs and sync_filesystem in fs/sync.c. https://github.com/torvalds/linux/blob/v6.12/fs/sync.c (accessed 2026-10-15)

### ESCON

URL: https://hesela.dev/terms/escon/
Status: eol

Earlier IBM optical channel link superseded by FICON for mainframe DASD.

Related terms:
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)

Citations:
- [c1] ESCON. https://en.wikipedia.org/wiki/ESCON (accessed 2026-03-26)

### ESDI

URL: https://hesela.dev/terms/esdi/
Also known as: Enhanced Small Disk Interface
Status: eol

Enhanced Small Disk Interface, a faster successor to ST-506 with integrated encoding on the drive.

Related terms:
- [st-506](https://hesela.dev/terms/st-506/)
- [scsi](https://hesela.dev/terms/scsi/)
- [ide](https://hesela.dev/terms/ide/)
- [st-412](https://hesela.dev/terms/st-412/)

Citations:
- [c1] ESDI. https://en.wikipedia.org/wiki/Enhanced_Small_Disk_Interface (accessed 2026-03-26)

### Ext4 fast commit

URL: https://hesela.dev/terms/ext4-fast-commit/
Also known as: Ext4 fast-commit journaling
Status: shipping

Record updated: 2026-10-15

Ext4 fast commit is a journaling mechanism that records metadata deltas for eligible updates instead of a full traditional metadata-block commit.

Note: Linux v6.12 describes this for ordered mode, with fallback to full commits. [journal] Replay targets recorded outcomes rather than blindly repeating procedures; the implementation also documents hardening work, so the design rationale is not a correctness certification. [fast] See the explicitly synthetic interrupted-recovery model. [hesela] In the audited v6.16 ext4_fc_submit_bh path, a barrier-enabled tail requests both REQ_PREFLUSH and REQ_FUA; do not infer zero device flushes from compact records. [tail]

Limitations:
- Lower mean fsync latency need not imply a lower p99; the ATC 2024 paper reports the opposite trade-off in its NFS Varmail experiment, attributed to fallback full commits. (sources: [fastcommit-paper])
- The cited Linux v6.12 mechanism and explanatory model do not certify a deployed kernel or storage stack. (sources: [hesela])

Related terms:
- [journal-checkpoint](https://hesela.dev/terms/journal-checkpoint/)
- [journal-revoke-record](https://hesela.dev/terms/journal-revoke-record/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [logical-journaling](https://hesela.dev/terms/logical-journaling/)
- [physical-journaling](https://hesela.dev/terms/physical-journaling/)
- [cache-flush](https://hesela.dev/terms/cache-flush/)
- [force-unit-access](https://hesela.dev/terms/force-unit-access/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)

Citations:
- [fastcommit-paper] Shirwadkar, Kadekodi and Tso. FastCommit. USENIX ATC 2024, section 6.1 and Figure 12, pp. 165-166.. https://www.usenix.org/system/files/atc24-shirwadkar.pdf (accessed 2026-10-15)
- [journal] Linux v6.12: ext4 Journal (jbd2), layout and fast commits. https://github.com/torvalds/linux/blob/v6.12/Documentation/filesystems/ext4/journal.rst (accessed 2026-10-14)
- [fast] Linux v6.12: fs/ext4/fast_commit.c, replay idempotence and stated limitations. https://github.com/torvalds/linux/blob/v6.12/fs/ext4/fast_commit.c (accessed 2026-10-14)
- [hesela] Hesela: Ext4 journal replay, revocation and repeatable recovery. https://hesela.com/analyses/ext4-journal-replay-revocation/ (accessed 2026-10-14)
- [tail] Linux v6.16: ext4_fc_submit_bh. https://github.com/torvalds/linux/blob/v6.16/fs/ext4/fast_commit.c#L664-L676 (accessed 2026-10-15)

### Ext4 orphan file

URL: https://hesela.dev/terms/ext4-orphan-file/
Also known as: orphan_file, COMPAT_ORPHAN_FILE
Status: shipping

Record updated: 2026-10-15

An ext4 orphan file is an internal metadata file that stores inode-number slots for orphan cleanup when the orphan_file filesystem feature is enabled.

Note: The legacy orphan list starts at s_last_orphan and uses each inode's i_dtime field as a next-inode link. The orphan file instead uses the special inode referenced by s_orphan_file_inum; a zero slot is unused. RO_COMPAT_ORPHAN_PRESENT indicates that entries may require recovery, not that an orphan definitely exists. It is set during writable use and cleared on clean unmount. [linux-ext4-orphan-layout] Unlike COMPAT_ORPHAN_FILE, an unknown RO_COMPAT_ORPHAN_PRESENT bit prevents an older kernel from mounting read-write; clearing it removes this barrier, not restrictions from other features or older checking tools. [linux-ext4-superblock] Linux v6.12 falls back to the legacy list when orphan-file insertion returns ENOSPC. Here ENOSPC can mean no available orphan-file slots or a bounded slot search giving up, not necessarily filesystem-wide space exhaustion. This insertion path does not dynamically grow the preallocated orphan file, and fallback does not itself establish a user-visible operation failure. [linux-v6-12-ext4-orphan] See the paired recovery analysis. [hesela-ext4-orphan-cleanup]

Limitations:
- The feature changes recovery bookkeeping, not unlink semantics or application synchronization requirements. (sources: [linux-ext4-orphan-layout], [linux-unlink-2], [linux-fsync-2])

Related terms:
- [ext4-orphan-inode](https://hesela.dev/terms/ext4-orphan-inode/)
- [inode](https://hesela.dev/terms/inode/)
- [unlink](https://hesela.dev/terms/unlink/)

Citations:
- [linux-ext4-orphan-layout] Linux ext4 documentation: Orphan file (v6.12). https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/Documentation/filesystems/ext4/orphan.rst (accessed 2026-10-15)
- [linux-v6-12-ext4-orphan] Linux v6.12: ext4 orphan inode handling. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/ext4/orphan.c (accessed 2026-10-15)
- [linux-ext4-superblock] Linux ext4 documentation: Super block feature compatibility (v6.12). https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/Documentation/filesystems/ext4/super.rst (accessed 2026-10-15)
- [linux-unlink-2] Linux manual: unlink(2). https://man7.org/linux/man-pages/man2/unlink.2.html (accessed 2026-10-15)
- [linux-fsync-2] Linux manual: fsync(2). https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-15)
- [hesela-ext4-orphan-cleanup] Hesela: ext4 journal replay and orphan cleanup. https://hesela.com/analyses/ext4-journal-replay-revocation/#orphan-cleanup (accessed 2026-10-15)

### Ext4 orphan inode

URL: https://hesela.dev/terms/ext4-orphan-inode/
Also known as: orphan inode (ext4)
Status: shipping

Record updated: 2026-10-15

An ext4 orphan inode is an inode tracked so recovery can finish deletion or remove excess allocations left by an interrupted truncation or extension.

Note: An unlinked file may remain alive while open; ext4 records recovery work so a crash does not leave its inode and blocks permanently allocated. Linked files can also need orphan tracking when truncation or extension spans journal transactions, so orphan does not mean only a file without directory entries. [linux-ext4-orphan-layout] In Linux v6.12, ext4_process_orphan uses the recovered link count: linked inodes are truncated to the recovered inode size, while zero-link inodes are released for deletion. [linux-v6-12-ext4-orphan] See the Hesela analysis for the relationship to journal replay. [hesela-ext4-orphan-cleanup]

Limitations:
- Linux v6.12 increments nr_truncates even after an ext4_truncate error if execution continues; its cleanup count alone does not certify successful repair. Read accompanying errors. (sources: [linux-v6-12-ext4-orphan])
- Cleanup reclaims allocations; it is not undelete, secure sanitization, or an application durability guarantee. (sources: [linux-v6-12-ext4-orphan], [linux-fsync-2])
- In Linux v6.12, cleanup skips a read-only block device but may temporarily permit writes for a read-only filesystem mount on writable media; read-only mounting alone is not a no-write guarantee. (sources: [linux-v6-12-ext4-orphan])

Related terms:
- [inode](https://hesela.dev/terms/inode/)
- [unlink](https://hesela.dev/terms/unlink/)
- [ext4-orphan-file](https://hesela.dev/terms/ext4-orphan-file/)
- [read-only-mount](https://hesela.dev/terms/read-only-mount/)

Citations:
- [linux-ext4-orphan-layout] Linux ext4 documentation: Orphan file (v6.12). https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/Documentation/filesystems/ext4/orphan.rst (accessed 2026-10-15)
- [linux-v6-12-ext4-orphan] Linux v6.12: ext4 orphan inode handling. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/ext4/orphan.c (accessed 2026-10-15)
- [linux-fsync-2] Linux manual: fsync(2). https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-15)
- [hesela-ext4-orphan-cleanup] Hesela: ext4 journal replay and orphan cleanup. https://hesela.com/analyses/ext4-journal-replay-revocation/#orphan-cleanup (accessed 2026-10-15)

### F1 score

URL: https://hesela.dev/terms/f1-score/
Also known as: balanced F-score, F1 measure
Status: shipping

Record updated: 2026-10-14

F1 score is the harmonic mean of precision and recall for a specified positive class and decision threshold.

Note: For binary predictions, F1 = 2TP / (2TP + FP + FN); true negatives do not enter this formula. If TP, FP and FN are all zero, it is undefined; report the software's zero-division convention. F1 is neither recall nor accuracy, and multiclass or multilabel results must state the averaging rule. [sklearn-f1] Separately averaged or median precision and recall do not generally reconstruct an averaged or median F1. [sklearn-metrics]

Limitations:
- A single F1 value does not state how many healthy drives trigger alerts or the operational cost of false alarms; retain precision, recall, prevalence and the counting unit. (sources: [sklearn-metrics])

Related terms:
- [precision](https://hesela.dev/terms/precision/)
- [recall](https://hesela.dev/terms/recall/)
- [false-positive-rate](https://hesela.dev/terms/false-positive-rate/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [average-precision](https://hesela.dev/terms/average-precision/)
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)

Citations:
- [sklearn-f1] scikit-learn: f1_score, binary formula, averaging and zero-division conventions.. https://scikit-learn.org/stable/modules/generated/sklearn.metrics.f1_score.html (accessed 2026-10-14)
- [sklearn-metrics] scikit-learn: precision, recall and F-measures; aggregation and metric denominators.. https://scikit-learn.org/stable/modules/model_evaluation.html#precision-recall-and-f-measures (accessed 2026-10-14)

### F2FS checkpoint

URL: https://hesela.dev/terms/f2fs-checkpoint/
Also known as: F2FS checkpoint pack
Status: shipping

Record updated: 2026-10-15

An F2FS checkpoint records a consistent filesystem recovery point, including information selecting valid metadata-table versions.

Note: The documented checkpoint=disable mode preserves an older recovery view across unmount or shutdown while disabled. In upstream Linux v6.12 and v6.16, the regular-file fsync path can return successful data-writeback status before later recovery-metadata handling when SBI_CP_DISABLED is set. It is not merely a longer checkpoint interval. [manual] [source612] [source616]

Related terms:
- [f2fs](https://hesela.dev/terms/f2fs/)
- [f2fs-roll-forward-recovery](https://hesela.dev/terms/f2fs-roll-forward-recovery/)
- [fsync](https://hesela.dev/terms/fsync/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)

Citations:
- [manual] Linux 6.12 F2FS documentation: checkpoint, recovery and fsync mount policies.. https://docs.kernel.org/6.12/filesystems/f2fs.html (accessed 2026-10-15)
- [source612] Linux v6.12 fs/f2fs/file.c: f2fs_do_sync_file and checkpoint fallback.. https://github.com/torvalds/linux/blob/v6.12/fs/f2fs/file.c (accessed 2026-10-15)
- [source616] Linux v6.16 fs/f2fs/file.c: regular-file writeback and SBI_CP_DISABLED return.. https://github.com/torvalds/linux/blob/v6.16/fs/f2fs/file.c (accessed 2026-10-15)
- [hesela-f2fs] F2FS: when a successful fsync is not a recovery promise. https://hesela.com/analyses/f2fs-checkpoint-fsync-recovery/ (accessed 2026-10-15)

### F2FS roll-forward recovery

URL: https://hesela.dev/terms/f2fs-roll-forward-recovery/
Status: shipping

Record updated: 2026-10-15

F2FS roll-forward recovery reconstructs selected post-checkpoint file updates from recovery-marked node blocks.

Note: Skipping this path changes the recovered view and is not equivalent to disabling future checkpoints. In upstream v6.16, orphan-inode recovery precedes the fsync-data recovery selection; suppressing roll-forward is therefore not a claim that mounting performs no recovery actions. [mount616] The source audit is not a runtime crash test.

Related terms:
- [f2fs](https://hesela.dev/terms/f2fs/)
- [f2fs-checkpoint](https://hesela.dev/terms/f2fs-checkpoint/)
- [fsync](https://hesela.dev/terms/fsync/)
- [btrfs-tree-log](https://hesela.dev/terms/btrfs-tree-log/)

Citations:
- [lee] Lee, Sim, Hwang and Cho (2015). F2FS: A New File System for Flash Storage. FAST 15, pp. 273-286, section 2.7.. https://www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf (accessed 2026-10-15)
- [mount616] Linux v6.16 fs/f2fs/super.c: mount-time recovery and disabled-checkpoint state.. https://github.com/torvalds/linux/blob/v6.16/fs/f2fs/super.c (accessed 2026-10-15)
- [hesela-f2fs] F2FS: when a successful fsync is not a recovery promise. https://hesela.com/analyses/f2fs-checkpoint-fsync-recovery/ (accessed 2026-10-15)

### F2FS

URL: https://hesela.dev/terms/f2fs/
Also known as: Flash-Friendly File System
Status: shipping

Record updated: 2026-10-15

F2FS is a Linux log-structured filesystem designed for flash storage devices that expose a block interface.

Note: Its original design combines checkpoint-based recovery with a roll-forward path for selected synchronized file updates. These mechanisms differ from a database WAL and do not replace application transaction protocols. [lee]

Related terms:
- [f2fs-checkpoint](https://hesela.dev/terms/f2fs-checkpoint/)
- [f2fs-roll-forward-recovery](https://hesela.dev/terms/f2fs-roll-forward-recovery/)
- [ftl](https://hesela.dev/terms/ftl/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [lee] Lee, Sim, Hwang and Cho (2015). F2FS: A New File System for Flash Storage. FAST 15, pp. 273-286, section 2.7.. https://www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf (accessed 2026-10-15)
- [hesela-f2fs] F2FS: when a successful fsync is not a recovery promise. https://hesela.com/analyses/f2fs-checkpoint-fsync-recovery/ (accessed 2026-10-15)

### Fail-slow

URL: https://hesela.dev/terms/fail-slow/
Also known as: fail-slow failure, hardware performance fault
Status: unknown

Record updated: 2026-10-15

Fail-slow describes a component that remains operational but performs more slowly than expected for its operating conditions.

Note: A slowdown is an observed performance symptom, not proof of a particular physical defect or imminent fail-stop event. Hardware, firmware and workload context must be separated. Gray failure additionally concerns a disagreement between application and system observations. [gunawi-fast18] [huang-hotos17]

Related terms:
- [gray-failure](https://hesela.dev/terms/gray-failure/)
- [differential-observability](https://hesela.dev/terms/differential-observability/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)
- [slowdown-ratio](https://hesela.dev/terms/slowdown-ratio/)
- [tail-latency](https://hesela.dev/terms/tail-latency/)

Citations:
- [gunawi-fast18] Gunawi et al., Fail-Slow at Scale, FAST 2018; hardware performance faults and study limits.. https://www.usenix.org/system/files/conference/fast18/fast18-gunawi.pdf (accessed 2026-10-13)
- [huang-hotos17] Huang et al., Gray Failure: The Achilles' Heel of Cloud-Scale Systems, HotOS 2017, section 3; DOI 10.1145/3102980.3103005.. https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/paper-1.pdf (accessed 2026-10-13)
- [hesela-observers] Hesela: Fail-slow NVMe SSDs: what SMART and heartbeats miss. https://hesela.com/analyses/nvme-fail-slow-unseen-by-smart/ (accessed 2026-10-13)
- [hesela-tail] Hesela: Slow RAID hours are not request tail latency; source audit and reproducible counterexamples. https://hesela.com/analyses/storage-tail-slowdowns-raid-fanout/ (accessed 2026-10-15)

### Logical failover slot

URL: https://hesela.dev/terms/failover-slot/
Also known as: PostgreSQL failover slot
Status: shipping

Record updated: 2026-10-16

A PostgreSQL logical failover slot is a logical replication slot enabled for synchronization to a physical standby so consumption can resume after promotion.

Note: The failover flag enables synchronization; it does not prove a usable copy exists on the target standby. [pg-failover] PostgreSQL 18 readiness requires a complete slot inventory and persistent, valid, synchronized copies. [pg-failover]

Limitations:
- A temporary synchronized slot cannot support post-promotion continuation, and slot copying cannot restore WAL or catalog history already removed from the standby. (sources: [pg-decoding])
- Readiness is point-in-time evidence, not proof of fencing, exactly-once consumer effects or a universal zero-loss guarantee. (sources: [hesela-replication])
- Requesting an older LSN cannot rewind logical streaming before confirmed_flush_lsn; a reconnect alone does not establish that missing consumer history was replayed. (sources: [pg-logical-start])

Related terms:
- [replication-slot](https://hesela.dev/terms/replication-slot/)
- [logical-decoding](https://hesela.dev/terms/logical-decoding/)
- [hot-standby-feedback](https://hesela.dev/terms/hot-standby-feedback/)
- [replication-lag](https://hesela.dev/terms/replication-lag/)
- [idempotency](https://hesela.dev/terms/idempotency/)

Citations:
- [pg-failover] PostgreSQL 18: logical replication failover. https://www.postgresql.org/docs/18/logical-replication-failover.html (accessed 2026-10-16)
- [pg-decoding] PostgreSQL 18: replication slot synchronization. https://www.postgresql.org/docs/18/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS-SYNCHRONIZATION (accessed 2026-10-16)
- [hesela-replication] Hesela: Replication acknowledgements and logical failover readiness. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-16)
- [pg-logical-start] PostgreSQL 18: START_REPLICATION SLOT LOGICAL and confirmed_flush_lsn. https://www.postgresql.org/docs/18/protocol-replication.html#PROTOCOL-REPLICATION-START-REPLICATION-SLOT-LOGICAL (accessed 2026-10-16)

### Failure burst

URL: https://hesela.dev/terms/failure-burst/
Also known as: Failure burst (adjacent-gap rule)
Status: shipping

Record updated: 2026-10-16

Under an adjacent-gap rule, a failure burst is a maximal sequence of event starts in which every consecutive gap is no greater than a specified window.

Note: Ford et al. use this rule for node unavailability. A burst may span longer than its gap limit; a singleton is also a burst. Temporal grouping does not by itself establish a common cause. [ford-osdi10] State the event-selection, timing and boundary conventions before comparing counts.

Related terms:
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [failure-label](https://hesela.dev/terms/failure-label/)
- [failure-operation-ticket](https://hesela.dev/terms/failure-operation-ticket/)

Citations:
- [ford-osdi10] Ford et al. Availability in Globally Distributed Storage Systems. OSDI 2010, section 4.1 and Figure 5.. https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf (accessed 2026-10-16)

### Failure domain

URL: https://hesela.dev/terms/failure-domain/
Also known as: fault domain
Status: shipping

Record updated: 2026-10-16

A failure domain is a group of components that can be affected by the same failure event because they share a dependency or physical location.

Note: Hosts, racks, power supplies and network paths can define different failure domains. [ford-domains] Placing redundant data on separate hosts does not necessarily separate it across racks or power sources. [ceph-crush] Domain boundaries describe the failures a placement policy is intended to isolate; they do not prove statistical independence between components in different domains.

Related terms:
- [crush-placement](https://hesela.dev/terms/crush-placement/)
- [placement-group](https://hesela.dev/terms/placement-group/)
- [mirroring](https://hesela.dev/terms/mirroring/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [failure-burst](https://hesela.dev/terms/failure-burst/)

Citations:
- [ford-domains] Ford et al., Availability in Globally Distributed Storage Systems, OSDI 2010, section 4: failure domains. https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ford.pdf (accessed 2026-10-13)
- [ceph-crush] Ceph Squid documentation: CRUSH Maps, hierarchy and placement rules. https://docs.ceph.com/en/squid/rados/operations/crush-map/ (accessed 2026-10-13)
- [hesela-availability] Storage availability and correlated failures: placement boundaries. https://hesela.com/analyses/storage-availability-correlated-failures/ (accessed 2026-10-13)

### Failure label

URL: https://hesela.dev/terms/failure-label/
Also known as: failure target
Status: shipping

Record updated: 2026-10-16

A failure label is a recorded outcome assigned to an observation under an explicit rule defining which event counts as failure and when it occurs.

Note: Specify the event, counting unit and timestamp. Lu et al. use the operator's disk replacement decision after failed I/O and unsuccessful restart. [lu-fast20] Narya instead targets customer-impacting host failures later attributed to hardware faults; a permanent component failure can occur later. [levy-osdi20]

Limitations:
- A replacement record is not automatically a physical failure or a service outage; changing the target changes the prediction task. (sources: [lu-fast20], [levy-osdi20])

Related terms:
- [prediction-horizon](https://hesela.dev/terms/prediction-horizon/)
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)
- [grouped-cross-validation](https://hesela.dev/terms/grouped-cross-validation/)
- [smart](https://hesela.dev/terms/smart/)
- [right-censoring](https://hesela.dev/terms/right-censoring/)
- [failure-operation-ticket](https://hesela.dev/terms/failure-operation-ticket/)

Citations:
- [lu-fast20] Lu et al. Making Disk Failure Predictions SMARTer! FAST 2020, section 2.1, p. 153.. https://www.usenix.org/system/files/fast20-lu.pdf (accessed 2026-10-14)
- [levy-osdi20] Levy et al. Predictive and Adaptive Failure Mitigation to Avert Production Cloud VM Interruptions. OSDI 2020, section 4.3 and Figure 2, p. 1159.. https://www.usenix.org/system/files/osdi20-levy.pdf (accessed 2026-10-14)

### Failure operation ticket

URL: https://hesela.dev/terms/failure-operation-ticket/
Also known as: FOT
Status: shipping

Record updated: 2026-10-16

A failure operation ticket is a management-system record of a detected hardware problem and its handling status, rather than necessarily a unique failed component.

Note: Wang et al. analyze repair and unrepaired ticket categories, excluding false alarms. A repeated symptom after closure can produce another record; closing a ticket with an action does not establish completed physical repair. [wang-dsn17] Keep ticket, component, incident and exposure counts distinct.

Related terms:
- [failure-label](https://hesela.dev/terms/failure-label/)
- [rate-of-occurrence-of-failures](https://hesela.dev/terms/rate-of-occurrence-of-failures/)
- [failure-burst](https://hesela.dev/terms/failure-burst/)

Citations:
- [wang-dsn17] Wang, Zhang and Xu. What Can We Learn from Four Years of Data Center Hardware Failures? DSN 2017, sections II and III-D.. https://netman.aiops.org/~peidan/ANM2019/9.EventPrediction/ReadingList/2017DSN_What%20Can%20We%20Learn%20from%20Four%20Years%20of%20Data%20Center%20Hardware%20Failures.pdf (accessed 2026-10-16)

### False positive rate

URL: https://hesela.dev/terms/false-positive-rate/
Also known as: FPR, false alarm rate
Status: shipping

Record updated: 2026-10-15

The false positive rate is the fraction of observed negative cases incorrectly classified as positive at a specified decision threshold.

Note: FPR = FP / (FP + TN), with FP false positives and TN true negatives, so FPR equals one minus specificity. It is undefined without observed negatives. The fraction of alerts that are false is instead FP / (TP + FP), or one minus precision when alerts exist. [sklearn-confusion] State the denominator whenever using the ambiguous phrase false alarm rate. Low FPR need not imply high precision when failures are rare. [saito2015]

Related terms:
- [precision](https://hesela.dev/terms/precision/)
- [recall](https://hesela.dev/terms/recall/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [smart](https://hesela.dev/terms/smart/)
- [adaptive-scrubbing](https://hesela.dev/terms/adaptive-scrubbing/)

Citations:
- [sklearn-confusion] scikit-learn: model evaluation, confusion-matrix rates.. https://scikit-learn.org/stable/modules/model_evaluation.html#multilabel-confusion-matrix (accessed 2026-10-12)
- [saito2015] Saito and Rehmsmeier. The Precision-Recall Plot Is More Informative than the ROC Plot When Evaluating Binary Classifiers on Imbalanced Datasets. PLOS ONE 10(3): e0118432 (2015).. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0118432 (accessed 2026-10-12)
- [hesela-prediction] Hesela: disk failure prediction, metric denominators and a synthetic alert-count example.. https://hesela.com/analyses/ml-disk-failure-prediction/ (accessed 2026-10-12)

### FastCDC

URL: https://hesela.dev/terms/fastcdc/
Also known as: Fast Content-Defined Chunking
Status: shipping

Record updated: 2026-10-12

FastCDC is a content-defined chunking approach that combines Gear-based boundary selection, sub-minimum skipping and chunk-size normalization.

Note: The 2016 design changes boundary-test strictness before and after a target length. Normalization narrows the size distribution rather than making chunks fixed-sized; reported speedups apply to the paper's implementations and workloads, not every backup system. [fastcdc]

Related terms:
- [content-defined-chunking](https://hesela.dev/terms/content-defined-chunking/)
- [rolling-hash](https://hesela.dev/terms/rolling-hash/)
- [deduplication](https://hesela.dev/terms/deduplication/)

Citations:
- [fastcdc] Wen Xia, Yukun Zhou, Hong Jiang, Dan Feng, Yu Hua, Yuchong Hu, Yucheng Zhang and Qing Liu. FastCDC: A Fast and Efficient Content-Defined Chunking Approach for Data Deduplication. USENIX ATC 2016, pp. 101-114, sections 4-5.. https://www.usenix.org/system/files/conference/atc16/atc16-paper-xia.pdf (accessed 2026-10-12)
- [hesela-cdc] Content-defined chunking: boundaries are not identity. https://hesela.com/analyses/content-defined-chunking-boundaries/ (accessed 2026-10-12)

### Fault injection

URL: https://hesela.dev/terms/fault-injection/
Also known as: Fault-injection testing
Status: research

Record updated: 2026-10-14

Fault injection is a testing method that deliberately introduces specified faults into a system to observe detection, propagation and recovery under a defined workload.

Note: Report the injection point, fault selection, timing, workload, trial count and correctness oracle. A high failure fraction under deliberately injected faults does not estimate how often those faults occur in service. Distinguish observed multi-fault trials from a single-fault estimate derived under independence assumptions. [zhang2010] The companion arithmetic audit publishes observed and derived values separately. [hesela-arithmetic]

Limitations:
- Coverage is bounded by the injected fault model and the observation procedure; absence of an observed failure is not proof that all faults are tolerated. (sources: [zhang2010])

Related terms:
- [checksum](https://hesela.dev/terms/checksum/)
- [end-to-end-data-protection](https://hesela.dev/terms/end-to-end-data-protection/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [bounded-crash-testing](https://hesela.dev/terms/bounded-crash-testing/)
- [crash-test-oracle](https://hesela.dev/terms/crash-test-oracle/)

Citations:
- [zhang2010] Zhang et al., End-to-end Data Integrity for File Systems: A ZFS Case Study, FAST 2010, sections 4-6. https://www.usenix.org/events/fast10/tech/full_papers/zhang.pdf (accessed 2026-10-14)
- [hesela-review] Hesela: ZFS and Btrfs checksum counters, with observed-versus-derived arithmetic. https://hesela.com/analyses/filesystem-checksum-error-detection/ (accessed 2026-10-14)
- [hesela-arithmetic] Hesela: executable arithmetic audit of published fault-injection summary percentages (JSON with code provenance). https://hesela.dev/research/fault-injection-arithmetic.json (accessed 2026-10-14)

### Flux-control microwave-assisted magnetic recording (FC-MAMR)

URL: https://hesela.dev/terms/fc-mamr/
Also known as: FC-MAMR, Flux Control MAMR
Status: shipping

Record updated: 2026-10-16

Flux-control microwave-assisted magnetic recording (FC-MAMR) is Toshiba's HDD write-assist technique that uses a spintronic device between the write poles to redirect magnetic flux toward the recording medium and strengthen the write field.

Note: Toshiba's 2021 account places the device between the main and auxiliary poles; flux control avoids requiring media designed for microwave resonance [toshiba-fc-mamr-2021]. This identifies the assist mechanism, not an absence of all oscillation in the device. Toshiba's 2021 MG09 technical article distinguishes its commercial FC-MAMR implementation from MAS-MAMR's microwave-assisted media switching [toshiba-mg09-2021]. The MG09 design also uses per-head STO voltage control and applies the bias only during writing to limit device degradation [toshiba-fc-bias-2021]; this does not quantify fleet reliability.

Limitations:
- A product's MAMR label does not by itself establish that it uses microwave-assisted media switching.

Related terms:
- [mamr](https://hesela.dev/terms/mamr/)
- [mas-mamr](https://hesela.dev/terms/mas-mamr/)
- [epmr](https://hesela.dev/terms/epmr/)
- [pmr](https://hesela.dev/terms/pmr/)

Citations:
- [toshiba-fc-mamr-2021] Toshiba: Science and Technology Highlights 2021, section 1.12, p. 15. https://www.global.toshiba/content/dam/toshiba/ww/technology/corporate/review/2021/toshiba-review-science-and-technology-highlights-2021/2101.pdf#page=15 (accessed 2026-10-16)
- [toshiba-mg09-2021] Toshiba: High-Reliability FC-MAMR Nearline HDD with a Capacity of 18 TB (2021), pp. 1-2. https://toshiba.semicon-storage.com/content/dam/toshiba-ss-v3/master/en/storage/product/data-center-enterprise/202102025_nearlineHDD_18TB_e.pdf (accessed 2026-10-16)
- [toshiba-fc-bias-2021] Takeo and Sugiyama: Toshiba Review 76(6), pp. 7-10 (2021), section 5, p. 10: STO degradation prevention (Japanese). https://www.global.toshiba/content/dam/toshiba/jp/technology/corporate/review/2021/06/a03.pdf#page=4 (accessed 2026-10-16)

### FCoE

URL: https://hesela.dev/terms/fcoe/
Status: limited

Fibre Channel over Ethernet tunnels FC frames on lossless Ethernet for converged data center networks.

Related terms:
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [iscsi](https://hesela.dev/terms/iscsi/)
- [alua](https://hesela.dev/terms/alua/)

Citations:
- [c1] FCoE. https://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet (accessed 2026-03-26)

### fdatasync

URL: https://hesela.dev/terms/fdatasync/
Also known as: fdatasync()
Status: shipping

Record updated: 2026-10-15

fdatasync is a file-synchronization operation that persists modified data and the metadata required to retrieve it, without requiring synchronization of all other file metadata.

Note: File-size changes must be synchronized because retrieval depends on them; timestamp-only changes need not be. Like a file fsync, fdatasync does not establish persistence of its containing directory entry. Check errors before acknowledging a commit.

Advantages:
- Can avoid metadata work that is unnecessary for data retrieval.

Limitations:
- Not a transaction across files or a substitute for directory synchronization.
- Less required metadata work does not guarantee lower latency on every filesystem.

Related terms:
- [fsync](https://hesela.dev/terms/fsync/)
- [msync](https://hesela.dev/terms/msync/)
- [sync-file-range](https://hesela.dev/terms/sync-file-range/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [o-dsync](https://hesela.dev/terms/o-dsync/)
- [o-sync](https://hesela.dev/terms/o-sync/)

Citations:
- [fsync-api] Linux man-pages 6.19: fsync(2), fdatasync metadata requirements. https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-13)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-13)

### Fencing token

URL: https://hesela.dev/terms/fencing-token/
Status: shipping

Record updated: 2026-10-11

A fencing token identifies an ownership generation that a receiving service checks to reject operations from an obsolete owner.

Note: Chubby's sequencer includes the lock name, acquisition mode and generation. The receiving service must validate it; merely issuing or attaching a token does not enforce exclusion. This is distinct from a SCSI registration key. Correct recovery of the recipient's validation state is part of the protection, not a property supplied by an arbitrary counter.

Related terms:
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [scsi-persistent-reservations](https://hesela.dev/terms/scsi-persistent-reservations/)

Citations:
- [chubby] Mike Burrows. The Chubby lock service for loosely-coupled distributed systems. OSDI 2006, sections 2.1 and 2.4.. https://www.usenix.org/legacy/event/osdi06/tech/full_papers/burrows/burrows.pdf (accessed 2026-10-11)
- [hesela-fencing] Storage fencing: why a lost heartbeat does not stop writes. https://hesela.com/analyses/storage-fencing-stale-writes/ (accessed 2026-10-11)

### Fibre Channel

URL: https://hesela.dev/terms/fibre-channel/
Status: limited

A high-speed serial fabric used to attach block storage in enterprise SAN environments.

Related terms:
- [san](https://hesela.dev/terms/san/)
- [sas](https://hesela.dev/terms/sas/)
- [scsi](https://hesela.dev/terms/scsi/)
- [alua](https://hesela.dev/terms/alua/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)

Citations:
- [c1] Fibre Channel. https://en.wikipedia.org/wiki/Fibre_Channel (accessed 2026-03-26)

### FICON

URL: https://hesela.dev/terms/ficon/
Status: limited

Fibre Channel attachment for IBM mainframe storage channels.

Related terms:
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [san](https://hesela.dev/terms/san/)

Citations:
- [c1] FICON. https://en.wikipedia.org/wiki/FICON (accessed 2026-03-26)

### FIEMAP

URL: https://hesela.dev/terms/fiemap/
Also known as: FS_IOC_FIEMAP
Status: shipping

Record updated: 2026-10-16

A Linux ioctl interface that reports file extent mappings and associated state flags over a requested logical byte range.

Note: FIEMAP_FLAG_SYNC synchronizes before mapping, so the query can alter the observed state. DELALLOC also sets UNKNOWN; UNWRITTEN instead describes allocated zero-reading storage. Mappings can change between calls and are not permission to access a mounted filesystem through its block device. Record request flags and check for a full output buffer. Hesela's linked observation compares unsynchronized queries with explicit fsync and FIEMAP synchronization. In upstream Linux v6.8, fiemap_prep uses filemap_write_and_wait rather than fsync for this flag; it is not a substitute for a metadata-durability barrier.

Limitations:
- A count-only query is not a stable snapshot for the following mapping call.
- Returned extents may cross the requested range; LAST can be range-scoped on some implementations.

Related terms:
- [file-extent](https://hesela.dev/terms/file-extent/)
- [delayed-allocation](https://hesela.dev/terms/delayed-allocation/)
- [unwritten-extent](https://hesela.dev/terms/unwritten-extent/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [fiemap-interface] Linux 6.12: FIEMAP ioctl, flags and access restrictions. https://docs.kernel.org/6.12/filesystems/fiemap.html (accessed 2026-10-16)
- [hesela-observer] Hesela: measured FIEMAP observer intervention. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/#observer (accessed 2026-10-16)
- [fiemap-writeback] Linux v6.8 fs/ioctl.c: fiemap_prep writeback implementation. https://raw.githubusercontent.com/torvalds/linux/v6.8/fs/ioctl.c (accessed 2026-10-16)

### File extent

URL: https://hesela.dev/terms/file-extent/
Also known as: filesystem extent
Status: shipping

Record updated: 2026-10-16

A filesystem mapping for a contiguous range of file blocks and the storage blocks backing that range.

Note: Ext4 stores a starting file block, storage block and length for each extent, reducing mapping metadata for contiguous runs; this is a filesystem representation, not a statement about physical NAND placement. A FIEMAP mapping includes state flags, not just addresses; its synchronization option can change the state before reporting it.

Related terms:
- [unwritten-extent](https://hesela.dev/terms/unwritten-extent/)
- [sparse-file](https://hesela.dev/terms/sparse-file/)
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [reflink](https://hesela.dev/terms/reflink/)
- [fiemap](https://hesela.dev/terms/fiemap/)

Citations:
- [ext4-extents] Linux 6.12: ext4 extent tree and mapping format. https://docs.kernel.org/6.12/filesystems/ext4/dynamic.html#extent-tree (accessed 2026-10-13)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)
- [fiemap-interface] Linux 6.12: FIEMAP ioctl, flags and access restrictions. https://docs.kernel.org/6.12/filesystems/fiemap.html (accessed 2026-10-16)

### File preallocation

URL: https://hesela.dev/terms/file-preallocation/
Also known as: file space reservation
Status: shipping

Record updated: 2026-10-16

Reserving filesystem allocation for a file range before the application writes that range's data.

Note: Successful Linux fallocate with mode 0 protects subsequent writes in the allocated range against lack of filesystem space; KEEP_SIZE avoids extending logical length. This is not just an advisory hint. A lower thin pool can still require backing allocations when data is written: an end-to-end capacity reservation is not established by the file operation alone, an inference from the separate layer contracts. Shared extents need an explicit sharing-aware contract; FALLOC_FL_UNSHARE_RANGE can make them private where supported.

Advantages:
- Reserves a selected range before later application writes need its filesystem allocation. (sources: [fallocate])

Limitations:
- Allocation is not proof that future application data has been persisted. (sources: [util-fallocate])
- The fallocate interface also has deallocation and zeroing modes, so the API name alone does not identify preallocation. (sources: [fallocate])
- glibc's posix_fallocate fallback can race concurrent writers when native allocation is unsupported; API choice and error handling matter. (sources: [posix-fallocate])

Related terms:
- [sparse-file](https://hesela.dev/terms/sparse-file/)
- [hole-punching](https://hesela.dev/terms/hole-punching/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [fsync](https://hesela.dev/terms/fsync/)
- [file-extent](https://hesela.dev/terms/file-extent/)
- [unwritten-extent](https://hesela.dev/terms/unwritten-extent/)
- [reflink](https://hesela.dev/terms/reflink/)
- [delayed-allocation](https://hesela.dev/terms/delayed-allocation/)
- [posix-fallocate](https://hesela.dev/terms/posix-fallocate/)

Citations:
- [fallocate] Linux man-pages: fallocate(2), allocation and mode contracts. https://www.man7.org/linux/man-pages/man2/fallocate.2.html (accessed 2026-10-12)
- [util-fallocate] util-linux 2.41.2: fallocate(1), preallocation, punching and zeroing. https://raw.githubusercontent.com/util-linux/util-linux/v2.41.2/sys-utils/fallocate.1.adoc (accessed 2026-10-12)
- [lvmthin] LVM2: lvmthin(7), physical allocation, discards and pool exhaustion. https://man7.org/linux/man-pages/man7/lvmthin.7.html (accessed 2026-10-12)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)
- [posix-fallocate] Linux man-pages: posix_fallocate(3), return convention and glibc caveats. https://man7.org/linux/man-pages/man3/posix_fallocate.3.html (accessed 2026-10-16)

### File storage

URL: https://hesela.dev/terms/file-storage/
Status: shipping

Shared hierarchical files and directories over NFS, SMB, or similar protocols.

Related terms:
- [nas](https://hesela.dev/terms/nas/)
- [object-storage](https://hesela.dev/terms/object-storage/)

Citations:
- [c1] File storage. https://en.wikipedia.org/wiki/File_server (accessed 2026-03-26)

### Filesystem aging

URL: https://hesela.dev/terms/filesystem-aging/
Also known as: file system aging
Status: shipping

Record updated: 2026-10-14

Filesystem aging is the evolution of allocation layout through file operations that can degrade performance even when the logical contents remain comparable.

Note: This is layout history, not calendar age or NAND wear. A benchmark should distinguish within-file placement, locality between related files and the distribution of remaining free space.

Limitations:
- Effects depend on workload, filesystem version, cache policy and hardware.
- Historical aging experiments are not a ranking of current filesystems.

Related terms:
- [free-space-fragmentation](https://hesela.dev/terms/free-space-fragmentation/)
- [dynamic-layout-score](https://hesela.dev/terms/dynamic-layout-score/)
- [ssd-preconditioning](https://hesela.dev/terms/ssd-preconditioning/)
- [ssd-steady-state](https://hesela.dev/terms/ssd-steady-state/)

Citations:
- [conway17] Conway et al. File Systems Fated for Senescence? Nonsense, Says Science! FAST 2017, pp. 45-58, sections 3.3, 4 and 6.. https://www.usenix.org/system/files/conference/fast17/fast17-conway.pdf (accessed 2026-10-14)
- [conway19] Conway et al. Filesystem Aging: It's more Usage than Fullness. HotStorage 2019, sections 3-4 and Figure 3.. https://www.usenix.org/system/files/hotstorage19-paper-conway.pdf (accessed 2026-10-14)

### Filesystem consistency invariant

URL: https://hesela.dev/terms/filesystem-consistency-invariant/
Also known as: File-system consistency invariant
Status: research

Record updated: 2026-10-13

A filesystem consistency invariant is a rule relating filesystem metadata that must hold at a defined consistency boundary.

Note: Recon checked metadata relationships at transaction commit; this differs from validating a block checksum. Its 2012 evaluation was ext3-focused. The 2014 follow-up checked per-write location invariants as well, rather than assuming transactional writes were correct.

Limitations:
- Coverage depends on the specified rules, observation point and implementation; it does not establish application-level correctness. (sources: [recon12], [recon14])

Related terms:
- [checksum](https://hesela.dev/terms/checksum/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)

Citations:
- [recon12] Fryer et al. Recon: Verifying File System Consistency at Runtime. FAST 2012, sections 2, 4.1 and 5. https://www.usenix.org/legacy/events/fast/tech/full_papers/Fryer2-16-12.pdf (accessed 2026-10-13)
- [recon14] Fryer et al. Checking the Integrity of Transactional Mechanisms. FAST 2014, sections 3.1 and 5. https://www.usenix.org/system/files/conference/fast14/fast14-paper_fryer.pdf (accessed 2026-10-13)
- [hesela-scrub] Hesela: Disk scrubbing, checksum coverage and consistency boundaries. https://hesela.com/analyses/scrubbing-detection-not-durability/ (accessed 2026-10-13)

### Filesystem freeze

URL: https://hesela.dev/terms/filesystem-freeze/
Also known as: fsfreeze, Filesystem freezing
Status: shipping

Record updated: 2026-10-15

A filesystem freeze temporarily blocks modifications after completing ongoing filesystem transactions and flushing dirty filesystem data, metadata and logs to storage.

Note: Linux fsfreeze requires a mounted filesystem with freeze support; blocked modifications resume after thaw. [util-linux-freeze] QEMU v10.1.0 freezes eligible local guest filesystems and returns a count, which may be zero; its list variant ignores invalid mountpoints. That count does not establish coverage of every application dependency. [qemu-freeze] Filesystem transactions are not application transactions: application preparation is a separate concern. [microsoft-vss]

Advantages:
- Can establish a stable filesystem image for snapshot-capable storage. (sources: [util-linux-freeze])

Limitations:
- Writers can remain blocked until thaw; a recovery procedure must account for failed capture and cleanup. (sources: [util-linux-freeze])
- Files still undergoing unlink can remain represented in the frozen on-disk image until thaw or a clean mount of the snapshot completes. (sources: [util-linux-freeze])
- A guest-agent status report can be invalidated by another process changing freeze state. (sources: [qemu-freeze])

Related terms:
- [snapshot](https://hesela.dev/terms/snapshot/)
- [application-consistent-snapshot](https://hesela.dev/terms/application-consistent-snapshot/)
- [application-quiescing](https://hesela.dev/terms/application-quiescing/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [restore-test](https://hesela.dev/terms/restore-test/)

Citations:
- [util-linux-freeze] util-linux v2.41.2: fsfreeze(8), filesystem freeze and thaw. https://github.com/util-linux/util-linux/blob/v2.41.2/sys-utils/fsfreeze.8.adoc (accessed 2026-10-15)
- [qemu-freeze] QEMU v10.1.0: guest agent freeze protocol and scope. https://github.com/qemu/qemu/blob/v10.1.0/qga/qapi-schema.json (accessed 2026-10-15)
- [microsoft-vss] Microsoft: Volume Shadow Copy Service, application writers and snapshot coordination. https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service (accessed 2026-10-15)
- [hesela-recovery] Hesela: Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-15)

### Fixed block architecture

URL: https://hesela.dev/terms/fixed-block-architecture/
Status: shipping

SCSI-like fixed sectors adopted on mainframe storage for simplification and FBA volumes.

Related terms:
- [mainframe-dasd](https://hesela.dev/terms/mainframe-dasd/)
- [scsi](https://hesela.dev/terms/scsi/)

Citations:
- [c1] Fixed block architecture. https://en.wikipedia.org/wiki/Direct-access_storage_device (accessed 2026-03-26)

### SSD controller

URL: https://hesela.dev/terms/flash-controller/
Status: shipping

ASIC or SoC managing NAND channels, ECC, and host protocols on an SSD.

Related terms:
- [ssd](https://hesela.dev/terms/ssd/)
- [ftl](https://hesela.dev/terms/ftl/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] SSD controller. https://en.wikipedia.org/wiki/Flash_memory_controller (accessed 2026-03-26)

### Flash module

URL: https://hesela.dev/terms/flash-module/
Status: shipping

A replaceable package of NAND dies and controller used in arrays and custom cards.

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)

Citations:
- [c1] Flash module. https://en.wikipedia.org/wiki/Solid-state_drive (accessed 2026-03-26)

### Floating-gate flash

URL: https://hesela.dev/terms/floating-gate/
Status: shipping

A flash cell design that stores charge on an electrically isolated conductive gate to alter the transistor's threshold voltage.

Note: Floating gate is a charge-storage architecture, not a synonym for planar NAND. Micron's 2016 mobile 3D NAND announcement provides a documented vertical implementation; it is historical product evidence, not a claim of current availability.

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [charge-trap-flash](https://hesela.dev/terms/charge-trap-flash/)
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] Floating-gate flash. https://en.wikipedia.org/wiki/Floating-gate_MOSFET (accessed 2026-03-26)
- [handbook] KIOXIA Reliability Handbook, 2025. Section 2-1-7: floating-gate structure and failure mechanisms. https://www.kioxia.com/content/dam/kioxia/en-jp/about/asset/reliability-handbook-e.pdf (accessed 2026-10-11)
- [micron2016] Micron. Mobile 3D NAND announcement, 9 August 2016: floating-gate architecture. https://investors.micron.com/news/press-release/2016/Micron-Introduces-Mobile-3D-NAND-Solution-for-Next-Generation-Smartphones-08-09-2016/default.aspx (accessed 2026-10-11)
- [hesela3d] Hesela: 3D NAND retention, cell architecture and evidence limits. https://hesela.com/analyses/3d-nand-retention-evidence/ (accessed 2026-10-11)

### Floppy disk

URL: https://hesela.dev/terms/floppy-disk/
Status: eol

Removable flexible magnetic disk media used for software distribution and PC backup before optical and flash.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [tape](https://hesela.dev/terms/tape/)
- [st-412](https://hesela.dev/terms/st-412/)

Citations:
- [c1] Floppy disk. https://en.wikipedia.org/wiki/Floppy_disk (accessed 2026-03-26)

### Fluid dynamic bearing

URL: https://hesela.dev/terms/fluid-dynamic-bearing/
Status: shipping

Spindle motor bearings using lubricant films to reduce vibration in modern HDDs.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)

Citations:
- [c1] Fluid dynamic bearing. https://en.wikipedia.org/wiki/Fluid_dynamic_bearing (accessed 2026-03-26)

### Flying height

URL: https://hesela.dev/terms/flying-height/
Also known as: fly height, head-disk clearance
Status: shipping

Record updated: 2026-10-16

Flying height is the physical clearance between a flying HDD head/slider region and the disk surface.

Note: Specify the measurement location: clearance near the read/write element need not equal clearance elsewhere on the slider. Smaller recording spacing and avoidance of unintended contact impose competing constraints [control]. This is a length, not a SMART event count; no universal present-day nanometer value is assigned here.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [head-disk-interface](https://hesela.dev/terms/head-disk-interface/)
- [thermal-flying-height-control](https://hesela.dev/terms/thermal-flying-height-control/)
- [head-slap](https://hesela.dev/terms/head-slap/)
- [head-gas-bearing](https://hesela.dev/terms/head-gas-bearing/)
- [helium-hdd](https://hesela.dev/terms/helium-hdd/)

Citations:
- [control] Juang and Bogy: Design and Analysis of a Flying Height Control Slider with Thermal Nanoactuator, CML report 06004, sections 1-2. https://cml.berkeley.edu/wp-content/uploads/blue-reports/06004.pdf (accessed 2026-10-15)
- [analysis] Hesela: HDD mechanical faults, evidence and diagnostic limits. https://hesela.com/analyses/hdd-mechanical-failure-points/ (accessed 2026-10-15)

### Force Unit Access

URL: https://hesela.dev/terms/force-unit-access/
Also known as: FUA, REQ_FUA
Status: shipping

Record updated: 2026-10-12

Force Unit Access is a write-request property requiring the flagged data to reach nonvolatile storage before that request is reported complete.

Note: Linux represents this requirement with REQ_FUA. It is distinct from REQ_PREFLUSH, which makes earlier completed writes persistent before the accompanying I/O begins; FUA alone is not that ordering guarantee. The flags can be combined. For devices without native FUA, Linux can implement the requirement with a post-write flush. The name describes completion semantics, not a universal physical bypass of every cache or a guarantee that a multi-block write is atomic.

Advantages:
- Allows persistence to be required for a specific write's completion. (sources: [linux-cache])

Limitations:
- Does not replace the preflush guarantee for previously completed writes. (sources: [linux-cache])

Related terms:
- [cache-flush](https://hesela.dev/terms/cache-flush/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [write-through-cache](https://hesela.dev/terms/write-through-cache/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)

Citations:
- [linux-cache] Linux kernel documentation. Explicit volatile write back cache control: REQ_PREFLUSH and REQ_FUA.. https://docs.kernel.org/block/writeback_cache_control.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)

### Forward assembly area

URL: https://hesela.dev/terms/forward-assembly-area/
Status: research

Record updated: 2026-10-11

A forward assembly area buffers requested chunks in future restore-output order using advance knowledge from the backup recipe.

Note: It retains useful chunks rather than treating whole fetched containers as the only caching unit. [lillibridge2013]

Related terms:
- [deduplication](https://hesela.dev/terms/deduplication/)
- [chunk-fragmentation](https://hesela.dev/terms/chunk-fragmentation/)

Citations:
- [lillibridge2013] Mark Lillibridge, Kave Eshghi and Deepavali Bhagwat. Improving Restore Speed for Backup Systems that Use Inline Chunk-Based Deduplication. USENIX FAST 2013, pp. 183-197; sections 2-4.. https://www.usenix.org/system/files/conference/fast13/fast13-final124.pdf (accessed 2026-10-11)
- [hesela-dedup-restore] Deduplication ratio does not predict restore cost. https://hesela.com/analyses/deduplication-restore-fragmentation/ (accessed 2026-10-11)

### Free-space fragmentation

URL: https://hesela.dev/terms/free-space-fragmentation/
Also known as: free space fragmentation
Status: shipping

Record updated: 2026-10-14

Free-space fragmentation is the division of a filesystem's available allocation space into separated contiguous runs.

Note: The same number of free blocks can have different run sizes and locations. This constrains later allocation, but free space itself is not read in a scan of allocated file contents. Geriatrix targets both allocated-file and free-space layout.

Limitations:
- An occupancy percentage is not a free-extent distribution.
- Logical free runs do not reveal the physical NAND layout behind an SSD's mapping layer.

Related terms:
- [filesystem-aging](https://hesela.dev/terms/filesystem-aging/)
- [dynamic-layout-score](https://hesela.dev/terms/dynamic-layout-score/)
- [ssd-preconditioning](https://hesela.dev/terms/ssd-preconditioning/)

Citations:
- [geriatrix] Kadekodi, Nagarajan, Ganger and Gibson. Geriatrix: Aging what you see and what you don't see. USENIX ATC 2018, pp. 691-704, sections 4-6.. https://www.usenix.org/system/files/conference/atc18/atc18-kadekodi.pdf (accessed 2026-10-14)
- [conway19] Conway et al. Filesystem Aging: It's more Usage than Fullness. HotStorage 2019, sections 3-4 and Figure 3.. https://www.usenix.org/system/files/hotstorage19-paper-conway.pdf (accessed 2026-10-14)

### fs-verity

URL: https://hesela.dev/terms/fs-verity/
Status: shipping

Record updated: 2026-10-15

fs-verity is a Linux filesystem facility that verifies the immutable contents of selected files against a cryptographic file digest.

Note: Its digest binds a descriptor including file size, not only the Merkle root. Authentication policy is separate from enabling verification. [fs-verity-source]

Limitations:
- Names, ownership and mode are outside its measurement; requiring signatures for verity files does not require every file to use verity. (sources: [fs-verity-source])

Related terms:
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)
- [dm-verity](https://hesela.dev/terms/dm-verity/)
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)

Citations:
- [fs-verity-source] Linux v6.12 documentation: fs-verity, descriptor, metadata exclusions and built-in signature limits. https://docs.kernel.org/6.12/filesystems/fsverity.html (accessed 2026-10-15)
- [hesela-integrity] Hesela: Why a valid checksum can still return the wrong data. https://hesela.com/analyses/checksums-identity-and-lost-writes/#linux-verity (accessed 2026-10-15)

### fsync

URL: https://hesela.dev/terms/fsync/
Also known as: fsync()
Status: shipping

Record updated: 2026-10-15

fsync is a file-synchronization operation that requests persistence of a file's modified data and associated metadata before reporting completion.

Note: On Linux, syncing the file does not necessarily persist its containing directory entry; the directory needs its own sync. fdatasync may omit metadata unnecessary for retrieving the data, but must include required file-size changes. A failed sync must be treated as an unresolved durability event, not silently replaced by a later successful return. OpenZFS is an important configuration caveat: sync=disabled ignores application synchronous requests, whereas logbias=throughput changes the storage path without disabling synchronous semantics. [zfs-props] For an asynchronous io_uring sync, establish dependencies on the intended writes before treating its completion as their persistence boundary. [uring-fsync] In F2FS with checkpointing disabled, the audited regular-file fsync path can return successful data-writeback status before recovery metadata; inspect the effective configuration. [f2fs-sync]

Related terms:
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [fdatasync](https://hesela.dev/terms/fdatasync/)
- [msync](https://hesela.dev/terms/msync/)
- [sync-file-range](https://hesela.dev/terms/sync-file-range/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [zfs-intent-log](https://hesela.dev/terms/zfs-intent-log/)
- [io-uring](https://hesela.dev/terms/io-uring/)
- [io-uring-drain](https://hesela.dev/terms/io-uring-drain/)
- [f2fs-checkpoint](https://hesela.dev/terms/f2fs-checkpoint/)
- [syncfs](https://hesela.dev/terms/syncfs/)
- [o-sync](https://hesela.dev/terms/o-sync/)
- [o-dsync](https://hesela.dev/terms/o-dsync/)

Citations:
- [linux-fsync] Linux man-pages 6.19: fsync(2). https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-10)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-10)
- [hesela-rename] Hesela: Atomic rename is not a durable commit. https://hesela.com/analyses/atomic-rename-directory-durability/ (accessed 2026-10-11)
- [zfs-props] OpenZFS 2.3: zfsprops(7), sync and logbias. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zfsprops.7.html (accessed 2026-10-14)
- [uring-fsync] liburing: io_uring_enter(2), IORING_OP_FSYNC ordering. https://man7.org/linux/man-pages/man2/io_uring_enter.2.html (accessed 2026-10-14)
- [f2fs-sync] Linux v6.16 fs/f2fs/file.c: regular-file writeback and SBI_CP_DISABLED return.. https://github.com/torvalds/linux/blob/v6.16/fs/f2fs/file.c (accessed 2026-10-15)
- [hesela-f2fs] F2FS: when a successful fsync is not a recovery promise. https://hesela.com/analyses/f2fs-checkpoint-fsync-recovery/ (accessed 2026-10-15)

### Flash translation layer (FTL)

URL: https://hesela.dev/terms/ftl/
Also known as: FTL
Status: shipping

Record updated: 2026-10-15

A flash translation layer maps host logical addresses to physical flash locations and manages flash-specific operations such as reclamation.

Note: Mapping granularity and in-memory representation are design choices; an FTL is not necessarily a fully resident page table. Recovering the map must distinguish current data from superseded copies. Recovery-order and snapshot guarantees are separate design contracts; see the linked research concepts.

Related terms:
- [ssd](https://hesela.dev/terms/ssd/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [wear-leveling](https://hesela.dev/terms/wear-leveling/)
- [zns](https://hesela.dev/terms/zns/)
- [hmb](https://hesela.dev/terms/hmb/)
- [dram-cache-ssd](https://hesela.dev/terms/dram-cache-ssd/)
- [mapping-cache](https://hesela.dev/terms/mapping-cache/)
- [translation-page](https://hesela.dev/terms/translation-page/)
- [prefix-preserving-crash-consistency](https://hesela.dev/terms/prefix-preserving-crash-consistency/)
- [snapshot-consistent-ftl](https://hesela.dev/terms/snapshot-consistent-ftl/)

Citations:
- [agrawal] Nitin Agrawal, Vijayan Prabhakaran, Ted Wobber, John D. Davis, Mark Manasse and Rina Panigrahy. Design Tradeoffs for SSD Performance. USENIX ATC 2008, pp. 57-70, sections 3.1, 3.4 and 4.. https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal.pdf (accessed 2026-10-12)
- [hesela] SSD mapping caches: why DRAM size is not a speed rating. https://hesela.com/analyses/ssd-mapping-cache-hmb/ (accessed 2026-10-12)

### Full backup

URL: https://hesela.dev/terms/full-backup/
Status: shipping

Record updated: 2026-10-14

A full backup captures every data object within a defined backup scope, whether or not it has changed since an earlier backup.

Note: Full describes coverage of the selected scope, not necessarily an entire server. [snia-full] SQL Server includes enough transaction log in a full database backup to recover it to backup completion; a later recovery point needs subsequent log backups. [sql-full]

Advantages:
- Can provide the complete data baseline for later differential or incremental backups. (sources: [snia-full])

Limitations:
- Complete scope does not mean coverage of changes made after backup completion. (sources: [sql-full])

Related terms:
- [backup](https://hesela.dev/terms/backup/)
- [incremental-backup](https://hesela.dev/terms/incremental-backup/)
- [differential-backup](https://hesela.dev/terms/differential-backup/)
- [synthetic-full-backup](https://hesela.dev/terms/synthetic-full-backup/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)

Citations:
- [snia-full] SNIA Dictionary: full backup. https://www.snia.org/education/online-dictionary/term/full-backup (accessed 2026-10-14)
- [sql-full] Microsoft SQL Server: Full database backups and restore scope. https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/full-database-backups-sql-server?view=sql-server-ver17 (accessed 2026-10-14)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-14)

### Full-page write

URL: https://hesela.dev/terms/full-page-write/
Also known as: full_page_writes
Status: shipping

Record updated: 2026-10-11

A PostgreSQL full-page write records a recoverable page image in WAL to support recovery from an incomplete data-page write.

Note: With full_page_writes enabled, PostgreSQL normally logs a page image on its first modification after a checkpoint. The image provides a reconstruction basis that ordinary change records alone may not supply. This is a PostgreSQL mechanism, not a universal name for all torn-page defenses.

Advantages:
- Supports reconstruction of a page interrupted during writeback. (sources: [pg-settings])

Limitations:
- Adds WAL traffic; it is not a substitute for an independently recoverable backup. (sources: [pg-settings], [pg-archive])

Related terms:
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [torn-write](https://hesela.dev/terms/torn-write/)

Citations:
- [pg-settings] PostgreSQL 18: WAL settings. https://www.postgresql.org/docs/18/runtime-config-wal.html (accessed 2026-10-11)
- [pg-archive] PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery. https://www.postgresql.org/docs/18/continuous-archiving.html (accessed 2026-10-11)
- [hesela-wal] WAL, checkpoints and torn pages: three different recovery guarantees. https://hesela.com/analyses/wal-checkpoints-torn-pages/ (accessed 2026-10-11)

### Full-stripe write

URL: https://hesela.dev/terms/full-stripe-write/
Also known as: full stripe write
Status: shipping

Record updated: 2026-10-11

A parity-array write supplying replacement data for every data position of a stripe so its new parity can be computed without reading the prior stripe contents.

Note: Parity is still written: a healthy stripe with k equal-size data blocks and p parity blocks writes k+p blocks for k blocks of payload in Hesela's model. Covering the stripe requires the appropriate address alignment and aggregation at the parity layer, not merely a host request of matching length. Linux MD's journal may collect writes before destaging; cache capacity and timing constrain that aggregation.

Advantages:
- Eliminates old-data and old-parity reads for parity computation when all replacement data is present

Limitations:
- Does not eliminate parity write traffic, lower-layer overhead or crash-consistency requirements
- Request splitting and misalignment can leave partial stripes
- Early acknowledgement from a write-back journal is a different durability boundary from final member placement

Related terms:
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [reconstruct-write](https://hesela.dev/terms/reconstruct-write/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)

Citations:
- [linux-cache] Linux kernel documentation: RAID 4/5/6 cache, write-back mode and implementation. Rolling documentation; accessed 11 October 2026.. https://www.kernel.org/doc/html/latest/driver-api/md/raid5-cache.html (accessed 2026-10-11)
- [hesela-cost] Hesela: RAID write penalty is not a speed ratio; model and limitations. https://hesela.com/analyses/raid-write-penalty-io-not-speed/ (accessed 2026-10-11)

### Fuzzy checkpoint

URL: https://hesela.dev/terms/fuzzy-checkpoint/
Status: shipping

Record updated: 2026-10-15

A fuzzy checkpoint records recovery information while transaction processing continues, rather than freezing all activity into one instantaneous database image.

Note: In ARIES, the checkpoint records transaction and dirty-page information without forcing dirty pages to storage. Recovery may need older log records. This is neither a backup nor permission to delete every pre-checkpoint log record. Checkpoint metadata and compensation records solve different problems: the former guides restart, while CLRs preserve rollback progress. [aries]

Related terms:
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [compensation-log-record](https://hesela.dev/terms/compensation-log-record/)
- [page-lsn](https://hesela.dev/terms/page-lsn/)

Citations:
- [aries] Mohan, Haderle, Lindsay, Pirahesh and Schwarz. ARIES. ACM TODS 17(1), 1992, pp. 121-122, section 5.4.. https://www.cs.cmu.edu/~15849g/readings/mohan92.pdf (accessed 2026-10-12)
- [hesela-wal] WAL, checkpoints and torn pages: three different recovery guarantees. https://hesela.com/analyses/wal-checkpoints-torn-pages/ (accessed 2026-10-12)

### Host-side flash GC

URL: https://hesela.dev/terms/garbage-collection-host/
Status: shipping

Host filesystems or FTLs relocate valid pages before erasing flash blocks.

Related terms:
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [ftl](https://hesela.dev/terms/ftl/)
- [trim](https://hesela.dev/terms/trim/)

Citations:
- [c1] Host-side flash GC. https://en.wikipedia.org/wiki/Garbage_collection_(SSD) (accessed 2026-03-26)

### SMR garbage collection

URL: https://hesela.dev/terms/garbage-collection-smr/
Status: shipping

Record updated: 2026-10-15

SMR garbage collection relocates staged updates and rewrites affected shingled regions to reclaim reusable space.

Note: Internal cleaning can compete with foreground I/O; idle-only accounting can miss work already performed during writes [analysis]. Host-write volume alone is insufficient to predict its start because mapping entries and allocated media space can bind separately [skylight].

Related terms:
- [device-managed-smr](https://hesela.dev/terms/device-managed-smr/)
- [smr](https://hesela.dev/terms/smr/)
- [shingled-band](https://hesela.dev/terms/shingled-band/)
- [smr-persistent-cache](https://hesela.dev/terms/smr-persistent-cache/)

Citations:
- [c1] SMR garbage collection. https://en.wikipedia.org/wiki/Shingled_magnetic_recording (accessed 2026-03-26)
- [skylight] Aghayev and Desnoyers: Skylight, FAST 2015, sections 4.5-4.6. https://www.usenix.org/system/files/conference/fast15/fast15-paper-aghayev.pdf (accessed 2026-10-15)
- [zoned] Zoned Storage: Shingled Magnetic Recording Hard Disks. https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-15)
- [analysis] Hesela: SMR stalls, cache limits and the errors SMART can miss. https://hesela.com/analyses/smr-drive-failure-signatures/ (accessed 2026-10-15)

### Garbage collection (flash)

URL: https://hesela.dev/terms/garbage-collection/
Also known as: GC, SSD garbage collection
Status: shipping

Record updated: 2026-10-15

Flash garbage collection reclaims a victim erase block by first preserving its valid data elsewhere and then erasing the block for reuse.

Note: Relocation and erasure are different operations. The migration path can use controller-mediated copying or eligible NAND copyback; fewer channel transfers alone do not establish fewer physical writes.

Limitations:
- Reclaiming space can require relocating live pages, adding work beyond host writes. (sources: [hong2018])

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [trim](https://hesela.dev/terms/trim/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [ssd](https://hesela.dev/terms/ssd/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [nand-copyback](https://hesela.dev/terms/nand-copyback/)
- [nand-erase-block](https://hesela.dev/terms/nand-erase-block/)

Citations:
- [c1] Garbage collection (SSD). https://en.wikipedia.org/wiki/Garbage_collection_(SSD) (accessed 2026-03-26)
- [hong2018] Hong, Kim, Park, Jung and Kim. Revitalizing Copybacks in Modern SSDs: Why and How. Author manuscript arXiv:1810.04603v1, 2018, sections 3-5.. https://arxiv.org/abs/1810.04603v1 (accessed 2026-10-11)
- [hesela-copyback] Hesela: NAND copyback, faster relocation is not fewer writes. https://hesela.com/analyses/nand-copyback-ecc-boundary/ (accessed 2026-10-11)

### Ghost cache entry

URL: https://hesela.dev/terms/ghost-cache-entry/
Also known as: cache history entry
Status: research

Record updated: 2026-10-15

A ghost cache entry records the identity or history of an evicted item without retaining its cached payload.

Note: An ARC history hit is still a cache miss requiring a fetch. [arc]

Related terms:
- [adaptive-replacement-cache](https://hesela.dev/terms/adaptive-replacement-cache/)
- [cache-pollution](https://hesela.dev/terms/cache-pollution/)
- [mapping-cache](https://hesela.dev/terms/mapping-cache/)

Citations:
- [arc] Nimrod Megiddo and Dharmendra S. Modha. ARC: A Self-Tuning, Low Overhead Replacement Cache. FAST 2003, pp. 115-130; sections I, IV-V.. https://www.usenix.org/event/fast03/tech/full_papers/megiddo/megiddo.pdf (accessed 2026-10-15)
- [hesela] Hesela: mapping caches, scan phases and cache-history semantics (constructed examples). https://hesela.com/analyses/ssd-mapping-cache-hmb/#scan-pollution (accessed 2026-10-15)

### GMR read head

URL: https://hesela.dev/terms/giant-magnetoresistive-head/
Status: eol

Giant magnetoresistive heads enabled areal density gains in the late 1990s HDD era.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [longitudinal-recording](https://hesela.dev/terms/longitudinal-recording/)

Citations:
- [c1] GMR read head. https://en.wikipedia.org/wiki/Giant_magnetoresistive_effect (accessed 2026-03-26)

### Glass storage

URL: https://hesela.dev/terms/glass-storage/
Also known as: Project Silica, volumetric glass archive
Status: research

Experimental archival storage that encodes data as structural changes inside glass for very long-duration, read-mostly retention.

Note: Glass archival research (Microsoft Project Silica is the best-known public program) encodes data inside durable quartz/fused silica using ultrafast femtosecond lasers that write volumetric voxels, then reads with polarization-sensitive microscopy. The media is write-once (WORM) by design: read optics lack the energy to rewrite the glass, and library mechanics can keep plates out of writers for an air-gap archive. Public materials describe research prototypes and demonstrators (including cloud-library concepts), not a general retail glass-drive SKU line. Scope is long-horizon archival media exploration alongside tape and optical disc—capacity, write rate, and lifetime figures must be taken from the cited research papers, not secondary marketing summaries.

Advantages:
- Demonstrated multi-layer writes in silica with no moving media during read. (sources: [c1])

Limitations:
- Not a shipping general-purpose replacement for tape or HDD at datacenter scale. (sources: [c1])

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)

Citations:
- [c1] Project Silica. https://www.microsoft.com/en-us/research/project/project-silica/ (accessed 2026-03-26)
- [n2] Microsoft Research — Project Silica: Towards Sustainable Cloud Archival Storage in Glass (SOSP 2023 PDF). https://www.microsoft.com/en-us/research/wp-content/uploads/2023/09/ProjectSilica-SOSP23.pdf (accessed 2026-10-07)
- [n3] Microsoft Research — Project Silica’s advances in glass storage technology (blog). https://www.microsoft.com/en-us/research/blog/project-silicas-advances-in-glass-storage-technology/ (accessed 2026-10-07)

### Glass platter substrate

URL: https://hesela.dev/terms/glass-substrate/
Status: shipping

Glass disks replace aluminum on high-capacity platters for better flatness and thermal stability.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)

Citations:
- [c1] Glass platter substrate. https://en.wikipedia.org/wiki/Hard_disk_drive (accessed 2026-03-26)

### Gray failure

URL: https://hesela.dev/terms/gray-failure/
Also known as: grey failure
Status: unknown

Record updated: 2026-10-13

A gray failure occurs when an application observes a system as unhealthy while that system's failure observer regards it as healthy.

Note: This observer-relative definition is broader than slow hardware: it can include intermittent errors and capacity problems. A slowdown detected by both observers need not be gray in this sense. [huang-hotos17]

Related terms:
- [fail-slow](https://hesela.dev/terms/fail-slow/)
- [differential-observability](https://hesela.dev/terms/differential-observability/)

Citations:
- [huang-hotos17] Huang et al., Gray Failure: The Achilles' Heel of Cloud-Scale Systems, HotOS 2017, section 3; DOI 10.1145/3102980.3103005.. https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/paper-1.pdf (accessed 2026-10-13)
- [hesela-observers] Hesela: Fail-slow NVMe SSDs: what SMART and heartbeats miss. https://hesela.com/analyses/nvme-fail-slow-unseen-by-smart/ (accessed 2026-10-13)

### Greedy garbage collection

URL: https://hesela.dev/terms/greedy-garbage-collection/
Also known as: greedy block cleaning
Status: shipping

Record updated: 2026-10-12

A flash block-cleaning policy that selects a candidate erase block with the fewest valid pages, minimizing the valid data copied for that selection.

Note: The candidate set matters: a global greedy policy and a policy restricted to an age window are not the same algorithm. Immediate copying cost does not by itself determine long-run behavior under skewed update frequencies.

Limitations:
- Uniform-write formulas are conditional models, not universal drive predictions. (sources: [desnoyers], [xiang])

Related terms:
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [over-provisioning](https://hesela.dev/terms/over-provisioning/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [hot-cold-data-separation](https://hesela.dev/terms/hot-cold-data-separation/)

Citations:
- [xiang] Luojie Xiang and Brian M. Kurkoski. An Improved Analytic Expression for Write Amplification in NAND Flash. arXiv:1110.4245v1 (19 October 2011), sections II-IV, equation 12 and Table I.. https://arxiv.org/abs/1110.4245v1 (accessed 2026-10-11)
- [desnoyers] Peter Desnoyers. Analytic Modeling of SSD Write Performance. SYSTOR 2012, sections 2-6, Tables 1-2. DOI: 10.1145/2367589.2367603.. https://www.ccs.neu.edu/home/pjd/papers/pjd-systor12.pdf (accessed 2026-10-11)
- [hesela-op] Hesela: SSD over-provisioning, capacity denominators and analytical-model limits. https://hesela.com/analyses/ssd-overprovisioning-denominators/ (accessed 2026-10-11)

### Group commit

URL: https://hesela.dev/terms/group-commit/
Status: shipping

Record updated: 2026-10-15

Group commit is a logging optimization that shares a durable log synchronization across multiple concurrent transaction or write requests.

Note: PostgreSQL can persist several commit records in one WAL synchronization without flushing all changed data pages. [pg-intro] Group commit can occur with commit_delay=0; an added delay is a batching opportunity, not a durability exemption. [pg-configuration] RocksDB also groups compatible concurrent writes; different write options can prevent grouping. [rocksdb-wal] Hesela's distinction: sharing persistence work does not turn separate transactions into one application-level atomic operation. [pg-transactions] The 1984 DeWitt et al. report distinguishes early lock release from client acknowledgment and requires dependency-aware log persistence; it does not establish invention priority. [dewitt-1984]

Advantages:
- Amortizes log synchronization overhead across concurrent commits. (sources: [pg-intro])

Limitations:
- Waiting to collect more commits can increase latency and can reduce throughput. (sources: [pg-configuration])
- The mechanism does not itself specify replica acknowledgments or the storage stack's persistence guarantees. (sources: [pg-settings], [pg-reliability])

Related terms:
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [asynchronous-commit](https://hesela.dev/terms/asynchronous-commit/)

Citations:
- [pg-intro] PostgreSQL 18: Write-Ahead Logging. https://www.postgresql.org/docs/18/wal-intro.html (accessed 2026-10-15)
- [pg-configuration] PostgreSQL 18: WAL Configuration, group commit. https://www.postgresql.org/docs/18/wal-configuration.html (accessed 2026-10-15)
- [pg-settings] PostgreSQL 18: WAL settings, commit_delay and synchronous_commit. https://www.postgresql.org/docs/18/runtime-config-wal.html (accessed 2026-10-15)
- [pg-reliability] PostgreSQL 18: Reliability. https://www.postgresql.org/docs/18/wal-reliability.html (accessed 2026-10-15)
- [rocksdb-wal] RocksDB: WAL Performance, Group Commit (unversioned wiki). https://github.com/facebook/rocksdb/wiki/WAL-Performance (accessed 2026-10-15)
- [pg-transactions] PostgreSQL 18: Transactions. https://www.postgresql.org/docs/18/tutorial-transactions.html (accessed 2026-10-15)
- [dewitt-1984] DeWitt et al. Implementation Techniques for Main Memory Database Systems. UCB/ERL M84/5 (1984), section 5.2.. https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/Archive/ERL-m-84-5.pdf (accessed 2026-10-15)
- [hesela-wal] Hesela: Group commit shares persistence work, not transaction identity. https://hesela.com/analyses/wal-checkpoints-torn-pages/#group-commit (accessed 2026-10-15)

### Grouped cross-validation

URL: https://hesela.dev/terms/grouped-cross-validation/
Also known as: group-wise cross-validation, group-aware cross-validation
Status: shipping

Record updated: 2026-10-14

Grouped cross-validation evaluates a predictor using splits that keep all observations from each specified group together in either training or testing within a split.

Note: GroupKFold holds each group out once across its test folds. [sklearn-groupkfold] In storage evaluation, group by physical drive to test unseen drives or by site to test unseen sites; these are different generalization questions. Group separation alone does not impose chronological order. [sklearn-validation]

Limitations:
- Choose groups for the deployment question; grouping does not prevent future information or globally fitted preprocessing from entering training. (sources: [sklearn-validation])

Related terms:
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)
- [prediction-horizon](https://hesela.dev/terms/prediction-horizon/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [smart](https://hesela.dev/terms/smart/)

Citations:
- [sklearn-groupkfold] scikit-learn: GroupKFold, non-overlapping groups and per-fold behavior.. https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.GroupKFold.html (accessed 2026-10-14)
- [sklearn-validation] scikit-learn: cross-validation for grouped data, time series and training-only transformations.. https://scikit-learn.org/stable/modules/cross_validation.html (accessed 2026-10-14)

### Heat-assisted magnetic recording (HAMR)

URL: https://hesela.dev/terms/hamr/
Also known as: energy-assisted recording
Status: shipping

Recorded firstSeen: 2024 (sources: [c2])

An HDD technology that briefly heats the media with a laser so bits can be written on high-coercivity material at higher density.

Note: HAMR addresses the writeability/thermal-stability trade-off at high areal density: media grains are made highly coercive so tiny bits stay stable at room temperature, then a laser diode on the write head briefly heats a nanoscale spot so the magnetic writer can flip polarity; the spot cools in about a nanosecond. Seagate’s shipping Mozaic platform pairs superlattice high-anisotropy media with a plasmonic (near-field) writer. HAMR changes how small bits are written, not whether tracks are shingled—Mozaic SKUs appear in vendor CMR/SMR matrices as CMR or SMR variants. It targets mass-capacity nearline density; seek and rotational latency remain mechanical. Public production emphasis has been Seagate; other vendors discuss HAMR on their own qualification timelines.

Advantages:
- Extends areal density beyond PMR alone by using thermally assisted writes. (sources: [c1], [c2])

Related terms:
- [mamr](https://hesela.dev/terms/mamr/)
- [pmr](https://hesela.dev/terms/pmr/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [helium-hdd](https://hesela.dev/terms/helium-hdd/)
- [areal-density](https://hesela.dev/terms/areal-density/)

Citations:
- [c1] Heat-assisted magnetic recording. https://en.wikipedia.org/wiki/Heat-assisted_magnetic_recording (accessed 2026-03-26)
- [c2] Seagate begins shipping HAMR drives. https://www.seagate.com/news/news-archive/seagate-begins-shipping-hamr-drives/ (accessed 2026-03-26)
- [n3] Seagate — Heat-Assisted Magnetic Recording (HAMR). https://www.seagate.com/innovation/hamr/ (accessed 2026-10-07)
- [n4] Seagate — What is Mozaic 3+ (plasmonic write path). https://www.seagate.com/resources/what-is-mozaic-3plus-how-does-it-work-and-what-can-it-do-for-my-data-center/ (accessed 2026-10-07)
- [n5] Seagate — Gen 2 plasmonic writer. https://www.seagate.com/innovation/mozaic/gen-2-plasmonic-writer/ (accessed 2026-10-07)

### Hard link

URL: https://hesela.dev/terms/hard-link/
Also known as: hardlink
Status: shipping

Record updated: 2026-10-15

A hard link is a directory entry naming an existing file's inode, so multiple hard links refer to the same file rather than to separate copies.

Note: On Linux, link() creates another name without overwriting an existing destination and cannot cross mounted-filesystem boundaries. In-place writes through either name modify the shared file; replacing one name with rename() instead rebinds that name and leaves the other hard links attached to their original inode. Removing one link does not remove the other names. Separate open() calls through these names still create separate open file descriptions.

Advantages:
- Provides another name for the same file without copying its contents.

Limitations:
- Shared file contents mean a hard link is not an independent backup.
- Linux link() rejects directories and links across mounted filesystems.

Related terms:
- [inode](https://hesela.dev/terms/inode/)
- [atomic-rename](https://hesela.dev/terms/atomic-rename/)
- [unlink](https://hesela.dev/terms/unlink/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)

Citations:
- [linux-link-2] Linux man-pages 6.19: link(2). https://man7.org/linux/man-pages/man2/link.2.html (accessed 2026-10-15)
- [linux-rename-2] Linux man-pages 6.19: rename(2). https://man7.org/linux/man-pages/man2/rename.2.html (accessed 2026-10-15)
- [linux-open-2] Linux man-pages 6.19: open(2). https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-15)
- [hesela-namespace] Hesela: The name changes; existing readers do not. https://hesela.com/analyses/atomic-rename-directory-durability/#namespace-identity (accessed 2026-10-15)

### Hash collision

URL: https://hesela.dev/terms/hash-collision/
Also known as: Digest collision
Status: shipping

Record updated: 2026-10-12

A hash collision occurs when two distinct inputs produce the same digest under the same hash function and parameters.

Note: Hashing identical bytes twice is not a collision. Finding any colliding pair differs from finding a replacement for an already specified original, which is a second-preimage problem. [nist-collision] [nist-second-preimage] A stale or misplaced record with its own valid digest can pass a check without any collision. [hesela-integrity]

Limitations:
- Collision resistance concerns the difficulty of finding colliding inputs, not an assertion that every input has a unique digest. (sources: [nist-hash])
- CRC undetected-error probabilities require a stated error model and cannot be treated as universal device failure rates. (sources: [rfc3385])

Related terms:
- [checksum](https://hesela.dev/terms/checksum/)
- [cryptographic-hash](https://hesela.dev/terms/cryptographic-hash/)
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)
- [deduplication](https://hesela.dev/terms/deduplication/)

Citations:
- [nist-collision] NIST CSRC glossary: collision. https://csrc.nist.gov/glossary/term/collision (accessed 2026-10-12)
- [nist-second-preimage] NIST CSRC glossary: second preimage resistance. https://csrc.nist.gov/glossary/term/second_preimage_resistance (accessed 2026-10-12)
- [nist-hash] NIST CSRC glossary: cryptographic hash function and security properties. https://csrc.nist.gov/glossary/term/cryptographic_hash_function (accessed 2026-10-12)
- [rfc3385] RFC 3385: iSCSI CRC/Checksum Considerations, sections 1-2 and 10 (historical error-model analysis). https://www.rfc-editor.org/rfc/rfc3385.html (accessed 2026-10-12)
- [hesela-integrity] Hesela: Why a valid checksum can still return the wrong data. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-12)

### Hazard rate

URL: https://hesela.dev/terms/hazard-rate/
Status: shipping

Record updated: 2026-10-13

The hazard rate is the instantaneous event rate at a given time conditional on the event not having occurred before that time.

Note: For a continuous lifetime T, h(t) = f(t) / S(t), with units of inverse time, not percent probability. Specify the clock and event: device age until first failure and time since the last replacement anywhere in a cluster are different random variables. A constant hazard gives exponential survival; neither constant hazard nor independence is established by a pooled AFR.

Related terms:
- [afr](https://hesela.dev/terms/afr/)
- [mtbf](https://hesela.dev/terms/mtbf/)
- [drive-day](https://hesela.dev/terms/drive-day/)
- [right-censoring](https://hesela.dev/terms/right-censoring/)
- [left-truncation](https://hesela.dev/terms/left-truncation/)
- [interarrival-time](https://hesela.dev/terms/interarrival-time/)
- [rate-of-occurrence-of-failures](https://hesela.dev/terms/rate-of-occurrence-of-failures/)
- [survival-function](https://hesela.dev/terms/survival-function/)
- [kaplan-meier-estimator](https://hesela.dev/terms/kaplan-meier-estimator/)

Citations:
- [nist-hazard] NIST e-Handbook: Failure (or hazard) rate (8.1.2.3). https://www.itl.nist.gov/div898/handbook/apr/section1/apr123.htm (accessed 2026-10-10)
- [nist-exponential] NIST e-Handbook: Exponential distribution (8.1.6.1). https://www.itl.nist.gov/div898/handbook/apr/section1/apr161.htm (accessed 2026-10-10)
- [schroeder-2007] Schroeder and Gibson: Disk failures in the real world, FAST 2007, sections 2.4 and 5.3. https://static.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html (accessed 2026-10-10)
- [hesela-methods] Hesela: AFR is a rate, not a one-year failure probability. https://hesela.com/analyses/afr-rate-not-probability/ (accessed 2026-10-10)
- [hesela-age-audit] Hesela: Missing SMART ages and the limits of drive-age comparisons. https://hesela.com/analyses/backblaze-age-missing-data-audit/ (accessed 2026-10-11)

### Host bus adapter (HBA)

URL: https://hesela.dev/terms/hba/
Status: shipping

A card or SoC port that connects servers to SCSI, SAS, Fibre Channel, or NVMe fabrics.

Related terms:
- [sas](https://hesela.dev/terms/sas/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [nvme](https://hesela.dev/terms/nvme/)
- [ahci](https://hesela.dev/terms/ahci/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] Host bus adapter (HBA). https://en.wikipedia.org/wiki/Host_bus_adapter (accessed 2026-03-26)

### Hard disk drive (HDD)

URL: https://hesela.dev/terms/hdd/
Also known as: hard drive, magnetic disk
Status: shipping

Record updated: 2026-10-15

Recorded firstSeen: 1956 (sources: [c1])

A non-volatile storage device that records data on spinning platters with a moving read/write head.

Note: An HDD stores bits as magnetic orientations on spinning platters; one or more heads on an actuator arm seek radially while rotational latency waits for the sector to pass under the head. Capacity scales with platter count, areal density (PMR/CMR/SMR plus assisted recording such as HAMR/MAMR), and packaging (air vs helium). Interfaces today are predominantly SATA or SAS for block access; performance is bounded by mechanics (IOPS and latency) rather than flash controller parallelism. HDDs remain the common economics choice for warm/cold bulk and nearline tiers where dollars-per-TB and watts-per-TB matter more than microsecond latency. Form factors in volume are mainly 3.5-inch enterprise/nearline and 2.5-inch mobile/legacy.

Related terms:
- [cmr](https://hesela.dev/terms/cmr/)
- [smr](https://hesela.dev/terms/smr/)
- [pmr](https://hesela.dev/terms/pmr/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [sata](https://hesela.dev/terms/sata/)
- [sas](https://hesela.dev/terms/sas/)
- [areal-density](https://hesela.dev/terms/areal-density/)
- [st-412](https://hesela.dev/terms/st-412/)
- [head-disk-interface](https://hesela.dev/terms/head-disk-interface/)
- [flying-height](https://hesela.dev/terms/flying-height/)
- [thermal-flying-height-control](https://hesela.dev/terms/thermal-flying-height-control/)

Citations:
- [c1] Computer History Museum — 1956: First commercial hard disk drive shipped (The Storage Engine, IBM Model 350 RAMAC). https://www.computerhistory.org/storageengine/first-commercial-hard-disk-drive-shipped/ (accessed 2026-10-16)
- [n2] Seagate — CMR and SMR hard drive list (mass-capacity context). https://www.seagate.com/products/cmr-smr-list/ (accessed 2026-10-07)
- [n3] Western Digital — Helium hard drives explained (mechanics packaging). https://blog.westerndigital.com/helium-hard-drives-explained/ (accessed 2026-10-07)
- [n4] IDEMA — HDD technology resources (industry association). https://idema.org/ (accessed 2026-10-07)

### Head-disk interface (HDI)

URL: https://hesela.dev/terms/head-disk-interface/
Also known as: HDI, head disk interface
Status: shipping

Record updated: 2026-10-16

The head-disk interface is the interacting region between an HDD's head-carrying slider and rotating disk surface.

Note: The interface involves gas-film support, local clearance and surface interactions, not the SATA or SAS host connection. Ma et al. distinguish passive flight, touchdown transition and stronger modulation using specialized head-media spacing and touchdown-sensor signals [touchdown]. A controlled contact experiment is not a count of catastrophic failures in an operating fleet [analysis].

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [flying-height](https://hesela.dev/terms/flying-height/)
- [thermal-flying-height-control](https://hesela.dev/terms/thermal-flying-height-control/)
- [rotational-vibration](https://hesela.dev/terms/rotational-vibration/)
- [head-slap](https://hesela.dev/terms/head-slap/)
- [touchdown-sensor](https://hesela.dev/terms/touchdown-sensor/)
- [head-gas-bearing](https://hesela.dev/terms/head-gas-bearing/)

Citations:
- [touchdown] Ma et al.: Head disk interface characterization, CML report 15013, introduction and experiment. https://cml.berkeley.edu/wp-content/uploads/blue-reports/15013.pdf (accessed 2026-10-15)
- [analysis] Hesela: HDD mechanical faults, evidence and diagnostic limits. https://hesela.com/analyses/hdd-mechanical-failure-points/ (accessed 2026-10-15)

### HDD head gas bearing

URL: https://hesela.dev/terms/head-gas-bearing/
Also known as: head air bearing, slider gas bearing
Status: shipping

Record updated: 2026-10-16

An HDD head gas bearing is the thin moving gas film whose pressure supports the head-carrying slider against its suspension load.

Note: The established name air-bearing surface (ABS) also appears in helium research. Liu's chapter 8 numerically couples gas flow and thermal deformation for one slider: unheated and heated clearance respond differently to helium fraction [gas-model]. This is not the spindle bearing, and its behavior cannot be inferred from bulk gas density alone [card].

Related terms:
- [head-disk-interface](https://hesela.dev/terms/head-disk-interface/)
- [flying-height](https://hesela.dev/terms/flying-height/)
- [thermal-flying-height-control](https://hesela.dev/terms/thermal-flying-height-control/)
- [helium-hdd](https://hesela.dev/terms/helium-hdd/)

Citations:
- [gas-model] Nan Liu (2010), UC Berkeley dissertation, chapter 8: TFC sliders in air-helium mixtures. https://cml.berkeley.edu/wp-content/uploads/gold-reports/G10002.pdf (accessed 2026-10-16)
- [card] Hesela: helium HDD construction and evidence boundaries. https://hesela.com/tech/helium-hdd/ (accessed 2026-10-16)

### Head slap

URL: https://hesela.dev/terms/head-slap/
Also known as: head-slap
Status: unknown

Record updated: 2026-10-15

Head slap is a head-disk contact mechanism in which an HDD slider separates from the disk and then snaps back into it.

Note: Li and Bogy identify this mechanism in their coupled structural and air-bearing simulation, distinct from long-pulse loading that overcomes a still-positive bearing force [shock]. Residual vibration can cause contact after the pulse ends. It is a mechanism, not a synonym for every head crash, a SMART counter or a universal shock threshold.

Related terms:
- [head-disk-interface](https://hesela.dev/terms/head-disk-interface/)
- [flying-height](https://hesela.dev/terms/flying-height/)

Citations:
- [shock] Li and Bogy: Operational Shock Failure Mechanisms in Hard Disk Drives, CML report 13009, sections 4.1-4.2 and 5. https://cml.berkeley.edu/wp-content/uploads/blue-reports/13009.pdf (accessed 2026-10-15)
- [analysis] Hesela: HDD mechanical faults, evidence and diagnostic limits. https://hesela.com/analyses/hdd-mechanical-failure-points/ (accessed 2026-10-15)

### Helical scan recording

URL: https://hesela.dev/terms/helical-scan/
Status: limited

Tape heads scan at an angle across a slow-moving tape, used in DAT and some video formats.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [dat-cartridge](https://hesela.dev/terms/dat-cartridge/)

Citations:
- [c1] Helical scan recording. https://en.wikipedia.org/wiki/Helical_scan (accessed 2026-03-26)

### Helium-filled HDD

URL: https://hesela.dev/terms/helium-hdd/
Also known as: helium drive, He HDD
Status: shipping

Record updated: 2026-10-16

A helium-filled HDD is a hard disk drive whose head-disk assembly operates in a sealed helium atmosphere to reduce aerodynamic loading.

Note: Helium is an enclosure technology, independent of track layout and assisted recording. The 2013 He6 is a modern high-volume production milestone, not a universal invention date: earlier disk systems used an external helium supply [history]. Gas-bearing geometry and heat transfer still govern local head clearance [gas-model]. HelioSeal names Western Digital's platform, not every helium HDD [card].

Advantages:
- The HGST development report describes denser platter packaging after reducing flow-induced vibration. (sources: [c1])

Limitations:
- Construction evidence does not establish a fleet failure rate or a lifetime diagnostic-port standard. (sources: [card])

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [dual-actuator](https://hesela.dev/terms/dual-actuator/)
- [helium-leak-port](https://hesela.dev/terms/helium-leak-port/)
- [head-gas-bearing](https://hesela.dev/terms/head-gas-bearing/)
- [flying-height](https://hesela.dev/terms/flying-height/)

Citations:
- [c1] Aoyagi et al. (2017), JSME IIP2017 B-03, sections 2-4; DOI 10.1299/jsmeiip.2017.B-03. https://www.jstage.jst.go.jp/article/jsmeiip/2017/0/2017_B-03/_pdf/-char/en (accessed 2026-10-16)
- [history] Roger Wood, Computer History Museum, helium-drive history, pp. 4-6. https://d1yx3ys82bpsa0.cloudfront.net/groups/chm-helium-white-paper.pdf (accessed 2026-10-16)
- [gas-model] Nan Liu (2010), UC Berkeley dissertation, chapter 8: TFC sliders in air-helium mixtures. https://cml.berkeley.edu/wp-content/uploads/gold-reports/G10002.pdf (accessed 2026-10-16)
- [card] Hesela: helium HDD construction and evidence boundaries. https://hesela.com/tech/helium-hdd/ (accessed 2026-10-16)

### Helium leak port

URL: https://hesela.dev/terms/helium-leak-port/
Status: unknown

Record updated: 2026-10-16

Helium leak port is an unverified legacy corpus label, not an established name for a lifetime diagnostic interface on helium HDDs.

Note: Correction, 2026-10-16: the previous diagnostic-port definition is withdrawn. Seagate documents a manufacturing fill port with a final seal, separately from internal environmental sensors [sealing]. Neither establishes the claimed service interface. The existing slug and name remain for compatibility and to make the correction discoverable; they are not confirmation that this is standard terminology [card].

Limitations:
- Do not infer a user-accessible test or refill connection from this legacy label. (sources: [sealing])

Related terms:
- [helium-hdd](https://hesela.dev/terms/helium-hdd/)

Citations:
- [sealing] Seagate TP686.1-1602US (February 2016), pp. 3-4: fill-port seal and internal sensors. https://www.seagate.com/files/www-content/product-content/enterprise-hdd-fam/enterprise-capacity-3-5-hdd-10tb/_shared/docs/helium-drive-launch-tp686-1-1602us.pdf (accessed 2026-10-16)
- [card] Hesela: helium HDD construction and evidence boundaries. https://hesela.com/tech/helium-hdd/ (accessed 2026-10-16)

### Hinted handoff

URL: https://hesela.dev/terms/hinted-handoff/
Status: shipping

Record updated: 2026-10-13

Hinted handoff retains information about an update missed by an intended replica and attempts to deliver it later.

Note: Cassandra 5.0.0 coordinators store hints for unavailable or timed-out replicas; delivery is best effort. [hints] Its max_hint_window limits hint generation during unavailability, not a universal hint lifetime or replay deadline. [config]

Limitations:
- An empty hint queue does not prove that replicas have received every missed mutation. (sources: [hints], [config])

Related terms:
- [anti-entropy-repair](https://hesela.dev/terms/anti-entropy-repair/)
- [read-repair](https://hesela.dev/terms/read-repair/)
- [sloppy-quorum](https://hesela.dev/terms/sloppy-quorum/)

Citations:
- [hints] Apache Cassandra 5.0.0: Hints. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/managing/operating/hints.adoc (accessed 2026-10-13)
- [config] Apache Cassandra 5.0.0: max_hint_window configuration. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/conf/cassandra.yaml (accessed 2026-10-13)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### Host-managed SMR (HM-SMR)

URL: https://hesela.dev/terms/hm-smr/
Also known as: host-aware SMR, ZBC/ZAC host-managed
Status: limited

An SMR HDD whose shingled bands are exposed to the host, which must write sequentially within zones.

Note: Host-managed SMR exposes sequential-write-required zones: the host (or zoned filesystem) must write at the zone write pointer; out-of-order writes are rejected. Zone report/reset/finish commands come from SCSI ZBC or ATA ZAC with aligned semantics. Linux identifies host-managed disks as zoned block devices (`queue/zoned` = host-managed); SCSI type 0x14 or SATA signature 0xabcd distinguish them from ordinary disks. Unlike drive-managed SMR, there is no firmware mask for random block I/O—integration needs zone-aware software (e.g., zonefs, SMR-aware object layers). Vendors place top nearline capacities on HM-SMR because the host can keep writes sequential and performance predictable.

Advantages:
- Host software can optimize placement for append-heavy workloads. (sources: [c1])

Limitations:
- Requires OS or application support for zoned block or zoned ATA commands. (sources: [c1])

Related terms:
- [smr](https://hesela.dev/terms/smr/)
- [device-managed-smr](https://hesela.dev/terms/device-managed-smr/)
- [zns](https://hesela.dev/terms/zns/)

Citations:
- [c1] Zoned block device. https://en.wikipedia.org/wiki/Zoned_block_device (accessed 2026-03-26)
- [n2] Zoned Storage — Getting started with SMR hard disks. https://zonedstorage.io/docs/getting-started/smr-disk (accessed 2026-10-07)
- [n3] Zoned Storage — Zoned storage devices overview (host-managed model). https://zonedstorage.io/docs/introduction/zoned-storage (accessed 2026-10-07)
- [n4] Zoned Storage — SMR introduction (ZBC/ZAC). https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-07)

### Host memory buffer (HMB)

URL: https://hesela.dev/terms/hmb/
Also known as: HMB
Status: shipping

Record updated: 2026-10-12

Host Memory Buffer is an optional NVMe feature through which a controller uses assigned host-memory ranges.

Note: The allocation's use is vendor-specific. NVMe 1.4a requires correct operation without host memory and protection against data loss or corruption on surprise removal while HMB is used.

Advantages:
- KIOXIA documents HMB as a way to build its BG-series architecture without onboard DRAM. (sources: [kioxia])

Limitations:
- Actual allocation and performance depend on host support and device implementation. (sources: [nvme], [kioxia])

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [ftl](https://hesela.dev/terms/ftl/)
- [dram-cache-ssd](https://hesela.dev/terms/dram-cache-ssd/)
- [mapping-cache](https://hesela.dev/terms/mapping-cache/)
- [translation-page](https://hesela.dev/terms/translation-page/)

Citations:
- [nvme] NVM Express Base Specification, revision 1.4a (9 March 2020), sections 5.21.1.13 and 8.9. Copyright 2007-2020 NVM Express, Inc.. https://www.nvmexpress.org/wp-content/uploads/NVM-Express-1_4a-2020.03.09-Ratified.pdf (accessed 2026-10-12)
- [kioxia] KIOXIA. HMB (Host Memory Buffer) technology for DRAM-less SSDs. 28 August 2018. Vendor description, not an independent benchmark.. https://www.kioxia.com/en-jp/rd/technology/topics/topics-14.html (accessed 2026-10-12)
- [hesela] SSD mapping caches: why DRAM size is not a speed rating. https://hesela.com/analyses/ssd-mapping-cache-hmb/ (accessed 2026-10-12)

### Hole punching

URL: https://hesela.dev/terms/hole-punching/
Also known as: file hole punching
Status: shipping

Record updated: 2026-10-13

Deallocating whole filesystem blocks within a file range while preserving the file's logical length and making the affected range read as zeros.

Note: On Linux, FALLOC_FL_PUNCH_HOLE must be combined with FALLOC_FL_KEEP_SIZE; partial boundary blocks are zeroed rather than removed. The operation changes file content and requires filesystem support. It is not the same as collapsing a range, which shifts later data, or as a sanitization procedure.

Advantages:
- Can release whole blocks in a selected range without shortening the file. (sources: [fallocate])

Limitations:
- A partial-block range need not release any whole filesystem block. (sources: [fallocate])
- File-level deallocation does not prove immediate physical reclamation below a thin pool. (sources: [lvmthin], [dm-thin])

Related terms:
- [sparse-file](https://hesela.dev/terms/sparse-file/)
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [discard](https://hesela.dev/terms/discard/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [unwritten-extent](https://hesela.dev/terms/unwritten-extent/)

Citations:
- [fallocate] Linux man-pages: fallocate(2), allocation and mode contracts. https://www.man7.org/linux/man-pages/man2/fallocate.2.html (accessed 2026-10-12)
- [lvmthin] LVM2: lvmthin(7), physical allocation, discards and pool exhaustion. https://man7.org/linux/man-pages/man7/lvmthin.7.html (accessed 2026-10-12)
- [dm-thin] Linux 6.12: device-mapper thin provisioning, metadata and exhaustion. https://raw.githubusercontent.com/torvalds/linux/v6.12/Documentation/admin-guide/device-mapper/thin-provisioning.rst (accessed 2026-10-12)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)

### Holographic data storage

URL: https://hesela.dev/terms/holographic-storage/
Status: research

Stores pages of data as interference patterns in a photosensitive volume, mostly experimental commercially.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)

Citations:
- [c1] Holographic data storage. https://en.wikipedia.org/wiki/Holographic_data_storage (accessed 2026-03-26)

### NVMe Host Controlled Thermal Management

URL: https://hesela.dev/terms/host-controlled-thermal-management/
Also known as: HCTM, NVMe HCTM
Status: shipping

Record updated: 2026-10-16

NVMe Host Controlled Thermal Management is a controller feature through which a host configures temperature targets for automatic transitions to lower-power active power states or vendor-specific thermal actions.

Note: Feature Identifier 10h sets TMT1 and TMT2 in kelvins; they are distinct from warning and critical composite thresholds. A zero disables the respective HCTM setting. [base23] SMART transition counts and action timers describe HCTM activity, with times in seconds and saturation at 0xFFFFFFFF; zero can mean no recorded activity or an unimplemented field. [base23] [nvmelog]

Limitations:
- Light and heavy throttling are examples, not fixed performance-loss percentages; these counters do not enumerate every vendor thermal action. (sources: [base23], [nvmelog])

Related terms:
- [thermal-throttling-ssd](https://hesela.dev/terms/thermal-throttling-ssd/)
- [nvme-composite-temperature](https://hesela.dev/terms/nvme-composite-temperature/)
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-warning-composite-temperature-time](https://hesela.dev/terms/nvme-warning-composite-temperature-time/)
- [nvme-critical-composite-temperature-time](https://hesela.dev/terms/nvme-critical-composite-temperature-time/)

Citations:
- [base23] NVM Express Base Specification 2.3: Figure 210 (pp. 214-217), temperature hysteresis section 5.2.26.1.3.1, HCTM Figure 417 (p. 410). https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [nvmelog] libnvme v1.15: nvme_smart_log field definitions (July 2025). https://github.com/linux-nvme/libnvme/blob/v1.15/doc/man/nvme_smart_log.2 (accessed 2026-10-15)

### Host-managed band (SMR)

URL: https://hesela.dev/terms/host-managed-band/
Status: shipping

The host tracks which SMR bands are full and schedules sequential writes into empty zones.

Related terms:
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [zbc](https://hesela.dev/terms/zbc/)
- [zac](https://hesela.dev/terms/zac/)

Citations:
- [c1] Host-managed band (SMR). https://en.wikipedia.org/wiki/Zoned_block_device (accessed 2026-03-26)

### Hot/cold data separation

URL: https://hesela.dev/terms/hot-cold-data-separation/
Also known as: update-frequency data separation
Status: shipping

Record updated: 2026-10-12

A flash-placement strategy that groups data by update frequency so frequently overwritten pages and long-lived pages need not share the same cleaning pool.

Note: Hot and cold refer to update frequency, not physical temperature or hot/cold storage tiers. Spare-space allocation between pools matters alongside classification and block selection.

Limitations:
- Data classification can change with workload; a placement model is not evidence that every controller implements it. (sources: [desnoyers])

Related terms:
- [greedy-garbage-collection](https://hesela.dev/terms/greedy-garbage-collection/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [over-provisioning](https://hesela.dev/terms/over-provisioning/)
- [ftl](https://hesela.dev/terms/ftl/)
- [nvme-fdp](https://hesela.dev/terms/nvme-fdp/)

Citations:
- [desnoyers] Peter Desnoyers. Analytic Modeling of SSD Write Performance. SYSTOR 2012, sections 2-6, Tables 1-2. DOI: 10.1145/2367589.2367603.. https://www.ccs.neu.edu/home/pjd/papers/pjd-systor12.pdf (accessed 2026-10-11)
- [hesela-op] Hesela: SSD over-provisioning, capacity denominators and analytical-model limits. https://hesela.com/analyses/ssd-overprovisioning-denominators/ (accessed 2026-10-11)

### Hot journal

URL: https://hesela.dev/terms/hot-journal/
Also known as: Hot rollback journal, SQLite hot journal
Status: shipping

Record updated: 2026-10-14

A hot journal is a SQLite rollback journal that requires replay to recover an interrupted database transaction.

Note: SQLite's rollback-mode checks require an existing journal larger than 512 bytes, a valid nonzero header, no RESERVED lock on the database, and either an existing named super-journal or no super-journal name. The lock check distinguishes recovery work from a current writer's journal. SQLite obtains recovery locks and replays a hot journal before reading the database. [sqlite-locking] A leftover journal whose named super-journal was deleted at group commit is not hot. [sqlite-atomiccommit] See the distinction between journal files and recovery decisions. [hesela-wal] A disposable process-exit observation demonstrates journal retention after commit and rollback of unfinished writes; it is not a power-loss test. [hesela-journal-observation]

Advantages:
- Lets SQLite identify unfinished rollback-mode work and recover before serving database reads. (sources: [sqlite-locking])

Limitations:
- A journal filename alone does not establish hotness; its header, lock state and super-journal relationship matter. (sources: [sqlite-locking])
- Deleting or separating a hot journal from its database can remove information needed for recovery. (sources: [sqlite-locking])

Related terms:
- [rollback-journal](https://hesela.dev/terms/rollback-journal/)
- [sqlite-super-journal](https://hesela.dev/terms/sqlite-super-journal/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [sqlite-locking] SQLite: File Locking And Concurrency In SQLite Version 3. https://sqlite.org/lockingv3.html (accessed 2026-10-14)
- [sqlite-atomiccommit] SQLite: Atomic Commit In SQLite. https://sqlite.org/atomiccommit.html (accessed 2026-10-14)
- [hesela-wal] Hesela: WAL, checkpoints and torn pages, SQLite commit scope. https://hesela.com/analyses/wal-checkpoints-torn-pages/#sqlite-commit-scope (accessed 2026-10-14)
- [hesela-journal-observation] Hesela: SQLite journal-lifecycle observations, measured synthetic workload and explicit limits. https://hesela.dev/research/sqlite-journal-observation.json (accessed 2026-10-14)

### Hot spare

URL: https://hesela.dev/terms/hot-spare/
Also known as: Standby spare
Status: shipping

Record updated: 2026-10-15

A hot spare is a standby device or reserved distributed spare capacity available to take over a failed member's role in a redundant array or pool.

Note: An unused spare is not an already synchronized extra member or an independent backup: replacement still requires reconstruction [zreplace]. In ZFS, spare activation and replacement state are distinct from completed resilvering [zconcepts]. A spare shortens the wait for replacement capacity; it does not add a parity level. OpenZFS documents ZED consuming pool events to automate replacement; monitoring and reconstruction completion still need separate checks [zpoolmonitor]. Linux MD's spare state also covers a device being recovered, not only an idle reserve [md-state].

Limitations:
- Automatic activation depends on the platform's fault-management services and configuration; merely listing a spare does not prove replacement has started. (sources: [zpoolmonitor])
- OpenZFS 2.3 warns of corruption if pools on different hosts concurrently claim a shared spare; its spares do not replace separate log devices, and a distributed dRAID spare serves only its own vdev. (sources: [zconcepts])

Related terms:
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)
- [resilver](https://hesela.dev/terms/resilver/)
- [raid](https://hesela.dev/terms/raid/)
- [mirroring](https://hesela.dev/terms/mirroring/)
- [distributed-spare](https://hesela.dev/terms/distributed-spare/)

Citations:
- [zconcepts] OpenZFS 2.3: zpoolconcepts(7), device failure and hot spares. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpoolconcepts.7.html (accessed 2026-10-15)
- [zreplace] OpenZFS 2.3: zpool-replace(8), replacement and sequential reconstruction. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-replace.8.html (accessed 2026-10-13)
- [hesela-rebuild] Hesela: RAID rebuild read-error models and resilver boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#spare-policy-heading (accessed 2026-10-15)
- [zpoolmonitor] OpenZFS 2.3: zpool(8), monitoring and event-driven spare replacement. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool.8.html (accessed 2026-10-13)
- [md-state] Linux 6.12: RAID arrays, per-device spare and in_sync states. https://docs.kernel.org/6.12/admin-guide/md.html (accessed 2026-10-15)

### Hot standby feedback

URL: https://hesela.dev/terms/hot-standby-feedback/
Also known as: PostgreSQL hot_standby_feedback
Status: shipping

Record updated: 2026-10-16

Hot standby feedback is PostgreSQL's mechanism for reporting standby query retention needs upstream to defer conflicting row cleanup.

Note: It can prevent cleanup-related query cancellations but retain dead rows and cause primary-side bloat; the default is off. [pg-feedback] It does not configure commit acknowledgements. [hesela-replication]

Limitations:
- Feedback does not eliminate every recovery conflict, including Access Exclusive locks and drops of tables, databases or tablespaces. (sources: [pg-conflicts])
- Slot synchronization needs a persistent physical upstream slot, which can be the existing streaming slot; feedback alone does not protect needed catalog history during a disconnection. (sources: [pg-decoding])

Related terms:
- [replication-slot](https://hesela.dev/terms/replication-slot/)
- [failover-slot](https://hesela.dev/terms/failover-slot/)
- [logical-decoding](https://hesela.dev/terms/logical-decoding/)
- [snapshot-isolation](https://hesela.dev/terms/snapshot-isolation/)

Citations:
- [pg-feedback] PostgreSQL 18: hot_standby_feedback. https://www.postgresql.org/docs/18/runtime-config-replication.html#GUC-HOT-STANDBY-FEEDBACK (accessed 2026-10-16)
- [pg-conflicts] PostgreSQL 18: handling query conflicts on hot standby. https://www.postgresql.org/docs/18/hot-standby.html#HOT-STANDBY-CONFLICT (accessed 2026-10-16)
- [pg-decoding] PostgreSQL 18: replication slot synchronization. https://www.postgresql.org/docs/18/logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS-SYNCHRONIZATION (accessed 2026-10-16)
- [hesela-replication] Hesela: Replication acknowledgements and logical failover readiness. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-16)

### Hot storage tier

URL: https://hesela.dev/terms/hot-storage/
Status: shipping

Low-latency media and tiers serving active workloads with frequent reads and writes.

Related terms:
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] Hot storage tier. https://en.wikipedia.org/wiki/Information_lifecycle_management (accessed 2026-03-26)

### Hot, warm, and cold storage tiers

URL: https://hesela.dev/terms/hot-warm-cold/
Also known as: storage tiering, temperature tiers
Status: shipping

A data-placement model where hot tiers favor latency, warm tiers favor cost per TB on disk, and cold tiers favor tape or archive media.

Related terms:
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)
- [glass-storage](https://hesela.dev/terms/glass-storage/)

Citations:
- [c1] Information lifecycle management. https://en.wikipedia.org/wiki/Information_lifecycle_management (accessed 2026-03-26)

### Hybrid flash array

URL: https://hesela.dev/terms/hybrid-flash-array/
Status: shipping

A storage system mixing flash caches or tiers with HDD capacity pools.

Related terms:
- [ssd](https://hesela.dev/terms/ssd/)
- [hdd](https://hesela.dev/terms/hdd/)
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)

Citations:
- [c1] Hybrid flash array. https://en.wikipedia.org/wiki/Hybrid_array (accessed 2026-03-26)

### IDE / ATA

URL: https://hesela.dev/terms/ide/
Also known as: Integrated Drive Electronics
Status: eol

Integrated Drive Electronics places the disk controller on the drive, the ancestor of PATA and SATA.

Related terms:
- [pata](https://hesela.dev/terms/pata/)
- [sata](https://hesela.dev/terms/sata/)
- [hdd](https://hesela.dev/terms/hdd/)
- [ahci](https://hesela.dev/terms/ahci/)
- [st-412](https://hesela.dev/terms/st-412/)

Supersedes:
- [st-506](https://hesela.dev/terms/st-506/)

Superseded by:
- [pata](https://hesela.dev/terms/pata/)

Citations:
- [c1] Parallel ATA. https://en.wikipedia.org/wiki/Parallel_ATA (accessed 2026-03-26)

### Idempotency key

URL: https://hesela.dev/terms/idempotency-key/
Also known as: Idempotency token
Status: shipping

Record updated: 2026-10-15

An idempotency key identifies attempts of one logical request so a service can recognize retries within its documented scope and retention rules.

Note: Keep identity and parameters stable for a retry. DynamoDB TransactWriteItems documents a ClientRequestToken window of ten minutes after the first request completes; changed parameters within it are rejected, and later reuse is a new request. This service-specific rule is not a universal token lifetime. An identifier alone does not provide crash durability or duplicate suppression.

Related terms:
- [idempotency](https://hesela.dev/terms/idempotency/)
- [retry-deduplication](https://hesela.dev/terms/retry-deduplication/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [dynamodb-token] Amazon DynamoDB API Reference: TransactWriteItems, ClientRequestToken contract.. https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_TransactWriteItems.html#DDB-TransactWriteItems-request-ClientRequestToken (accessed 2026-10-15)
- [hesela-timeouts] Storage timeouts: an expired timer is not a cancelled write. https://hesela.com/analyses/storage-timeouts-uncertain-completion/ (accessed 2026-10-15)

### Idempotency

URL: https://hesela.dev/terms/idempotency/
Also known as: Idempotence
Status: shipping

Record updated: 2026-10-15

Idempotency is the property that repeating the same operation with identical inputs has the same intended effect as performing it once.

Note: HTTP idempotency does not require identical responses or prohibit a separate log entry for each attempt (RFC 9110, section 9.2.2). It is not a durability or exactly-once execution guarantee. Repeating an assignment after another writer changes the value can overwrite that intervening update; duplicate suppression and concurrency control address distinct concerns.

Related terms:
- [idempotency-key](https://hesela.dev/terms/idempotency-key/)
- [retry-deduplication](https://hesela.dev/terms/retry-deduplication/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [http-idempotency] RFC 9110: HTTP Semantics (June 2022), section 9.2.2, Idempotent Methods.. https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2 (accessed 2026-10-15)
- [hesela-timeouts] Storage timeouts: an expired timer is not a cancelled write. https://hesela.com/analyses/storage-timeouts-uncertain-completion/ (accessed 2026-10-15)

### Storage immutability

URL: https://hesela.dev/terms/immutability-storage/
Status: shipping

Record updated: 2026-10-15

Storage immutability prevents specified data from being overwritten or deleted under an enforced retention rule or hold.

Note: Scope and bypass rights depend on the implementation. S3 Object Lock protects a specific object version, not the object name as a whole; new versions and delete markers remain possible. Governance bypass requires permission and an explicit bypass request. Compliance blocks user deletion during retention, including by the account root user, but is not protection against account deletion. Removing a legal hold does not end a concurrent retention period. [lock]

Advantages:
- Can enforce retention of a protected object version. (sources: [lock])

Limitations:
- A policy name alone does not describe bypass permissions or hold-removal rights. (sources: [lock])
- Retaining data does not establish recoverability; test restoration separately. (sources: [nist])
- A retained version can contain pre-existing compromise; selecting a trusted recovery point is a separate task. (sources: [s4])
- S3 Object Lock does not prevent encryption-key deletion or loss of key access; retained ciphertext may be unreadable. (sources: [manage])

Related terms:
- [worm-storage](https://hesela.dev/terms/worm-storage/)
- [object-storage](https://hesela.dev/terms/object-storage/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [backup-manifest](https://hesela.dev/terms/backup-manifest/)
- [object-versioning](https://hesela.dev/terms/object-versioning/)
- [object-lock](https://hesela.dev/terms/object-lock/)
- [legal-hold](https://hesela.dev/terms/legal-hold/)

Citations:
- [c1] Storage immutability. https://en.wikipedia.org/wiki/Object_lock (accessed 2026-03-26)
- [nist] NIST SP 800-53 Rev. 5: CP-9(1), CP-9(2) and CP-10. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf (accessed 2026-10-13)
- [lock] Amazon S3 User Guide: Locking objects with Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html (accessed 2026-10-13)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-13)
- [s4] Strunk et al.: Self-Securing Storage: Protecting Data in Compromised Systems, OSDI 2000, sections 2.2, 3.3 and 5. https://static.usenix.org/events/osdi2000/full_papers/strunk/strunk_html/index.html (accessed 2026-10-13)
- [manage] Amazon S3: Object Lock considerations. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html (accessed 2026-10-15)

### Incremental backup

URL: https://hesela.dev/terms/incremental-backup/
Status: shipping

Record updated: 2026-10-14

An incremental backup records changes relative to an earlier backup state and reuses retained backup data to represent unchanged content.

Note: For a dependent incremental format, the reference need not be the immediately previous backup: retain its actual predecessors, plus recovery WAL for PostgreSQL. [archive] In a deduplicated repository such as restic, a snapshot references a complete tree of stored blobs; restore depends on those objects, not a replay of every earlier snapshot. [restic-format]

Advantages:
- Can reduce copied data when much of a large database is unchanged. (sources: [archive])

Limitations:
- In a dependent incremental format, a missing required predecessor can prevent reconstruction. (sources: [combine])
- A legal dependency chain does not establish input integrity. (sources: [combine])

Related terms:
- [backup-manifest](https://hesela.dev/terms/backup-manifest/)
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [full-backup](https://hesela.dev/terms/full-backup/)
- [synthetic-full-backup](https://hesela.dev/terms/synthetic-full-backup/)
- [differential-backup](https://hesela.dev/terms/differential-backup/)

Citations:
- [combine] PostgreSQL 18: pg_combinebackup, dependency chains and hard links. https://www.postgresql.org/docs/18/app-pgcombinebackup.html (accessed 2026-10-13)
- [archive] PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery, sections 25.3.3 and 25.3.5. https://www.postgresql.org/docs/18/continuous-archiving.html (accessed 2026-10-13)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-13)
- [restic-format] restic repository format: snapshots, trees and data. https://restic.readthedocs.io/en/stable/100_references.html (accessed 2026-10-14)

### Independent access range (Linux)

URL: https://hesela.dev/terms/independent-access-range/
Also known as: independent_access_ranges
Status: shipping

Record updated: 2026-10-16

A Linux independent access range is an advertised region of a block device that can service requests in parallel with its other reported regions.

Note: Linux 6.14 documents /sys/block/<disk>/queue/independent_access_ranges/<index>/sector and nr_sectors in 512-byte units, independent of logical block size. Ranges cover the device without overlap. This is the kernel's representation, not the ATA log itself; absence does not establish the physical actuator count.

Related terms:
- [dual-actuator](https://hesela.dev/terms/dual-actuator/)
- [concurrent-positioning-range](https://hesela.dev/terms/concurrent-positioning-range/)
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)

Citations:
- [linux-abi] Linux 6.14 stable ABI: independent_access_ranges. https://docs.kernel.org/6.14/admin-guide/abi-stable.html#abi-sys-block-disk-queue-independent-access-ranges (accessed 2026-10-16)

### Informative censoring

URL: https://hesela.dev/terms/informative-censoring/
Also known as: Dependent censoring
Status: shipping

Record updated: 2026-10-13

Informative censoring occurs when the observation-ending process conveys information about the event time beyond what the survival analysis accounts for.

Note: Hypothetical storage example: retiring drives because worsening telemetry predicts failure can remove high-risk devices before recorded failure. If the target is failure under continued service rather than time to retirement, treating those withdrawals as ordinary independent censoring can bias an unadjusted survival curve. Record withdrawal reasons and examine sensitivity to the censoring assumptions. Observed event and censoring times alone cannot verify the assumptions that identify the target survival distribution. [overgaard-hansen]

Related terms:
- [right-censoring](https://hesela.dev/terms/right-censoring/)
- [kaplan-meier-estimator](https://hesela.dev/terms/kaplan-meier-estimator/)
- [survival-function](https://hesela.dev/terms/survival-function/)

Citations:
- [overgaard-hansen] Overgaard and Hansen: On the assumption of independent right censoring, arXiv:1905.02508v1. https://arxiv.org/html/1905.02508v1 (accessed 2026-10-13)

### SCSI initiator and target

URL: https://hesela.dev/terms/initiator-target/
Status: shipping

In SCSI, the initiator is the endpoint that sends commands and the target is the endpoint that waits for them and performs the requested data transfers; the roles apply across parallel SCSI, Fibre Channel, iSCSI and other storage protocols.

Note: In SCSI terminology, communication takes place between an initiator and a target: the initiator sends a command to the target, which then responds. Typically a computer (through its host adapter) is the initiator and a storage device is the target, and the relationship is analogous to client and server. The target usually exposes one or more logical units, addressed by LUN, because otherwise no read or write command would be possible; the initiator usually provides no LUNs. A target can be a whole subsystem: a RAID array may be a single SCSI device containing many logical units, each a virtual disk, with the SCSI ID or WWN identifying the subsystem and the LUN identifying the disk within it. Commands travel in a command descriptor block (CDB), a one-byte operation code followed by five or more bytes of parameters, and at the end of the sequence the target returns a status code byte, for example 00h for success, 02h for Check Condition (after which the initiator usually issues Request Sense) or 08h for busy. On a parallel SCSI bus each device has an ID, 0-7 on a narrow bus and 0-15 on a wide bus, and ID 7 is traditionally given to the host adapter because it has the highest priority in bus arbitration. The terms are not specific to parallel SCSI: they also apply to Fibre Channel Protocol, iSCSI, HyperSCSI, ATA over Ethernet, InfiniBand and other storage networking protocols, and nothing in the SCSI protocol prevents one endpoint from acting as both. Wikipedia notes that initiators are sometimes wrongly called controllers, and that in most protocols an address is roughly equivalent to a physical device port.

Advantages:
- A clear split of roles (initiator issues commands, target serves them) lets the same command model run over parallel SCSI, Fibre Channel, iSCSI and other transports
- A single target can present many logical units, so one subsystem such as a RAID array can expose many virtual disks addressed by LUN
- The role vocabulary carries over to network storage: iSCSI keeps the basic SCSI paradigm and command set while using logical connections over IP

Limitations:
- The initiator and target roles describe behavior of an address, not a kind of hardware, so one device can act as both and the terms are easy to confuse with controller or host
- On a parallel SCSI bus the number of addressable devices is small (8 on a narrow bus, 16 on a wide bus, host adapters included)
- Wikipedia notes that an address usually maps to one physical port; sharing one address across ports, or reaching one address through several ports, was uncommon as of 2008, so multipath setups switch between separate targets or initiators bound to ports

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [san](https://hesela.dev/terms/san/)
- [iscsi](https://hesela.dev/terms/iscsi/)
- [sas](https://hesela.dev/terms/sas/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [hba](https://hesela.dev/terms/hba/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [t10-scsi](https://hesela.dev/terms/t10-scsi/)
- [rdma-storage](https://hesela.dev/terms/rdma-storage/)

Citations:
- [c1] SCSI initiator and target (Wikipedia). https://en.wikipedia.org/wiki/SCSI_initiator_and_target (accessed 2026-10-11)
- [c2] SCSI (Wikipedia), sections on the SCSI command protocol, parallel interface and general addressing. https://en.wikipedia.org/wiki/SCSI (accessed 2026-10-11)

### Inode

URL: https://hesela.dev/terms/inode/
Also known as: index node
Status: shipping

Record updated: 2026-10-15

An inode is a filesystem object that holds a file's metadata and has a filesystem-local number, distinct from the directory names and open file descriptions that refer to the file.

Note: On Linux, stat() exposes the inode number as st_ino, the containing device as st_dev, and the hard-link count as st_nlink. Inode numbers alone are not unique across filesystems. A pathname replacement can select a different inode while an existing descriptor still refers to the previous file; inode identity is therefore different from pathname identity and from a content version. In ext4, a linked inode can also be tracked for recovery of incomplete truncation; an orphan is not necessarily an inode with no names. [linux-v6-12-ext4-orphan]

Advantages:
- Separates file metadata and identity from the names used to reach a file.

Limitations:
- An inode number alone is not a globally unique or permanent content identifier.
- Matching inode identity does not imply unchanged file contents or a shared open file description.

Related terms:
- [hard-link](https://hesela.dev/terms/hard-link/)
- [unlink](https://hesela.dev/terms/unlink/)
- [atomic-rename](https://hesela.dev/terms/atomic-rename/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [ext4-orphan-inode](https://hesela.dev/terms/ext4-orphan-inode/)
- [ext4-orphan-file](https://hesela.dev/terms/ext4-orphan-file/)

Citations:
- [linux-inode-7] Linux man-pages 6.19: inode(7). https://man7.org/linux/man-pages/man7/inode.7.html (accessed 2026-10-15)
- [linux-stat-3type] Linux man-pages 6.19: stat(3type). https://man7.org/linux/man-pages/man3/stat.3type.html (accessed 2026-10-15)
- [linux-open-2] Linux man-pages 6.19: open(2). https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-15)
- [hesela-namespace] Hesela: The name changes; existing readers do not. https://hesela.com/analyses/atomic-rename-directory-durability/#namespace-identity (accessed 2026-10-15)
- [linux-v6-12-ext4-orphan] Linux v6.12: ext4 orphan inode handling. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/ext4/orphan.c (accessed 2026-10-15)

### Interarrival time

URL: https://hesela.dev/terms/interarrival-time/
Also known as: Inter-event time
Status: shipping

Record updated: 2026-10-12

An interarrival time is the elapsed interval between consecutive events in a specified event stream.

Note: Choose the stream before computing gaps: all replacements in a fleet and replacements of a single device are different observations. The homogeneous Poisson model assumes independent, identically distributed exponential gaps; a mean gap alone does not establish that model. Event count per calendar window and gap duration are different variables.

Related terms:
- [rate-of-occurrence-of-failures](https://hesela.dev/terms/rate-of-occurrence-of-failures/)
- [annual-replacement-rate](https://hesela.dev/terms/annual-replacement-rate/)
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)

Citations:
- [nist-hpp] NIST e-Handbook 8.1.7.1: Homogeneous Poisson Process. https://www.itl.nist.gov/div898/handbook/apr/section1/apr171.htm (accessed 2026-10-12)
- [hesela-measurement-clocks] Hesela: Disk replacement rates are not disk lifetimes. https://hesela.com/analyses/mttf-vs-field-replacement-rates/ (accessed 2026-10-12)

### Invertible Bloom lookup table

URL: https://hesela.dev/terms/invertible-bloom-lookup-table/
Also known as: IBLT
Status: research

Record updated: 2026-10-16

An invertible Bloom lookup table is a randomized data structure that supports updates and can list encoded entries with high probability under its sizing assumptions.

Note: Unlike a membership-only filter, an IBLT can recover entries by repeatedly removing decodable cells. Listing can stop with an incomplete result; the configured threshold is not an unconditional guarantee. [iblt2011] Different constructions trade memory, randomness and decoding cost differently. [stacked2024]

Limitations:
- An incomplete decode is not evidence that two sets are equal. (sources: [iblt2011])

Related terms:
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [set-reconciliation](https://hesela.dev/terms/set-reconciliation/)
- [rateless-iblt](https://hesela.dev/terms/rateless-iblt/)

Citations:
- [iblt2011] Michael T. Goodrich and Michael Mitzenmacher. Invertible Bloom Lookup Tables. arXiv:1101.2245v3 (2015 revision; first submitted 2011), sections 1.3 and 2.. https://arxiv.org/abs/1101.2245v3 (accessed 2026-10-16)
- [stacked2024] Nils Fleischhacker, Kasper Green Larsen, Maciej Obremski and Mark Simkin. Invertible Bloom Lookup Tables with Less Memory and Randomness. ESA 2024. DOI: 10.4230/LIPIcs.ESA.2024.54.. https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.ESA.2024.54 (accessed 2026-10-16)
- [hesela-repair] Hesela: Replica repair, set reconciliation and record identity. https://hesela.com/analyses/replica-repair-coverage/#set-reconciliation (accessed 2026-10-16)

### I/O fencing

URL: https://hesela.dev/terms/io-fencing/
Also known as: Storage fencing
Status: shipping

Record updated: 2026-10-11

I/O fencing enforces exclusion of a node from shared storage so that recovery cannot be undermined by its continued access.

Note: Failure detection and quorum decisions do not themselves block storage traffic. A fence may act through power control, fabric access or storage-enforced reservations. Its scope must cover the resources and paths used by recovery; a storage-only fence need not stop the whole host. Use the supported cluster procedure and verify completion before proceeding.

Related terms:
- [scsi-persistent-reservations](https://hesela.dev/terms/scsi-persistent-reservations/)
- [fencing-token](https://hesela.dev/terms/fencing-token/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [san](https://hesela.dev/terms/san/)

Citations:
- [pacemaker] ClusterLabs, Pacemaker Explained 3.0: Fencing, including Fencing and Quorum.. https://clusterlabs.org/projects/pacemaker/doc/3.0/Pacemaker_Explained/html/fencing.html (accessed 2026-10-11)
- [fence-mpath] ClusterLabs fence_mpath source and embedded documentation, commit 65a423c846a91deff49271ffaeb8f7d4ed90ce50.. https://github.com/ClusterLabs/fence-agents/blob/65a423c846a91deff49271ffaeb8f7d4ed90ce50/agents/mpath/fence_mpath.py (accessed 2026-10-11)
- [hesela-fencing] Storage fencing: why a lost heartbeat does not stop writes. https://hesela.com/analyses/storage-fencing-stale-writes/ (accessed 2026-10-11)

### I/O request size

URL: https://hesela.dev/terms/io-request-size/
Also known as: Benchmark block size
Status: shipping

Record updated: 2026-10-13

I/O request size is the number of bytes requested by one input/output operation at a specified system boundary.

Note: fio's blocksize configures bytes per I/O; bssplit permits a mixture of sizes [fio]. This is distinct from a device's logical sector or filesystem allocation unit. Kernel request merging can change counts and sizes below the application boundary [linux-iostats]. When relating successful data-transfer IOPS to bytes/s, use the actual completed bytes and matching operation population, especially if sizes vary or transfers are short [hesela-accounting].

Limitations:
- Equal IOPS at different request sizes does not imply equal data throughput; a byte-weighted size average is not the required operation-weighted mean. (sources: [hesela-accounting])

Related terms:
- [iops](https://hesela.dev/terms/iops/)
- [throughput-storage](https://hesela.dev/terms/throughput-storage/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [physical-sector](https://hesela.dev/terms/physical-sector/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)

Citations:
- [fio] fio documentation: blocksize, bssplit, I/O depth and interpreting the output; online manual reviewed 13 October 2026.. https://fio.readthedocs.io/en/master/fio_doc.html (accessed 2026-10-13)
- [linux-iostats] Linux kernel documentation: I/O statistics fields; completed requests, merged requests and sectors.. https://docs.kernel.org/admin-guide/iostats.html (accessed 2026-10-13)
- [hesela-accounting] Hesela: IOPS, bytes and average occupancy; synthetic accounting examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#io-accounting (accessed 2026-10-13)

### I/O timeout

URL: https://hesela.dev/terms/io-timeout/
Also known as: I/O command timeout
Status: shipping

Record updated: 2026-10-13

An I/O timeout is expiration of a layer's waiting limit for an input/output operation, which may initiate recovery without proving that the operation never executed.

Note: Linux SCSI timeout handling can extend waiting or initiate abort and recovery. A timed-out command can still be active in lower layers. Distinguish application deadlines, command completion, cancellation and durable completion; inspect the actual driver and protocol contract.

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [no-path-retry](https://hesela.dev/terms/no-path-retry/)
- [retry-deduplication](https://hesela.dev/terms/retry-deduplication/)
- [fail-slow](https://hesela.dev/terms/fail-slow/)

Citations:
- [scsi-eh] Linux kernel documentation: SCSI EH, sections 1.2-1.4 and 2.1.. https://docs.kernel.org/scsi/scsi_eh.html (accessed 2026-10-11)
- [hesela-timeouts] Storage timeouts: an expired timer is not a cancelled write. https://hesela.com/analyses/storage-timeouts-uncertain-completion/ (accessed 2026-10-11)

### io_uring completion queue entry

URL: https://hesela.dev/terms/io-uring-cqe/
Also known as: io_uring CQE
Status: shipping

Record updated: 2026-10-14

An io_uring completion queue entry is a result record containing an operation result, flags and application-provided identification data.

Note: For ordinary one-shot writes, inspect res for the transferred byte count or a negative error number; a delivered entry alone does not mean success. A submission function's return value is a different result. [overview] [submit]

Advantages:
- Lets an application associate completion information with the submitted operation.

Limitations:
- A successful ordinary buffered write is not itself a power-loss durability guarantee.

Related terms:
- [io-uring](https://hesela.dev/terms/io-uring/)
- [io-uring-linked-requests](https://hesela.dev/terms/io-uring-linked-requests/)
- [completion-latency](https://hesela.dev/terms/completion-latency/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [overview] liburing: io_uring(7), result reporting and shared rings.. https://man7.org/linux/man-pages/man7/io_uring.7.html (accessed 2026-10-14)
- [submit] liburing: io_uring_submit(3), submission return value.. https://man7.org/linux/man-pages/man3/io_uring_submit.3.html (accessed 2026-10-14)
- [sync] Linux man-pages: fsync(2), error and directory persistence boundaries.. https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-14)
- [hesela-uring] io_uring: completion is not a durable commit. https://hesela.com/analyses/io-uring-completion-ordering-durability/ (accessed 2026-10-14)

### io_uring drain

URL: https://hesela.dev/terms/io-uring-drain/
Also known as: IOSQE_IO_DRAIN
Status: shipping

Record updated: 2026-10-14

io_uring drain is a submission flag that delays a request until earlier requests in the same ring finish and delays later requests until the drain request finishes.

Note: Drain orders completion within one ring; it is not a device-cache flush. [flags] The documented API forbids mixing IO_DRAIN with IOSQE_CQE_SKIP_SUCCESS in one ring, including on separate requests. [enter]

Advantages:
- Can establish a ring-scoped dependency before a synchronization request.

Limitations:
- It does not order another ring or validate earlier write results.

Related terms:
- [io-uring](https://hesela.dev/terms/io-uring/)
- [io-uring-linked-requests](https://hesela.dev/terms/io-uring-linked-requests/)
- [fsync](https://hesela.dev/terms/fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [flags] liburing 2.9: io_uring_sqe_set_flags(3), chain and drain scope.. https://github.com/axboe/liburing/blob/liburing-2.9/man/io_uring_sqe_set_flags.3 (accessed 2026-10-14)
- [enter] liburing: io_uring_enter(2), IORING_OP_FSYNC, linking and CQE_SKIP_SUCCESS constraints.. https://man7.org/linux/man-pages/man2/io_uring_enter.2.html (accessed 2026-10-14)
- [hesela-uring] io_uring: completion is not a durable commit. https://hesela.com/analyses/io-uring-completion-ordering-durability/ (accessed 2026-10-14)

### io_uring integrity metadata

URL: https://hesela.dev/terms/io-uring-integrity-metadata/
Also known as: io_uring PI attribute
Status: shipping

Record updated: 2026-10-15

io_uring integrity metadata is a separately described protection-information buffer attached to a read or write request through SQE attributes.

Note: In Linux v6.14, attr_type_mask selects IORING_RW_ATTR_FLAG_PI and attr_ptr identifies io_uring_attr_pi, whose addr and len describe metadata rather than file-data bytes. Initialize the reserved field to zero. [pi-uapi] [pi-rw] The request path requires O_DIRECT; the block mapping path rejects a missing integrity profile, insufficient metadata or unsupported check flags. Zero check flags do not request guard, reference-tag and application-tag checks automatically. Kernel ABI presence alone does not prove filesystem or device support. [pi-rw] [pi-map] [pi-fops]

Advantages:
- Lets participating applications supply integrity metadata alongside ordinary read/write requests.

Limitations:
- Does not itself establish persistence, freshness, cryptographic authentication or repair.
- The reviewed Linux v6.14 path does not accept user PI for buffered I/O; metadata format and checks depend on the supported stack.

Related terms:
- [io-uring](https://hesela.dev/terms/io-uring/)
- [protection-information](https://hesela.dev/terms/protection-information/)
- [end-to-end-data-protection](https://hesela.dev/terms/end-to-end-data-protection/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [io-uring-cqe](https://hesela.dev/terms/io-uring-cqe/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [pi-uapi] Linux v6.14: io_uring userspace ABI, SQE attributes and io_uring_attr_pi.. https://github.com/torvalds/linux/blob/v6.14/include/uapi/linux/io_uring.h (accessed 2026-10-15)
- [pi-rw] Linux v6.14: io_prep_rw_pi, io_prep_rw and io_rw_init_file in io_uring/rw.c.. https://github.com/torvalds/linux/blob/v6.14/io_uring/rw.c (accessed 2026-10-15)
- [pi-map] Linux v6.14: bio_integrity_map_iter and explicit integrity-check flags.. https://github.com/torvalds/linux/blob/v6.14/block/bio-integrity.c (accessed 2026-10-15)
- [pi-fops] Linux v6.14: direct block-device I/O mapping of user integrity metadata.. https://github.com/torvalds/linux/blob/v6.14/block/fops.c (accessed 2026-10-15)
- [hesela-uring-pi] Hesela: io_uring integrity metadata is a separate contract.. https://hesela.com/analyses/io-uring-completion-ordering-durability/#integrity-metadata (accessed 2026-10-15)

### io_uring linked requests

URL: https://hesela.dev/terms/io-uring-linked-requests/
Also known as: IOSQE_IO_LINK, IOSQE_IO_HARDLINK
Status: shipping

Record updated: 2026-10-14

io_uring linked requests are a chain of submission entries whose dependencies delay each successor until its predecessor completes.

Note: IO_LINK is local to its chain and does not order unrelated requests. A chain must stay within a submission boundary. IO_HARDLINK retains a link across a completion error; it does not convert the failed operation into a successful one. [flags]

Advantages:
- Expresses dependencies without waiting in user space between every operation.

Limitations:
- Ordering a chain does not make its side effects an atomic transaction.

Related terms:
- [io-uring](https://hesela.dev/terms/io-uring/)
- [io-uring-cqe](https://hesela.dev/terms/io-uring-cqe/)
- [io-uring-drain](https://hesela.dev/terms/io-uring-drain/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [flags] liburing 2.9: io_uring_sqe_set_flags(3), chain and drain scope.. https://github.com/axboe/liburing/blob/liburing-2.9/man/io_uring_sqe_set_flags.3 (accessed 2026-10-14)
- [hesela-uring] io_uring: completion is not a durable commit. https://hesela.com/analyses/io-uring-completion-ordering-durability/ (accessed 2026-10-14)

### io_uring

URL: https://hesela.dev/terms/io-uring/
Also known as: Linux io_uring
Status: shipping

Record updated: 2026-10-15

io_uring is a Linux asynchronous I/O interface that exchanges requests and completion results through shared submission and completion rings.

Note: Batching can reduce per-request submission overhead; it does not establish persistence. The completion result belongs to the specific operation, not to the ring as a whole. For file updates, identify the write set and its synchronization protocol. [overview] Linux v6.14 supports a separate PI metadata attribute for reads/writes; that path requires O_DIRECT and participating lower layers, and does not replace synchronization. [pi-rw]

Advantages:
- Supports batched asynchronous operations without requiring every request to use a separate synchronous syscall.

Limitations:
- Availability and behavior depend on the operation, kernel and filesystem.

Related terms:
- [io-uring-cqe](https://hesela.dev/terms/io-uring-cqe/)
- [io-uring-linked-requests](https://hesela.dev/terms/io-uring-linked-requests/)
- [io-uring-drain](https://hesela.dev/terms/io-uring-drain/)
- [fsync](https://hesela.dev/terms/fsync/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)
- [io-uring-integrity-metadata](https://hesela.dev/terms/io-uring-integrity-metadata/)

Citations:
- [overview] liburing: io_uring(7), result reporting and shared rings.. https://man7.org/linux/man-pages/man7/io_uring.7.html (accessed 2026-10-14)
- [hesela-uring] io_uring: completion is not a durable commit. https://hesela.com/analyses/io-uring-completion-ordering-durability/ (accessed 2026-10-14)
- [pi-rw] Linux v6.14: io_prep_rw_pi, io_prep_rw and io_rw_init_file in io_uring/rw.c.. https://github.com/torvalds/linux/blob/v6.14/io_uring/rw.c (accessed 2026-10-15)
- [pi-map] Linux v6.14: bio_integrity_map_iter and explicit integrity-check flags.. https://github.com/torvalds/linux/blob/v6.14/block/bio-integrity.c (accessed 2026-10-15)

### IOPS

URL: https://hesela.dev/terms/iops/
Also known as: Input/output operations per second
Status: shipping

Record updated: 2026-10-13

Observed IOPS is the number of completed input/output operations divided by the measurement duration at a specified system boundary.

Note: State the counted operation types, elapsed interval, request sizes and treatment of errors; an offered request rate is not a completion rate. Linux block statistics separately count completed requests and merged requests, so application and device counts need not agree [linux-iostats]. For the same successful data-transfer operations and interval, bytes/s equals IOPS multiplied by the operation-weighted mean completed size; this is accounting, not a prediction of device capacity [hesela-accounting]. Directional fio runtime denominators and interval-sampled iops_mean are distinct reporting quantities; establish a common observation window before combining rates [fio-stat].

Limitations:
- An IOPS figure without its workload, measurement boundary and latency distribution does not establish performance for another workload. (sources: [fio], [hesela-accounting])

Related terms:
- [queue-depth](https://hesela.dev/terms/queue-depth/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [throughput-storage](https://hesela.dev/terms/throughput-storage/)
- [io-request-size](https://hesela.dev/terms/io-request-size/)
- [little-law](https://hesela.dev/terms/little-law/)

Citations:
- [c1] IOPS. https://en.wikipedia.org/wiki/IOPS (accessed 2026-03-26)
- [fio] fio documentation: blocksize, bssplit, I/O depth and interpreting the output; online manual reviewed 13 October 2026.. https://fio.readthedocs.io/en/master/fio_doc.html (accessed 2026-10-13)
- [linux-iostats] Linux kernel documentation: I/O statistics fields; completed requests, merged requests and sectors.. https://docs.kernel.org/admin-guide/iostats.html (accessed 2026-10-13)
- [hesela-accounting] Hesela: IOPS, bytes and average occupancy; synthetic accounting examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#io-accounting (accessed 2026-10-13)
- [fio-stat] fio 3.41 source: stat.c, add_ddir_lat_json and add_ddir_status_json; latency sample counts and directional runtime denominators.. https://github.com/axboe/fio/blob/fio-3.41/stat.c#L1410-L1600 (accessed 2026-10-13)
- [hesela-populations] Hesela: fio summaries, latency sample populations and runtime denominators; synthetic examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#fio-populations (accessed 2026-10-13)

### iSCSI

URL: https://hesela.dev/terms/iscsi/
Status: shipping

Record updated: 2026-10-13

SCSI block commands carried over IP networks, allowing SAN-like access without dedicated FC hardware.

Note: iSCSI transports SCSI commands over TCP between initiators and targets; it is a transport mapping, not a new recording medium or a replacement for the SCSI command model. Its SCSI response includes sense data when CHECK CONDITION is returned. [rfc7143]

Related terms:
- [san](https://hesela.dev/terms/san/)
- [scsi](https://hesela.dev/terms/scsi/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [alua](https://hesela.dev/terms/alua/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)

Citations:
- [c1] iSCSI. https://en.wikipedia.org/wiki/ISCSI (accessed 2026-03-26)
- [rfc7143] RFC 7143: SCSI concepts and iSCSI transport; sections 4.1, 4.2 and 11.4.7. https://www.rfc-editor.org/rfc/rfc7143.html (accessed 2026-10-13)

### JBOD

URL: https://hesela.dev/terms/jbod/
Status: shipping

Just a Bunch Of Disks presents individual drives without RAID virtualization in the enclosure.

Related terms:
- [sas-expander](https://hesela.dev/terms/sas-expander/)
- [hba](https://hesela.dev/terms/hba/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] JBOD. https://en.wikipedia.org/wiki/Non-RAID_drive_architectures (accessed 2026-03-26)

### JEDEC SSD standards

URL: https://hesela.dev/terms/jedec-solid-state/
Status: shipping

JEDEC publishes endurance and environmental specs referenced by enterprise SSD vendors.

Related terms:
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [dwpd](https://hesela.dev/terms/dwpd/)

Citations:
- [c1] JEDEC SSD standards. https://en.wikipedia.org/wiki/JEDEC (accessed 2026-03-26)

### Journal checkpoint

URL: https://hesela.dev/terms/journal-checkpoint/
Also known as: JBD2 checkpoint
Status: shipping

Record updated: 2026-10-15

In JBD2 terminology, a journal checkpoint writes committed journaled state to its home locations so the corresponding log space can be reclaimed.

Note: This is not the same event as committing recovery information to the journal. In JBD2, checkpointing concerns committed buffers and journal-space management. [api] Do not infer an application's transaction boundary from this filesystem mechanism. [hesela] XFS uses checkpoint for a batched transaction written to its journal, not this JBD2 home-writeback stage. [xfs-design]

Limitations:
- The cited Linux v6.12 mechanism and explanatory model do not certify a deployed kernel or storage stack. (sources: [hesela])

Related terms:
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [journal-revoke-record](https://hesela.dev/terms/journal-revoke-record/)
- [ext4-fast-commit](https://hesela.dev/terms/ext4-fast-commit/)
- [physical-journaling](https://hesela.dev/terms/physical-journaling/)
- [logical-journaling](https://hesela.dev/terms/logical-journaling/)
- [xfs-delayed-logging](https://hesela.dev/terms/xfs-delayed-logging/)
- [xfs-ail](https://hesela.dev/terms/xfs-ail/)

Citations:
- [api] Linux v6.12: The Linux Journalling API, checkpointing. https://www.kernel.org/doc/html/v6.12/filesystems/journalling.html (accessed 2026-10-14)
- [hesela] Hesela: Ext4 journal replay, revocation and repeatable recovery. https://hesela.com/analyses/ext4-journal-replay-revocation/ (accessed 2026-10-14)
- [xfs-design] Linux v6.16: XFS Logging Design, asynchronous transactions, checkpoints and item lifecycle. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-15)

### Journal revoke record

URL: https://hesela.dev/terms/journal-revoke-record/
Also known as: JBD2 revocation
Status: shipping

Record updated: 2026-10-14

A journal revoke record identifies a block whose older journaled images must not be replayed over newer uses of that block.

Note: JBD2 tracks the latest revoking transaction per block; subsequent transaction images can still replay. [revoke] The concept is not secure erasure or permanent invalidation. The linked model illustrates the distinction with already committed records. [hesela]

Limitations:
- The cited Linux v6.12 mechanism and explanatory model do not certify a deployed kernel or storage stack. (sources: [hesela])

Related terms:
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [journal-checkpoint](https://hesela.dev/terms/journal-checkpoint/)
- [ext4-fast-commit](https://hesela.dev/terms/ext4-fast-commit/)

Citations:
- [revoke] Linux v6.12: fs/jbd2/revoke.c, recovery rules and jbd2_journal_test_revoke. https://github.com/torvalds/linux/blob/v6.12/fs/jbd2/revoke.c (accessed 2026-10-14)
- [hesela] Hesela: Ext4 journal replay, revocation and repeatable recovery. https://hesela.com/analyses/ext4-journal-replay-revocation/ (accessed 2026-10-14)

### Kaplan-Meier estimator

URL: https://hesela.dev/terms/kaplan-meier-estimator/
Also known as: Product-limit estimator, Kaplan-Meier estimate
Status: shipping

Record updated: 2026-10-13

The Kaplan-Meier estimator is a nonparametric estimator of the survival function that multiplies conditional survival estimates at observed event times while accounting for right-censored observations.

Note: At each distinct failure time, multiply by 1 - d_i/n_i, where d_i counts failures and n_i counts devices at risk just beforehand. Censoring removes devices from later risk sets without causing a failure step. [nist-km] Interpretation requires appropriate censoring assumptions; nonparametric does not mean assumption-free. [kaplan-meier-1958] For delayed entry, devices contribute to risk sets only after their observed entry ages. Adjusted risk sets can support population survival estimation under suitable truncation assumptions, but do not reconstruct individual unobserved failures or identify survival before ages supported by the cohort. [schisterman-2013] Report numbers at risk, uncertainty and the supported time range, not an extrapolated lifetime guarantee. For tied recorded failure and censoring times, the usual failure-before-censoring convention includes the censored unit in that event-time risk set. If the last observation is censored, the tail need not fall to zero; it is not a lifetime extrapolation. [kaplan-meier-1958]

Related terms:
- [survival-function](https://hesela.dev/terms/survival-function/)
- [right-censoring](https://hesela.dev/terms/right-censoring/)
- [left-truncation](https://hesela.dev/terms/left-truncation/)
- [informative-censoring](https://hesela.dev/terms/informative-censoring/)
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)

Citations:
- [nist-km] NIST e-Handbook 8.2.1.5: Empirical model fitting, Kaplan-Meier approach. https://www.itl.nist.gov/div898/handbook/apr/section2/apr215.htm (accessed 2026-10-13)
- [kaplan-meier-1958] Kaplan and Meier (1958): Nonparametric Estimation from Incomplete Observations, sections 1.1, 1.4 and 2.1. https://web.stanford.edu/~lutian/coursepdf/KMpaper.pdf (accessed 2026-10-13)
- [schisterman-2013] Schisterman et al. (2013): Accuracy Loss Due to Selection Bias in Cohort Studies with Left Truncation, Discussion. https://pmc.ncbi.nlm.nih.gov/articles/PMC6151356/ (accessed 2026-10-13)

### Key-value separation

URL: https://hesela.dev/terms/key-value-separation/
Also known as: KV separation
Status: shipping

Record updated: 2026-10-12

Key-value separation stores values outside the main key index and retains references in that index.

Note: Separating value movement from index sorting introduces a separate reclamation problem; it does not eliminate cleaning. [blobdb]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [value-log](https://hesela.dev/terms/value-log/)
- [database-write-amplification](https://hesela.dev/terms/database-write-amplification/)

Citations:
- [blobdb] RocksDB project. BlobDB: integrated implementation, garbage collection and configuration. Documentation reviewed 12 October 2026; page displays revision date 22 September 2022.. https://github.com/facebook/rocksdb/wiki/BlobDB (accessed 2026-10-12)
- [hesela-kv] Key-value separation: the cleaning bill moves elsewhere. https://hesela.com/analyses/key-value-separation-cleaning-cost/ (accessed 2026-10-12)

### Key-value SSD

URL: https://hesela.dev/terms/key-value-ssd/
Status: limited

A drive exposing key-value semantics instead of fixed-size LBAs for database and cache offload.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [computational-storage](https://hesela.dev/terms/computational-storage/)

Citations:
- [c1] Key-value SSD. https://en.wikipedia.org/wiki/Key-value_store (accessed 2026-03-26)

### Storage latency

URL: https://hesela.dev/terms/latency-storage/
Status: shipping

Record updated: 2026-10-15

Storage latency is the elapsed time between specified start and completion events for an I/O operation, including any delays inside those measurement boundaries.

Note: Specify whether timing begins at application arrival, I/O creation or submission; read delivery and write completion are not interchangeable persistence guarantees. Pool comparable means using the number of observations for each statistic, not an equal weight for each summary row. Check fio latency N: the cited version can emit mean zero for an empty sample set [fio-stat].

Related terms:
- [iops](https://hesela.dev/terms/iops/)
- [nvme](https://hesela.dev/terms/nvme/)
- [coordinated-omission](https://hesela.dev/terms/coordinated-omission/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)
- [submission-latency](https://hesela.dev/terms/submission-latency/)
- [completion-latency](https://hesela.dev/terms/completion-latency/)
- [tail-latency](https://hesela.dev/terms/tail-latency/)

Citations:
- [c1] Storage latency. https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics (accessed 2026-03-26)
- [fio] fio documentation: I/O depth, io_submit_mode and interpreting slat/clat/lat. Online manual reviewed 11 October 2026.. https://fio.readthedocs.io/en/master/fio_doc.html (accessed 2026-10-11)
- [hesela-latency] Hesela: synthetic arrival cohorts, timing boundaries and percentile pooling. https://hesela.com/analyses/storage-latency-coordinated-omission/ (accessed 2026-10-11)
- [fio-stat] fio 3.41 source: stat.c, add_ddir_lat_json and add_ddir_status_json; latency sample counts and directional runtime denominators.. https://github.com/axboe/fio/blob/fio-3.41/stat.c#L1410-L1600 (accessed 2026-10-13)
- [hesela-populations] Hesela: fio summaries, latency sample populations and runtime denominators; synthetic examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#fio-populations (accessed 2026-10-13)
- [hesela-tail] Hesela: Slow RAID hours are not request tail latency; source audit and reproducible counterexamples. https://hesela.com/analyses/storage-tail-slowdowns-raid-fanout/ (accessed 2026-10-15)

### Latent sector error

URL: https://hesela.dev/terms/latent-sector-error/
Also known as: LSE
Status: shipping

A latent sector error is an inaccessible sector whose failure remains undiscovered until that location is accessed.

Note: This is a sector-level observation, not necessarily a failed drive or irrecoverable loss at the array level.

Related terms:
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [raid-6](https://hesela.dev/terms/raid-6/)

Citations:
- [lse] Bairavasundaram, Goodson, Pasupathy and Schindler. An Analysis of Latent Sector Errors in Disk Drives. SIGMETRICS 2007, sections 2-4.. https://research.cs.wisc.edu/adsl/Publications/latent-sigmetrics07.pdf (accessed 2026-10-11)
- [hesela-scrub] Hesela: Scrubbing, detection time and repair boundaries. https://hesela.com/analyses/scrubbing-detection-not-durability/ (accessed 2026-10-11)

### Layer-to-layer process variation

URL: https://hesela.dev/terms/layer-to-layer-process-variation/
Status: shipping

Layer-to-layer process variation is fabrication-related variation in cell characteristics between vertical layers of a 3D NAND die.

Note: An average across layers can hide differences in raw error rates and read-reference settings; layer count alone does not quantify this variation.

Limitations:
- The cited single-vendor characterization is not a modern SSD fleet failure-rate estimate. (sources: [luo])

Related terms:
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [bit-error-rate](https://hesela.dev/terms/bit-error-rate/)

Citations:
- [luo] Luo, Ghose, Cai, Haratsch and Mutlu. Improving 3D NAND Flash Memory Lifetime by Tolerating Early Retention Loss and Process Variation. POMACS author manuscript, 2018, sections 4.1-4.4. https://ghose.cs.illinois.edu/papers/18sigmetrics_3dflash.pdf (accessed 2026-10-11)
- [hesela3d] Hesela: 3D NAND retention, cell architecture and evidence limits. https://hesela.com/analyses/3d-nand-retention-evidence/ (accessed 2026-10-11)

### LDPC (NAND ECC)

URL: https://hesela.dev/terms/ldpc/
Also known as: low-density parity-check code
Status: shipping

Record updated: 2026-10-12

An LDPC code is an error-correcting linear block code defined by a sparse parity-check matrix.

Note: In NAND, repeated sensing can supply confidence information for iterative decoding; the code family alone does not specify the recovery policy.

Advantages:
- Soft information can improve decoding compared with hard decisions in the studied channel models. (sources: [wang2011])

Limitations:
- A channel quantization that maximizes mutual information need not minimize frame errors for a finite code with absorbing sets. (sources: [wang2014])

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [ssd](https://hesela.dev/terms/ssd/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [soft-decision-decoding](https://hesela.dev/terms/soft-decision-decoding/)
- [log-likelihood-ratio](https://hesela.dev/terms/log-likelihood-ratio/)
- [bit-error-rate](https://hesela.dev/terms/bit-error-rate/)
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)
- [codeword](https://hesela.dev/terms/codeword/)
- [raw-bit-error-rate](https://hesela.dev/terms/raw-bit-error-rate/)
- [uncorrectable-bit-error-rate](https://hesela.dev/terms/uncorrectable-bit-error-rate/)

Citations:
- [c1] LDPC (NAND ECC). https://en.wikipedia.org/wiki/Low-density_parity-check_code (accessed 2026-03-26)
- [wang2011] Wang, Courtade, Shankar and Wesel. Soft Information for LDPC Decoding in Flash: Mutual-Information Optimized Quantization. IEEE GLOBECOM 2011, sections II-IV.. https://www.seas.ucla.edu/csl/files/publications/Jiadong_GC2011.pdf (accessed 2026-10-11)
- [wang2014] Wang et al. Enhanced Precision Through Multiple Reads for LDPC Decoding in Flash Memories. Author manuscript arXiv:1309.0566v4, 2014, sections IV and V.D.. https://arxiv.org/abs/1309.0566v4 (accessed 2026-10-11)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-11)

### Left-truncation

URL: https://hesela.dev/terms/left-truncation/
Also known as: Delayed entry
Status: shipping

Record updated: 2026-10-13

Left-truncation is selection into a time-to-event sample only after a unit has survived to its observation-entry time.

Note: A drive already several years old at the start of a study enters the observed risk set at that age, not at birth. Drives that failed before entry are absent. This differs from right-censoring, which limits follow-up after entry, and from an unknown or missing age value. Models for a lifetime-from-birth question must account for delayed entry under their stated assumptions. Adjusting risk sets alone does not remove informative-entry bias or identify survival before the earliest supported entry age. [schisterman-2013]

Related terms:
- [right-censoring](https://hesela.dev/terms/right-censoring/)
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)
- [drive-day](https://hesela.dev/terms/drive-day/)
- [survival-function](https://hesela.dev/terms/survival-function/)
- [kaplan-meier-estimator](https://hesela.dev/terms/kaplan-meier-estimator/)

Citations:
- [oakley-2024] Oakley, Forshaw, Philipson and Wilson (2024), Examining the impact of critical attributes on hard drive failure times, sections 1-3. https://doi.org/10.1002/asmb.2829 (accessed 2026-10-10)
- [hesela-age-audit] Hesela: Missing SMART ages and the limits of drive-age comparisons. https://hesela.com/analyses/backblaze-age-missing-data-audit/ (accessed 2026-10-11)
- [schisterman-2013] Schisterman et al. (2013): Accuracy Loss Due to Selection Bias in Cohort Studies with Left Truncation, Discussion. https://pmc.ncbi.nlm.nih.gov/articles/PMC6151356/ (accessed 2026-10-13)

### Legal hold (storage)

URL: https://hesela.dev/terms/legal-hold/
Also known as: Object legal hold, S3 legal hold
Status: shipping

Record updated: 2026-10-15

A storage legal hold prevents deletion or replacement of protected data until an authorized action removes the hold, rather than expiring on a preset date.

Note: In S3, legal hold is independent of retention: expiry of the retention period leaves the hold active, and removal of the hold leaves unexpired retention active. The s3:PutObjectLegalHold permission controls setting and removing it. [lock] This record describes storage behavior, not whether a legal preservation obligation is satisfied.

Advantages:
- The S3 API can target a versionId and set its legal-hold status to ON or OFF. (sources: [holdapi])

Limitations:
- This API is not supported for directory buckets or S3 on Outposts; compatible-service behavior must be verified separately. (sources: [holdapi])

Related terms:
- [object-lock](https://hesela.dev/terms/object-lock/)
- [object-versioning](https://hesela.dev/terms/object-versioning/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [worm-storage](https://hesela.dev/terms/worm-storage/)

Citations:
- [lock] Amazon S3: Locking objects with Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html (accessed 2026-10-15)
- [holdapi] Amazon S3 API: PutObjectLegalHold. https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectLegalHold.html (accessed 2026-10-15)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-15)

### Leveled compaction

URL: https://hesela.dev/terms/leveled-compaction/
Also known as: Level compaction
Status: shipping

Record updated: 2026-10-14

Leveled compaction organizes sorted data into levels with size targets and merges selected data with overlapping key ranges in a destination level.

Note: In RocksDB, each nonzero level is one sorted run partitioned across SST files with nonoverlapping key ranges within that level; L0 can contain multiple overlapping runs. One run is not necessarily one file. [rocks-levels] Compared with tiering, leveling usually trades more rewriting for fewer candidate runs and lower space overhead, but workload skew and file-selection policy affect that trade-off. RocksDB's L0 makes its Level policy a tiered-plus-leveled hybrid. [rocks-compaction]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [compaction](https://hesela.dev/terms/compaction/)
- [tiered-compaction](https://hesela.dev/terms/tiered-compaction/)
- [read-amplification](https://hesela.dev/terms/read-amplification/)
- [space-amplification](https://hesela.dev/terms/space-amplification/)

Citations:
- [rocks-levels] RocksDB project. Leveled Compaction: sorted runs and the L0 exception.. https://github.com/facebook/rocksdb/wiki/Leveled-Compaction (accessed 2026-10-14)
- [rocks-compaction] RocksDB project. Compaction: leveled, tiered and hybrid policies.. https://github.com/facebook/rocksdb/wiki/Compaction (accessed 2026-10-14)
- [hesela] Hesela. Bloom filters: optimize the lookup, not each filter; compaction and measurement boundaries.. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-14)

### Linearizability

URL: https://hesela.dev/terms/linearizability/
Also known as: Linearizable consistency
Status: shipping

Record updated: 2026-10-13

Linearizability requires concurrent operations on an object to behave as a legal sequential execution that preserves the real-time order of non-overlapping operations.

Note: Each operation can be placed at a point between invocation and response. An overlapping write may finish before a read responds without having to precede that read in the legal order. Separate linearizable reads and writes do not make a client's read-modify-write sequence atomic. Persistence across failures needs an explicit recovery contract.

Related terms:
- [serializability](https://hesela.dev/terms/serializability/)
- [read-your-writes](https://hesela.dev/terms/read-your-writes/)
- [monotonic-reads](https://hesela.dev/terms/monotonic-reads/)
- [compare-and-swap](https://hesela.dev/terms/compare-and-swap/)
- [quorum-intersection](https://hesela.dev/terms/quorum-intersection/)

Citations:
- [herlihy-wing] Maurice P. Herlihy and Jeannette M. Wing. Linearizability: A Correctness Condition for Concurrent Objects. ACM TOPLAS 12(3), 1990, sections 2.2 and 3.3.. https://www.cs.cmu.edu/~wing/publications/HerlihyWing90.pdf (accessed 2026-10-12)
- [etcd-guarantees] etcd v3.6 API guarantees: durability, strict serializability and operation completion.. https://etcd.io/docs/v3.6/learning/api_guarantees/ (accessed 2026-10-12)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-12)

### Little's law

URL: https://hesela.dev/terms/little-law/
Also known as: L = lambda W
Status: shipping

Record updated: 2026-10-13

Little's law relates time-averaged occupancy L to the operation rate lambda and mean residence time W within the same system boundary.

Note: L = lambda x W uses a time average for occupancy, a count per time for rate and an arithmetic mean over operations for residence time [little1961] [little2011]. For ordinary benchmark estimates, use a stable population and account for unfinished operations crossing the measurement window. An empty-to-empty finite trace also permits an exact occupancy-area identity without constant load. Hesela's arithmetic example, 10,000 operations/s x 0.002 s/operation = 20 average outstanding operations, is not a hardware measurement [hesela-accounting]. In Hesela's two-request cropped-window example, time-averaged occupancy is 1.2 while the completion rate multiplied by full mean completed-request residence gives 0.6; pre-window and unfinished work explain the mismatch [hesela-accounting].

Limitations:
- Substituting p99 latency or a configured queue limit changes the quantities in the law; it does not predict required concurrency or attainable device IOPS. (sources: [little2011], [hesela-accounting])

Related terms:
- [queue-depth](https://hesela.dev/terms/queue-depth/)
- [iops](https://hesela.dev/terms/iops/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [open-loop-load](https://hesela.dev/terms/open-loop-load/)
- [closed-loop-load](https://hesela.dev/terms/closed-loop-load/)

Citations:
- [little1961] John D. C. Little. A Proof for the Queuing Formula: L = lambda W. Operations Research 9(3), 383-387 (1961). DOI: 10.1287/opre.9.3.383.. https://doi.org/10.1287/opre.9.3.383 (accessed 2026-10-13)
- [little2011] John D. C. Little. Little's Law as Viewed on Its 50th Anniversary. Operations Research 59(3), 536-549 (2011), pp. 537-539. DOI: 10.1287/opre.1110.0940.. https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf (accessed 2026-10-13)
- [hesela-accounting] Hesela: IOPS, bytes and average occupancy; synthetic accounting examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#io-accounting (accessed 2026-10-13)

### LMDB reader table

URL: https://hesela.dev/terms/lmdb-reader-table/
Also known as: LMDB reader lock table
Status: shipping

Record updated: 2026-10-16

The LMDB reader table records reader process, thread and transaction identities so page reclamation can respect active snapshots.

Note: In LMDB 0.9.33, mdb_find_oldest scans reader transaction IDs and allocation excludes free-list records that are too recent for that boundary. A live old snapshot can therefore delay reuse without holding the writer mutex. [implementation] Our experiment found that mdb_reader_check cleared zero slots and did not relieve the live-reader case; ending the reader allowed 64 more writes at the same map size. [hesela-observation] A reset read-transaction handle is not an active snapshot; it must be renewed before reuse. [api]

Limitations:
- Map capacity, reusable pages and live payload bytes are different quantities; these test counts are not universal thresholds. (sources: [hesela-observation])

Related terms:
- [lmdb](https://hesela.dev/terms/lmdb/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [checkpoint-starvation](https://hesela.dev/terms/checkpoint-starvation/)

Citations:
- [chu] Howard Chu. MDB: A Memory-Mapped Database and Backend for OpenLDAP. LDAPCon 2011, sections 3.2 and 4.2.. https://www.openldap.org/pub/hyc/mdb-paper.pdf (accessed 2026-10-16)
- [api] LMDB 0.9.33 API: transaction lifetime, reset/renew, map capacity and reader checks. https://github.com/LMDB/lmdb/blob/3a29a24777c82a0165de813ae696a5068b5add30/libraries/liblmdb/lmdb.h (accessed 2026-10-16)
- [implementation] LMDB 0.9.33 implementation: mdb_find_oldest, mdb_page_alloc and mdb_reader_check0. https://github.com/LMDB/lmdb/blob/3a29a24777c82a0165de813ae696a5068b5add30/libraries/liblmdb/mdb.c (accessed 2026-10-16)
- [hesela-observation] Hesela: controlled LMDB reader-lifetime experiment, complete results and limits. https://hesela.dev/research/lmdb-reader-lifetime.json (accessed 2026-10-16)
- [hesela-analysis] LMDB readers: a stable snapshot can exhaust a fixed map. https://hesela.com/analyses/lmdb-readers-page-reuse-map-full/ (accessed 2026-10-16)

### LMDB

URL: https://hesela.dev/terms/lmdb/
Also known as: Lightning Memory-Mapped Database
Status: shipping

Record updated: 2026-10-16

LMDB is an embedded transactional key-value database that uses memory-mapped B+ trees, copy-on-write updates and multi-version concurrency control.

Note: The original MDB design separates the application tree from a transaction-indexed free-page tree. [chu] Our pinned C-API experiment kept eight 16 KiB values while varying reader lifetime; an active snapshot exhausted fixed 1 MiB and 2 MiB maps, whereas ended and reset-reader controls completed 256 overwrites. These are constructed observations, not a benchmark or failure-rate estimate. [hesela-observation]

Limitations:
- Map capacity, reusable pages and live payload bytes are different quantities; these test counts are not universal thresholds. (sources: [hesela-observation])

Related terms:
- [lmdb-reader-table](https://hesela.dev/terms/lmdb-reader-table/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [snapshot-isolation](https://hesela.dev/terms/snapshot-isolation/)

Citations:
- [chu] Howard Chu. MDB: A Memory-Mapped Database and Backend for OpenLDAP. LDAPCon 2011, sections 3.2 and 4.2.. https://www.openldap.org/pub/hyc/mdb-paper.pdf (accessed 2026-10-16)
- [api] LMDB 0.9.33 API: transaction lifetime, reset/renew, map capacity and reader checks. https://github.com/LMDB/lmdb/blob/3a29a24777c82a0165de813ae696a5068b5add30/libraries/liblmdb/lmdb.h (accessed 2026-10-16)
- [implementation] LMDB 0.9.33 implementation: mdb_find_oldest, mdb_page_alloc and mdb_reader_check0. https://github.com/LMDB/lmdb/blob/3a29a24777c82a0165de813ae696a5068b5add30/libraries/liblmdb/mdb.c (accessed 2026-10-16)
- [hesela-observation] Hesela: controlled LMDB reader-lifetime experiment, complete results and limits. https://hesela.dev/research/lmdb-reader-lifetime.json (accessed 2026-10-16)
- [hesela-analysis] LMDB readers: a stable snapshot can exhaust a fixed map. https://hesela.com/analyses/lmdb-readers-page-reuse-map-full/ (accessed 2026-10-16)

### Locally repairable code

URL: https://hesela.dev/terms/locally-repairable-code/
Also known as: LRC, local reconstruction code
Status: shipping

Record updated: 2026-10-11

A locally repairable code is an erasure code that provides recovery of specified missing fragments from a small subset of surviving fragments.

Note: Data locality and all-fragment locality differ: a global-parity repair need not have the same cost as a data-fragment repair. The code construction determines which erasure patterns remain decodable; local redundancy is not interchangeable with global redundancy.

Related terms:
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [repair-locality](https://hesela.dev/terms/repair-locality/)
- [repair-read-amplification](https://hesela.dev/terms/repair-read-amplification/)

Citations:
- [ceph-lrc] Ceph: Locally Repairable Erasure Code Plugin (development documentation; parameter names are implementation-specific).. https://docs.ceph.com/en/latest/rados/operations/erasure-code-lrc/ (accessed 2026-10-11)
- [hesela-lrc] Local repair is not whole-node repair. https://hesela.com/analyses/lrc-repair-costs-locality/ (accessed 2026-10-11)

### Log-likelihood ratio

URL: https://hesela.dev/terms/log-likelihood-ratio/
Also known as: LLR
Status: shipping

A log-likelihood ratio is the logarithm of the relative likelihood of two alternatives, used in decoding to express a bit decision and its confidence.

Note: For the NAND convention log(P(bit=0 | observation) / P(bit=1 | observation)), a positive value favors zero; reversing the ratio reverses its sign.

Related terms:
- [ldpc](https://hesela.dev/terms/ldpc/)
- [soft-decision-decoding](https://hesela.dev/terms/soft-decision-decoding/)

Citations:
- [cai2017] Cai, Ghose, Haratsch, Luo and Mutlu. Error Characterization, Mitigation, and Recovery in Flash Memory Based Solid-State Drives. Author manuscript arXiv:1706.08642, 2017, sections 6.2-6.3.. https://arxiv.org/abs/1706.08642 (accessed 2026-10-11)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-11)

### Log sequence number

URL: https://hesela.dev/terms/log-sequence-number/
Also known as: LSN
Status: shipping

Record updated: 2026-10-16

A log sequence number identifies a position in an engine's ordered recovery-log address space.

Note: PostgreSQL represents an LSN as a byte offset in WAL. Insert, write and durable-flush positions have different meanings: knowing an LSN does not establish that its record is durable. In PostgreSQL, subtracting compatible positions gives bytes, not transaction count or elapsed time; retain the engine, timeline and observed progress stage when comparing positions. XFS instead encodes a 32-bit cycle and 32-bit block position; the latter counts 512-byte basic blocks. [xfs-design] [log-format] Raw encoded subtraction across cycles is not a byte-distance calculation.

Related terms:
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [replication-lag](https://hesela.dev/terms/replication-lag/)
- [synchronous-replication](https://hesela.dev/terms/synchronous-replication/)
- [asynchronous-replication](https://hesela.dev/terms/asynchronous-replication/)
- [compensation-log-record](https://hesela.dev/terms/compensation-log-record/)
- [page-lsn](https://hesela.dev/terms/page-lsn/)
- [xfs-relogging](https://hesela.dev/terms/xfs-relogging/)

Citations:
- [pg-internals] PostgreSQL 18: WAL Internals. https://www.postgresql.org/docs/18/wal-internals.html (accessed 2026-10-12)
- [pg-functions] PostgreSQL 18: Backup Control Functions, Table 9.97 and notes. https://www.postgresql.org/docs/18/functions-admin.html#FUNCTIONS-ADMIN-BACKUP (accessed 2026-10-12)
- [hesela-wal] WAL, checkpoints and torn pages: three different recovery guarantees. https://hesela.com/analyses/wal-checkpoints-torn-pages/ (accessed 2026-10-12)
- [pg-lsn] PostgreSQL 18: pg_lsn type. https://www.postgresql.org/docs/18/datatype-pg-lsn.html (accessed 2026-10-12)
- [pg-timelines] PostgreSQL 18: timeline history and recovery branches. https://www.postgresql.org/docs/18/continuous-archiving.html#BACKUP-TIMELINES (accessed 2026-10-12)
- [hesela-replication] Replication acknowledgements: received, durable, applied. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-12)
- [xfs-design] Linux v6.16: XFS Logging Design, log space accounting and re-logging. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-16)
- [log-format] Linux v6.16: xfs_log_format.h, CYCLE_LSN and BLOCK_LSN. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/libxfs/xfs_log_format.h (accessed 2026-10-16)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-16)

### Logical decoding

URL: https://hesela.dev/terms/logical-decoding/
Also known as: PostgreSQL logical decoding
Status: shipping

Record updated: 2026-10-16

Logical decoding reconstructs database changes from a storage-level log into a representation that a consumer can interpret without the database's physical storage format.

Note: PostgreSQL uses output plugins to translate WAL into change streams. A logical slot serves one database and has its own progress state. [pg-decoding] A disconnected slot can retain system-catalog row versions needed for decoding, so monitoring only retained WAL misses part of its resource footprint. [pg-decoding]

Limitations:
- After a crash, checkpointed slot progress can rewind and recent changes can be delivered again; consumers must prevent duplicate effects. (sources: [pg-decoding])

Related terms:
- [replication-slot](https://hesela.dev/terms/replication-slot/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)
- [idempotency](https://hesela.dev/terms/idempotency/)
- [failover-slot](https://hesela.dev/terms/failover-slot/)
- [hot-standby-feedback](https://hesela.dev/terms/hot-standby-feedback/)

Citations:
- [pg-decoding] PostgreSQL 18: logical decoding concepts and crash replay. https://www.postgresql.org/docs/18/logicaldecoding-explanation.html (accessed 2026-10-16)
- [hesela-replication] Hesela: Replication acknowledgements, retention and decoding. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-16)

### Logical journaling

URL: https://hesela.dev/terms/logical-journaling/
Status: shipping

Record updated: 2026-10-15

Logical journaling records recoverable changes to logical objects or operations rather than simply reproducing their on-disk representation.

Note: Linux's XFS design uses logical records for in-core inode and quota changes alongside physical buffer logging and intents; the categories can coexist. [xfs] A compact record does not by itself establish lower device traffic or correct interrupted recovery. [hesela]

Related terms:
- [physical-journaling](https://hesela.dev/terms/physical-journaling/)
- [ext4-fast-commit](https://hesela.dev/terms/ext4-fast-commit/)
- [journal-checkpoint](https://hesela.dev/terms/journal-checkpoint/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [xfs-delayed-logging](https://hesela.dev/terms/xfs-delayed-logging/)

Citations:
- [xfs] Linux v6.12: XFS Logging Design, introduction. https://github.com/torvalds/linux/blob/v6.12/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-15)
- [hesela] Hesela: journal representations and FastCommit cost audit. https://hesela.com/analyses/ext4-journal-replay-revocation/#journal-cost (accessed 2026-10-15)

### Logical sector

URL: https://hesela.dev/terms/logical-sector/
Also known as: logical block (storage)
Status: shipping

Record updated: 2026-10-12

A logical sector is the addressable data unit selected by a logical block address at a storage interface.

Note: Its size describes the addressed interface, not the application's write size. In 512e it is 512 bytes; in 4Kn it is 4096 bytes.

Advantages:
- Explicit logical-sector sizes let software interpret address and transfer units without assuming 512 bytes. (sources: [microsoft-buffering])

Limitations:
- The addressing unit can be smaller than the physical sector. (sources: [microsoft-buffering])

Related terms:
- [physical-sector](https://hesela.dev/terms/physical-sector/)
- [512e](https://hesela.dev/terms/512e/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)

Citations:
- [microsoft-buffering] Microsoft: File buffering, alignment and file access requirements. https://learn.microsoft.com/en-us/windows/win32/fileio/file-buffering (accessed 2026-10-12)
- [hesela-sector-alignment] Hesela: 512e, 4Kn and alignment: geometry is not durability. https://hesela.com/analyses/sector-sizes-alignment-not-durability/ (accessed 2026-10-12)

### Logical unit (LUN)

URL: https://hesela.dev/terms/logical-unit-number/
Status: shipping

A SCSI addressable block device presented by a target to initiators on a SAN.

Related terms:
- [san](https://hesela.dev/terms/san/)
- [scsi](https://hesela.dev/terms/scsi/)
- [block-storage](https://hesela.dev/terms/block-storage/)

Citations:
- [c1] Logical unit (LUN). https://en.wikipedia.org/wiki/Logical_unit_number (accessed 2026-03-26)

### Longitudinal magnetic recording

URL: https://hesela.dev/terms/longitudinal-recording/
Also known as: LMR
Status: eol

Recorded lastSeen: 2005 (sources: [c1])

Magnetic recording where bit magnetization lies in the plane of the disk, largely replaced by PMR for capacity.

Limitations:
- Areal density growth stalled as grain size approached superparamagnetic limits. (sources: [c1])

Related terms:
- [pmr](https://hesela.dev/terms/pmr/)
- [cmr](https://hesela.dev/terms/cmr/)

Superseded by:
- [pmr](https://hesela.dev/terms/pmr/)

Citations:
- [c1] Perpendicular recording. https://en.wikipedia.org/wiki/Perpendicular_recording (accessed 2026-03-26)

### Lost write

URL: https://hesela.dev/terms/lost-write/
Status: unknown

Record updated: 2026-10-11

A lost write is a write reported as completed whose intended update is absent at the required storage location.

Note: An old record can remain internally consistent, including its checksum; physical address agreement alone cannot establish freshness.

Related terms:
- [misdirected-write](https://hesela.dev/terms/misdirected-write/)
- [parity-pollution](https://hesela.dev/terms/parity-pollution/)
- [end-to-end-data-protection](https://hesela.dev/terms/end-to-end-data-protection/)

Citations:
- [parity] Krioukov et al. Parity Lost and Parity Regained. FAST 2008, sections 3-4.. https://www.usenix.org/legacy/event/fast08/tech/full_papers/krioukov/krioukov_html/index.html (accessed 2026-10-11)
- [field] Bairavasundaram et al. An Analysis of Data Corruption in the Storage Stack. FAST 2008, sections 2-3 and 6.. https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html (accessed 2026-10-11)
- [hesela-integrity] Hesela: checksum, identity and freshness boundaries with executable synthetic examples. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-11)

### Least recently used replacement

URL: https://hesela.dev/terms/lru-replacement/
Also known as: LRU, least recently used
Status: research

Record updated: 2026-10-15

Least recently used replacement evicts the resident entry whose most recent access is oldest.

Note: One-time scans can evict reusable entries. [car]

Related terms:
- [cache-pollution](https://hesela.dev/terms/cache-pollution/)
- [mapping-cache](https://hesela.dev/terms/mapping-cache/)
- [adaptive-replacement-cache](https://hesela.dev/terms/adaptive-replacement-cache/)

Citations:
- [car] Sorav Bansal and Dharmendra S. Modha. CAR: Clock with Adaptive Replacement. FAST 2004; sections III-V.. https://www.usenix.org/legacy/events/fast04/tech/full_papers/bansal/bansal.pdf (accessed 2026-10-15)
- [hesela] Hesela: mapping caches, scan phases and cache-history semantics (constructed examples). https://hesela.com/analyses/ssd-mapping-cache-hmb/#scan-pollution (accessed 2026-10-15)

### LSM tombstone

URL: https://hesela.dev/terms/lsm-tombstone/
Also known as: deletion marker, point tombstone
Status: shipping

Record updated: 2026-10-13

An LSM tombstone is a versioned deletion marker that suppresses older values for a key without immediately erasing their stored bytes.

Note: A marker can remain necessary while an older table still contains a value it hides; removing the marker alone can expose obsolete data. Snapshot visibility can also require retaining old versions. In Cassandra 5.0.0, a replica that missed a deletion can reintroduce an old value after other replicas purge the marker. Grace-period expiry permits removal only when compaction conditions also allow it. [tombstones]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [sstable](https://hesela.dev/terms/sstable/)
- [range-tombstone](https://hesela.dev/terms/range-tombstone/)
- [delete-persistence-latency](https://hesela.dev/terms/delete-persistence-latency/)
- [anti-entropy-repair](https://hesela.dev/terms/anti-entropy-repair/)

Citations:
- [leveldb] LevelDB project. Implementation: sorted tables and compaction.. https://github.com/google/leveldb/blob/main/doc/impl.md (accessed 2026-10-12)
- [snapshots] RocksDB project. Snapshot: sequence numbers, point-in-time reads and lifetime.. https://github.com/facebook/rocksdb/wiki/Snapshot (accessed 2026-10-12)
- [hesela] LSM tombstones: deleted is not yet reclaimed. https://hesela.com/analyses/lsm-tombstones-delete-persistence/ (accessed 2026-10-12)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)
- [tombstones] Apache Cassandra 5.0.0: Tombstones. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/managing/operating/compaction/tombstones.adoc (accessed 2026-10-13)

### Log-structured merge-tree

URL: https://hesela.dev/terms/lsm-tree/
Also known as: LSM-tree, LSM tree, log structured merge tree
Status: shipping

Record updated: 2026-10-14

A write-oriented index that buffers updates and merges sorted components over time, trading write batching against read and compaction work.

Note: In RocksDB leveled compaction, L0 files may overlap, while higher levels partition a sorted run across non-overlapping SST files. One file per level is not a faithful description.

Related terms:
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [sstable](https://hesela.dev/terms/sstable/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [lsm-tombstone](https://hesela.dev/terms/lsm-tombstone/)
- [key-value-separation](https://hesela.dev/terms/key-value-separation/)
- [compaction](https://hesela.dev/terms/compaction/)
- [leveled-compaction](https://hesela.dev/terms/leveled-compaction/)
- [tiered-compaction](https://hesela.dev/terms/tiered-compaction/)
- [read-amplification](https://hesela.dev/terms/read-amplification/)
- [space-amplification](https://hesela.dev/terms/space-amplification/)

Citations:
- [rocks-levels] RocksDB project. Leveled Compaction: sorted levels, SST files and overlapping L0. Documentation reviewed 12 October 2026.. https://github.com/facebook/rocksdb/wiki/Leveled-Compaction (accessed 2026-10-12)
- [leveldb] LevelDB project. Implementation: log files, sorted tables and compaction. Documentation reviewed 12 October 2026.. https://github.com/google/leveldb/blob/main/doc/impl.md (accessed 2026-10-12)
- [hesela] Hesela: Bloom filters and the cost of an absent LSM lookup. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-12)

### LTFS data placement policy

URL: https://hesela.dev/terms/ltfs-data-placement-policy/
Also known as: LTFS placement policy
Status: shipping

Record updated: 2026-10-15

An LTFS data placement policy specifies which file data may be stored in the index partition alongside filesystem metadata.

Note: IBM Spectrum Archive supports a file-size limit and optional filename patterns, applied together when both are specified. Its documentation illustrates placing selected small files in the index partition for faster access after mounting. This is a placement rule, not a second filesystem or a backup policy. The index partition has limited capacity; overly broad criteria can exhaust it. [c1]

Advantages:
- Selected small files can be made available with less tape positioning after mount. (sources: [c1])

Related terms:
- [ltfs](https://hesela.dev/terms/ltfs/)
- [ltfs-index](https://hesela.dev/terms/ltfs-index/)
- [lto](https://hesela.dev/terms/lto/)
- [tape](https://hesela.dev/terms/tape/)

Citations:
- [c1] IBM Spectrum Archive SDE and LE: Installation and Configuration Guide, formatting options and section 3.5.4. https://www.redbooks.ibm.com/redbooks/pdfs/sg248090.pdf (accessed 2026-10-15)

### LTFS index

URL: https://hesela.dev/terms/ltfs-index/
Also known as: LTFS XML index
Status: shipping

Record updated: 2026-10-15

An LTFS index is XML metadata describing files, directories and the mapping from file contents to recorded tape extents.

Note: A full index describes the volume; an incremental index records changes. Incremental indexes belong only in the data partition, whose final index must be full after clean unmount. [c1] IBM Storage Archive exposes earlier generations as rollback points. Keeping history preserves access to other generations; erase-history discards newer history, so rollback is not always reversible. [c2]

Limitations:
- An index records file locations, not an independent backup of the file payload. (sources: [c1])
- Older recovery tools that do not recognize incremental indexes can fail or lose newer changes on an inconsistent volume, even when clean-volume mounting works. (sources: [c1])

Related terms:
- [ltfs](https://hesela.dev/terms/ltfs/)
- [lto](https://hesela.dev/terms/lto/)
- [tape](https://hesela.dev/terms/tape/)
- [ltfs-data-placement-policy](https://hesela.dev/terms/ltfs-data-placement-policy/)
- [medium-auxiliary-memory](https://hesela.dev/terms/medium-auxiliary-memory/)

Citations:
- [c1] SNIA LTFS Format Specification 2.5.1, sections 5.2.3, 9.2 and Annex H. https://www.snia.org/sites/default/files/technical-work/ltfs/release/SNIA-LTFS-Format-2-5-1-Standard.pdf (accessed 2026-10-15)
- [c2] IBM Storage Archive SDE: Rolling back media. https://www.ibm.com/docs/en/storage-archive-sde/2.4.8?topic=tools-rolling-back-media (accessed 2026-10-15)

### LTFS

URL: https://hesela.dev/terms/ltfs/
Also known as: Linear Tape File System
Status: shipping

Record updated: 2026-10-15

Linear Tape File System is a self-describing tape format that stores files and directory metadata for interchange between compatible implementations.

Note: The index partition primarily holds indexes; the data partition holds file data and additional indexes. Index-partition file placement is policy-controlled. [c1] In IBM Storage Archive, updating a file appends replacement data, while deletion removes its index entry without reclaiming space. [c2] Previous index generations support rollback while their referenced data remains available; erasing rollback history removes access to newer generations. [c3]

Limitations:
- IBM documents independent tape replicas as a separate Enterprise Edition function, not an automatic consequence of using LTFS. (sources: [c4])

Related terms:
- [lto](https://hesela.dev/terms/lto/)
- [tape](https://hesela.dev/terms/tape/)
- [file-storage](https://hesela.dev/terms/file-storage/)
- [ltfs-index](https://hesela.dev/terms/ltfs-index/)
- [ltfs-data-placement-policy](https://hesela.dev/terms/ltfs-data-placement-policy/)
- [medium-auxiliary-memory](https://hesela.dev/terms/medium-auxiliary-memory/)

Citations:
- [c1] SNIA LTFS Format Specification 2.5.1, sections 4, 5 and 9.2.18. https://www.snia.org/sites/default/files/technical-work/ltfs/release/SNIA-LTFS-Format-2-5-1-Standard.pdf (accessed 2026-10-15)
- [c2] IBM Storage Archive LE 2.4.7: Overwriting or erasing a file. https://www.ibm.com/docs/en/storage-archive-le/2.4.7?topic=tips-overwriting-erasing-file (accessed 2026-10-15)
- [c3] IBM Storage Archive SDE: Rolling back media. https://www.ibm.com/docs/en/storage-archive-sde/2.4.8?topic=tools-rolling-back-media (accessed 2026-10-15)
- [c4] IBM Spectrum Archive Enterprise Edition V1.2.6, section 7.10.4: Replicas and redundant copies. https://www.redbooks.ibm.com/redbooks/pdfs/sg248445.pdf (accessed 2026-10-15)

### LTO (Linear Tape-Open)

URL: https://hesela.dev/terms/lto/
Also known as: LTO Ultrium
Status: shipping

Record updated: 2026-10-16

An open tape format standard for high-capacity cartridges, advanced by the LTO Program for backup and archive.

Note: Linear Tape-Open (LTO Ultrium) is a multi-vendor tape format governed by the LTO Program’s Technology Provider Companies—HPE, IBM, and Quantum—with licensed media and drive manufacturers. Each generation defines native capacity, transfer rate, and compatibility rules; products carry Ultrium verification marks after compliance testing. LTO-9 is widely cited at 18 TB native (45 TB at 2.5:1 compression) and 400 MB/s native transfer per LTO.org materials; LTO-10 specifications were introduced in 2025 with higher native capacities (program announcements list 30 TB and later 40 TB cartridge specs—verify the exact SKU matrix before quoting). Modern generations add encryption, WORM, and LTFS options. Backward read/write compatibility is generation-specific and must be checked per roadmap, not assumed.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [tapealert](https://hesela.dev/terms/tapealert/)
- [ltfs](https://hesela.dev/terms/ltfs/)
- [ltfs-index](https://hesela.dev/terms/ltfs-index/)
- [ltfs-data-placement-policy](https://hesela.dev/terms/ltfs-data-placement-policy/)
- [medium-auxiliary-memory](https://hesela.dev/terms/medium-auxiliary-memory/)
- [tape-filemark](https://hesela.dev/terms/tape-filemark/)
- [tape-buffer-synchronization](https://hesela.dev/terms/tape-buffer-synchronization/)

Citations:
- [c1] Linear Tape-Open. https://en.wikipedia.org/wiki/Linear_Tape-Open (accessed 2026-03-26)
- [n2] LTO Program — Trust LTO / program overview. https://www.lto.org/trustlto/ (accessed 2026-10-07)
- [n3] LTO Program — LTO-10 technology page. https://www.lto.org/lto-10/ (accessed 2026-10-07)
- [n4] LTO Program — Generation 10 introduction (Aug 2025). https://www.lto.org/2025/08/the-lto-program-introduces-generation-10-of-leading-tape-technology-delivering-unparalled-media-density/ (accessed 2026-10-07)
- [n5] LTO Program — Roadmap. https://www.lto.org/roadmap/ (accessed 2026-10-07)

### LUKS

URL: https://hesela.dev/terms/luks/
Also known as: Linux Unified Key Setup
Status: shipping

Record updated: 2026-10-15

LUKS is a disk-encryption format that records cryptographic parameters and key-management metadata, including keyslots used to unlock encrypted storage.

Note: LUKS names a format, not a cipher. A LUKS2 header alone does not establish authenticated encryption. [cryptsetup-source] A header backup and a passphrase valid for that backup may retain decryption access after the live keyslot is changed or removed, while the data still use the corresponding volume key. [luks-header]

Limitations:
- Recovery copies of the header/keyslots are security-sensitive, not harmless configuration exports. (sources: [luks-header])

Related terms:
- [dm-crypt](https://hesela.dev/terms/dm-crypt/)
- [xts-aes](https://hesela.dev/terms/xts-aes/)
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)
- [backup](https://hesela.dev/terms/backup/)
- [cryptographic-erase](https://hesela.dev/terms/cryptographic-erase/)

Citations:
- [cryptsetup-source] cryptsetup v2.8.1: LUKS extension and experimental authenticated disk encryption. https://gitlab.com/cryptsetup/cryptsetup/-/raw/v2.8.1/man/cryptsetup.8.adoc (accessed 2026-10-15)
- [luks-header] cryptsetup-luksHeaderBackup(8): header backups and retained decryption access. https://man7.org/linux/man-pages/man8/cryptsetup-luksHeaderBackup.8.html (accessed 2026-10-15)
- [hesela-encryption] Hesela: Encryption is not authentication. https://hesela.com/analyses/checksums-identity-and-lost-writes/#encryption-boundaries (accessed 2026-10-15)

### LVM

URL: https://hesela.dev/terms/lvm/
Also known as: Logical Volume Manager, LVM2
Status: shipping

The Linux Logical Volume Manager, a device-mapper framework that builds resizable virtual block devices (logical volumes) out of one or more physical disks or partitions.

Note: LVM groups physical volumes (PVs) into volume groups (VGs) and carves logical volumes (LVs) out of them; each block of an LV is stored on one or more PVs according to algorithms implemented by the kernel Device Mapper. Heinz Mauelshagen wrote the original code in 1998 while at Sistina Software, taking its main design guidelines from the HP-UX volume manager. Per Wikipedia, VGs and LVs can be resized online, LVs can be moved between PVs (pvmove, which uses a device-mapper mirror target), read-only snapshots exist in LVM1 and read/write snapshots in LVM2, thinly provisioned LVs can be allocated from a pool, and the dm-cache target lets fast devices such as SSDs cache slower HDDs. LVs can also be created with RAID 1, 5 and 6 layouts or striped like RAID 0. Allocation follows policies tried from strictest to most liberal (contiguous, cling, normal, anywhere), and for striped or mirrored LVs the restrictions apply to each leg independently. Each PV normally carries an ASCII metadata header in its first megabyte describing the whole volume group layout; Wikipedia notes that most setups keep only one copy per PV, that distributions usually keep a running backup in /etc/lvm/backup for restoring it with vgcfgrestore, and that as of 2015 no online or offline defragmentation program exists for LVM. In shared-storage clusters, concurrent metadata access needs extra locking (clvmd, HA-LVM or lvmlockd), and the filesystem on top must itself be cluster-aware or be mounted on only one node at a time. LVM is a layer of block-level indirection, not a data-protection mechanism by itself: redundancy exists only where a RAID or mirror LV type is used.

Advantages:
- Logical volumes and volume groups can be resized online, and LVs can be moved between physical volumes with pvmove
- Snapshots, thin provisioning and dm-cache SSD caching are available as logical volume types
- LVs can use RAID 1, 5 and 6 layouts or striping across multiple physical volumes
- Each physical volume header carries the volume group layout, which simplifies recovery if a PV is lost

Limitations:
- A plain linear or striped LV adds no redundancy; losing a physical volume can lose the volume group unless a RAID or mirror LV type is used
- Per Wikipedia, no defragmentation program existed for LVM as of 2015; fragmentation after expansion must be reduced by manually rearranging extents with pvmove
- Most setups keep a single metadata copy per PV, so a failed header sector depends on the backup in /etc/lvm/backup and vgcfgrestore
- Shared-storage use needs extra locking (clvmd, HA-LVM or lvmlockd), and the filesystem on top must be cluster-aware or mounted on one node at a time

Related terms:
- [volume-manager](https://hesela.dev/terms/volume-manager/)
- [storage-virtualization](https://hesela.dev/terms/storage-virtualization/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [raid](https://hesela.dev/terms/raid/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [raid-6](https://hesela.dev/terms/raid-6/)
- [striping](https://hesela.dev/terms/striping/)
- [jbod](https://hesela.dev/terms/jbod/)
- [mirroring](https://hesela.dev/terms/mirroring/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [block-storage](https://hesela.dev/terms/block-storage/)

Citations:
- [c1] Logical Volume Manager (Linux) — Wikipedia. https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux) (accessed 2026-10-11)
- [c2] lvm(8) — LVM2 tools (Debian bookworm manpages). https://manpages.debian.org/bookworm/lvm2/lvm.8.en.html (accessed 2026-10-11)

### M-DISC

URL: https://hesela.dev/terms/m-disc/
Status: limited

Record updated: 2026-10-15

M-DISC is a family of write-once optical media marketed for archival storage using an inorganic recording layer.

Note: Inorganic BD-R is not exclusive to M-DISC [mdiscfaq]. DVD writing support and Blu-ray/BDXL compatibility must be checked separately. NIST's grouped longevity entry is guidance, not a product survival curve [nist8387]. Its cited LNE study tested DVD under severe heat and humidity, not Blu-ray shelf life [lne2012]. Vendor lifetime projections and warranties are different claims [verbatim].

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [blu-ray-archive](https://hesela.dev/terms/blu-ray-archive/)
- [bd-r-htl](https://hesela.dev/terms/bd-r-htl/)
- [bd-r-lth](https://hesela.dev/terms/bd-r-lth/)
- [optical-disc-lifetime-estimate](https://hesela.dev/terms/optical-disc-lifetime-estimate/)

Citations:
- [mdiscfaq] Millenniata M-DISC FAQ: format-specific writing compatibility and inorganic BD-R, manufacturer explanation.. https://www.mdisc.com/faq.html (accessed 2026-10-15)
- [nist8387] NIST IR 8387 (2022), Digital Evidence Preservation: Considerations for Evidence Handlers, Table 1 and Perdereau reference.. https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8387.pdf (accessed 2026-10-15)
- [lne2012] Jacques Perdereau, LNE (June 2012). Durability of recordable DVD and glass DVD at elevated temperature and humidity, sections 2.3, 3.2, 4 and 5.3.. https://www.lne.fr/sites/default/files/inline-files/syylex-glass-dvd-accelerated-aging-report.pdf (accessed 2026-10-15)
- [verbatim] Verbatim M-DISC BDXL 100GB, product 98912: projected lifetime and warranty, manufacturer claims.. https://www.verbatim.com/en/m-disc/products/98912-m-disc-bdxl-100gb-6x-with-branded-surface-1pk-jewel-case?country=US (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates and format-specific evidence. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### M.2

URL: https://hesela.dev/terms/m2/
Also known as: NGFF, M.2 SSD
Status: shipping

A small form-factor card standard commonly used for NVMe and SATA SSDs in laptops and desktops.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [sata](https://hesela.dev/terms/sata/)
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [sd-express](https://hesela.dev/terms/sd-express/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] M.2. https://en.wikipedia.org/wiki/M.2 (accessed 2026-03-26)

### Magneto-optical disc

URL: https://hesela.dev/terms/magneto-optical/
Status: eol

Optical-magnetic media written with a laser and magnetic field, used for archival and removable storage.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [tape](https://hesela.dev/terms/tape/)

Citations:
- [c1] Magneto-optical disc. https://en.wikipedia.org/wiki/Magneto-optical_drive (accessed 2026-03-26)

### Mainframe DASD

URL: https://hesela.dev/terms/mainframe-dasd/
Status: limited

Direct-access storage devices attached to IBM Z systems, historically count-key-data disks.

Related terms:
- [san](https://hesela.dev/terms/san/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)

Citations:
- [c1] Mainframe DASD. https://en.wikipedia.org/wiki/Direct-access_storage_device (accessed 2026-03-26)

### Microwave-assisted magnetic recording (MAMR)

URL: https://hesela.dev/terms/mamr/
Also known as: MAMR
Status: limited

Record updated: 2026-10-16

Microwave-assisted magnetic recording (MAMR) denotes HDD write-assist approaches whose implementation must be distinguished: MAS-MAMR uses a microwave magnetic field to assist switching in the medium, while Toshiba's FC-MAMR strengthens the write field through flux control.

Note: Toshiba distinguishes assistance to the head's write field in FC-MAMR from microwave-assisted reversal of media magnetization in MAS-MAMR [toshiba-mg09-2021]. Western Digital's ePMR is a separate DC-biased write-pole approach, not a synonym for MAMR; write assistance is also a different classification from CMR or SMR track layout [wd-recording-technologies].

Limitations:
- The family label alone does not identify the implemented assist mechanism.

Related terms:
- [hamr](https://hesela.dev/terms/hamr/)
- [pmr](https://hesela.dev/terms/pmr/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [areal-density](https://hesela.dev/terms/areal-density/)
- [fc-mamr](https://hesela.dev/terms/fc-mamr/)
- [mas-mamr](https://hesela.dev/terms/mas-mamr/)
- [epmr](https://hesela.dev/terms/epmr/)

Citations:
- [toshiba-mg09-2021] Toshiba: High-Reliability FC-MAMR Nearline HDD with a Capacity of 18 TB (2021), pp. 1-2. https://toshiba.semicon-storage.com/content/dam/toshiba-ss-v3/master/en/storage/product/data-center-enterprise/202102025_nearlineHDD_18TB_e.pdf (accessed 2026-10-16)
- [wd-recording-technologies] Western Digital: Recording Technologies, pp. 3-5. https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/tech-brief/tech-brief-recording-technologies.pdf (accessed 2026-10-16)

### MAP_SYNC

URL: https://hesela.dev/terms/map-sync/
Status: shipping

Record updated: 2026-10-13

MAP_SYNC is a Linux mmap flag for supported DAX files that provides a file-offset persistence guarantee used with appropriate CPU persistence instructions.

Note: The flag must be requested with MAP_SHARED_VALIDATE: MAP_SHARED can silently ignore it, and files without support fail with EOPNOTSUPP. It does not itself issue a persistence operation for every store. [mmap-docs] The application still needs a correct durability and recovery protocol; a mapping contract is not multi-write atomicity. [pmdk-persist]

Related terms:
- [dax](https://hesela.dev/terms/dax/)
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)

Citations:
- [mmap-docs] Linux man-pages. mmap(2), MAP_SYNC and MAP_SHARED_VALIDATE.. https://man7.org/linux/man-pages/man2/mmap.2.html (accessed 2026-10-13)
- [pmdk-persist] PMDK 1.13.1. pmem2_get_persist_fn(3): early persistence and non-transactional semantics.. https://github.com/pmem/pmdk/blob/1.13.1/doc/libpmem2/pmem2_get_persist_fn.3.md (accessed 2026-10-13)
- [hesela-pmem] Hesela. Persistent memory: DAX is not a durable commit.. https://hesela.com/analyses/pmem-persistence-domains-dax/ (accessed 2026-10-13)

### SSD mapping cache

URL: https://hesela.dev/terms/mapping-cache/
Also known as: cached mapping table, CMT
Status: shipping

Record updated: 2026-10-15

An SSD mapping cache retains selected logical-to-physical address mappings in memory.

Note: This stores locations rather than necessarily caching user data. Capacity alone does not establish the hit ratio; access history and the replacement rule matter. The linked example reports cold, scan and return phases separately, without inferring retail firmware behavior. [hesela]

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [dram-cache-ssd](https://hesela.dev/terms/dram-cache-ssd/)
- [hmb](https://hesela.dev/terms/hmb/)
- [translation-page](https://hesela.dev/terms/translation-page/)
- [lru-replacement](https://hesela.dev/terms/lru-replacement/)
- [cache-pollution](https://hesela.dev/terms/cache-pollution/)

Citations:
- [learned] Shengzhe Wang, Zihang Lin, Suzhen Wu, Hong Jiang, Jie Zhang and Bo Mao. LearnedFTL: A Learning-Based Page-Level FTL for Reducing Double Reads in Flash-Based SSDs. HPCA 2024, pp. 616-629, sections II-IV; DOI 10.1109/HPCA57654.2024.00054.. https://ranger.uta.edu/~jiang/publication/Conferences/2024/HPCA24%28LearnedFTL%29.pdf (accessed 2026-10-12)
- [hesela] SSD mapping caches: why DRAM size is not a speed rating. https://hesela.com/analyses/ssd-mapping-cache-hmb/ (accessed 2026-10-12)

### Microwave-assisted switching MAMR (MAS-MAMR)

URL: https://hesela.dev/terms/mas-mamr/
Also known as: MAS-MAMR, Microwave Assisted Switching MAMR
Status: research

Record updated: 2026-10-16

Microwave-assisted switching MAMR (MAS-MAMR) is a recording technique in which a spin-torque oscillator adds a microwave magnetic field to the write field, reducing the field needed to reverse magnetization in the recording medium.

Note: The mechanism assists media switching rather than only strengthening the head's write field [toshiba-mg09-2021]. Toshiba reported a head-and-media demonstration on 27 December 2021 [toshiba-mas-demo-2021] and still described MAS-MAMR development on 22 January 2026 [toshiba-mas-research-2026]. The research status reflects those dated sources, not a complete October 2026 market audit; neither source establishes universal commercial availability. The associated paper distinguishes coupled and uncoupled oscillator modes using a resistance response to external microwave excitation, with simulations supporting the interpretation [nakagawa-injection-locking-2026]. An absent response is not a universal coupling test.

Limitations:
- Results from a specific head-and-media demonstration do not establish performance for every HDD.

Related terms:
- [mamr](https://hesela.dev/terms/mamr/)
- [fc-mamr](https://hesela.dev/terms/fc-mamr/)
- [epmr](https://hesela.dev/terms/epmr/)
- [pmr](https://hesela.dev/terms/pmr/)

Citations:
- [toshiba-mg09-2021] Toshiba: High-Reliability FC-MAMR Nearline HDD with a Capacity of 18 TB (2021), p. 2. https://toshiba.semicon-storage.com/content/dam/toshiba-ss-v3/master/en/storage/product/data-center-enterprise/202102025_nearlineHDD_18TB_e.pdf#page=2 (accessed 2026-10-16)
- [toshiba-mas-demo-2021] Toshiba: Demonstration of improved HDD recording performance with MAS-MAMR (27 December 2021). https://www.global.toshiba/ww/technology/corporate/rdc/rd/topics/21/2112-03.html (accessed 2026-10-16)
- [toshiba-mas-research-2026] Toshiba: Analysis method for determining the oscillation state of STOs for MAS-MAMR (22 January 2026). https://www.global.toshiba/ww/technology/corporate/rdc/rd/topics/26/2601-01.html (accessed 2026-10-16)
- [nakagawa-injection-locking-2026] Nakagawa, Suto, Sakuraba and Maeda: Determination of coupling state within a spin-torque oscillator using injection locking, Communications Physics 9, 17 (2026), doi:10.1038/s42005-025-02469-4. https://www.nature.com/articles/s42005-025-02469-4 (accessed 2026-10-16)

### Maximum distance separable code

URL: https://hesela.dev/terms/maximum-distance-separable-code/
Also known as: MDS code
Status: shipping

Record updated: 2026-10-15

A maximum distance separable code achieves minimum distance n - k + 1 for length n and dimension k, allowing recovery from any n - k known symbol erasures.

Note: Recovery assumes correct surviving symbols and known positions; MDS does not describe their physical placement or integrity validation. See the systematic Reed-Solomon construction and erasure-channel contract in RFC 5510. [rfc5510] The executable error/erasure supplement distinguishes known missing positions from unknown wrong values and demonstrates ambiguous recovery and a unique wrong result after false identification. [hesela-errors]

Limitations:
- The any-subset guarantee is conditional on the actual code construction, not merely its redundancy count.

Related terms:
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [systematic-code](https://hesela.dev/terms/systematic-code/)
- [locally-repairable-code](https://hesela.dev/terms/locally-repairable-code/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [symbol-erasure](https://hesela.dev/terms/symbol-erasure/)
- [error-and-erasure-decoding](https://hesela.dev/terms/error-and-erasure-decoding/)

Citations:
- [rfc5510] Lacan, Roca, Peltotalo and Peltotalo. RFC 5510 (2009), sections 3.1, 8.2-8.4: systematic encoding and the erasure-channel assumption.. https://www.rfc-editor.org/rfc/rfc5510.html (accessed 2026-10-13)
- [fast2009] Plank, Luo, Schuman, Xu and Wilcox-O'Hearn. A Performance Evaluation and Examination of Open-Source Erasure Coding Libraries For Storage. FAST 2009, sections 2, 4-7.. https://static.usenix.org/events/fast09/tech/full_papers/plank/plank_html/ (accessed 2026-10-13)
- [forney] G. David Forney. Principles of Digital Communication II, MIT 6.451 (2005), section 6.5.3: bounded-distance erasure-and-error correction.. https://ocw.mit.edu/courses/6-451-principles-of-digital-communication-ii-spring-2005/bb895c1dee9ce0b39d6846e0aa984981_MIT6_451S05_FullLecNotes.pdf (accessed 2026-10-15)
- [hesela-errors] Hesela: exact GF(7) errors-and-erasures examples, including an ambiguous observation and false-identification negative control.. https://hesela.com/analyses/reed-solomon-matrix-recovery-guarantees/#errors-erasures (accessed 2026-10-15)

### Mean time to data loss (MTTDL)

URL: https://hesela.dev/terms/mean-time-to-data-loss/
Also known as: MTTDL
Status: research

Record updated: 2026-10-15

Mean time to data loss (MTTDL) is the expected time until a storage system first loses data that cannot be retrieved or reconstructed.

Note: MTTDL integrates the no-loss survival probability over an unbounded horizon; it is not a finite-mission loss probability or a measure of loss size. [greenan-hotstorage10-pdf]

Related terms:
- [normalized-magnitude-data-loss](https://hesela.dev/terms/normalized-magnitude-data-loss/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [mtbf](https://hesela.dev/terms/mtbf/)

Citations:
- [greenan-hotstorage10-pdf] Mean time to meaningless: MTTDL, Markov models, and storage system reliability, Greenan, Plank, and Wylie, USENIX HotStorage 2010 (USENIX PDF, independent academic source). https://www.usenix.org/legacy/event/hotstorage10/tech/full_papers/Greenan.pdf (accessed 2026-10-15)
- [hesela-durability] Eleven nines: what a durability model does not prove. https://hesela.com/analyses/s3-durability-eleven-nines-derivation/ (accessed 2026-10-15)

### Mean time to detection

URL: https://hesela.dev/terms/mean-time-to-detection/
Also known as: MTTD
Status: shipping

Record updated: 2026-10-15

Mean time to detection is the arithmetic mean of elapsed times between event occurrence and detection for a specified event population.

Note: Define the event, timestamp origin and handling of undetected events. A detection timestamp alone does not reveal when a latent error began. Averaging only detected events can omit the longest delays; report censoring or the model used for unknown onset. This metric does not include subsequent repair. A baseline/adaptive MTTD ratio G gives fractional time reduction 1 - 1/G, not G - 1. [hesela-budget] The ATC 2017 scrub simulation evaluates mean detection delay. [mahdisoltani2017]

Related terms:
- [latent-sector-error](https://hesela.dev/terms/latent-sector-error/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [adaptive-scrubbing](https://hesela.dev/terms/adaptive-scrubbing/)
- [right-censoring](https://hesela.dev/terms/right-censoring/)

Citations:
- [mahdisoltani2017] Mahdisoltani, Stefanovici and Schroeder. Improving Storage System Reliability with Proactive Error Prediction. USENIX ATC 2017, sections 4.1-4.3.. https://www.usenix.org/system/files/conference/atc17/atc17-mahdisoltani.pdf (accessed 2026-10-15)
- [hesela-budget] Hesela: sector-error prediction and adaptive scrub-budget arithmetic.. https://hesela.com/analyses/sector-error-prediction-scrubbing/ (accessed 2026-10-15)

### Medium Auxiliary Memory

URL: https://hesela.dev/terms/medium-auxiliary-memory/
Also known as: MAM
Status: shipping

Record updated: 2026-10-15

Medium Auxiliary Memory is nonvolatile storage associated with an individual storage medium, used to hold auxiliary attributes about the medium and its recorded data.

Note: LTFS uses MAM attributes for identification and consistency checks, including index generation and location. This is separate from the on-tape XML index; inaccessible or stale MAM does not inherently prevent reading the volume. [c1] IBM exposes attributes for the formatting application and cartridge barcode, illustrating the distinction between cartridge metadata and stored file contents. [c2]

Advantages:
- Coherency metadata can avoid seeking to both partition ends during consistency checks. (sources: [c1])

Limitations:
- If a partition's stored Volume Change Reference is stale, MAM coherency attributes alone cannot establish volume consistency; the on-tape indexes must be checked. (sources: [c1])

Related terms:
- [ltfs](https://hesela.dev/terms/ltfs/)
- [ltfs-index](https://hesela.dev/terms/ltfs-index/)
- [lto](https://hesela.dev/terms/lto/)
- [tape](https://hesela.dev/terms/tape/)

Citations:
- [c1] SNIA LTFS Format Specification 2.5.1, sections 4.1.21 and 10. https://www.snia.org/sites/default/files/technical-work/ltfs/release/SNIA-LTFS-Format-2-5-1-Standard.pdf (accessed 2026-10-15)
- [c2] IBM Storage Archive SDE: Virtual extended attributes, volume metadata. https://www.ibm.com/docs/en/storage-archive-sde/2.4.8?topic=attributes-virtual-extended (accessed 2026-10-15)

### Memristor storage

URL: https://hesela.dev/terms/memristor/
Status: research

Resistive switching devices researched as dense memory; not mainstream datacenter bulk storage.

Related terms:
- [phase-change-memory](https://hesela.dev/terms/phase-change-memory/)

Citations:
- [c1] Memristor storage. https://en.wikipedia.org/wiki/Memristor (accessed 2026-03-26)

### Memtable

URL: https://hesela.dev/terms/memtable/
Also known as: in-memory write buffer (LSM)
Status: shipping

Record updated: 2026-10-15

A memtable is an in-memory structure that holds recent LSM-tree updates before they are flushed to sorted table files.

Note: RocksDB's FAST 2021 architecture description separates the memtable from its recovery WAL and persistent SST files. A memtable flush and an SST compaction are different operations. [dong2021] Do not infer a power-loss guarantee from the in-memory structure's name; the logging and acknowledgment policy must also be specified. In RocksDB, accumulated immutable memtables waiting for flush can trigger write backpressure; this is distinct from the amount of SST compaction work. [stall-code]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [sstable](https://hesela.dev/terms/sstable/)
- [compaction](https://hesela.dev/terms/compaction/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [rocksdb-column-family](https://hesela.dev/terms/rocksdb-column-family/)
- [rocksdb-write-stall](https://hesela.dev/terms/rocksdb-write-stall/)

Citations:
- [dong2021] Siying Dong, Andrew Kryczka, Yanqin Jin and Michael Stumm. Evolution of Development Priorities in Key-value Stores Serving Large-scale Applications: The RocksDB Experience. FAST 2021, pp. 33-49; sections 2.2 and 4.. https://www.usenix.org/system/files/fast21-dong.pdf (accessed 2026-10-14)
- [hesela] RocksDB: a WAL sync is not a memtable flush. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/ (accessed 2026-10-14)
- [stall-code] RocksDB v10.10.1. ColumnFamilyData::GetWriteStallConditionAndCause.. https://github.com/facebook/rocksdb/blob/v10.10.1/db/column_family.cc#L986 (accessed 2026-10-15)

### Merkle tree

URL: https://hesela.dev/terms/merkle-tree/
Also known as: Hash tree
Status: shipping

Record updated: 2026-10-16

A Merkle tree combines hashes of data and child nodes into a root so that selected entries or subtrees can be checked without transferring the entire data set.

Note: Dynamo's 2007 design uses per-key-range trees to locate divergent replicas. [dynamo2007] For inclusion verification, use the intended trusted root and the construction's encoding, ordering and tree-shape rules. RFC 9162 specifies distinct leaf and internal-node prefixes and includes tree size and leaf index in proof verification; that is one construction, not a universal storage format. [rfc9162]

Limitations:
- A proof relative to a root does not by itself establish freshness, data availability or which divergent replica is authoritative. (sources: [rfc9162], [dynamo2007])
- A Merkle tree does not reconstruct missing data; replica synchronization still needs the relevant data and reconciliation rules. (sources: [dynamo2007])

Related terms:
- [cryptographic-hash](https://hesela.dev/terms/cryptographic-hash/)
- [hash-collision](https://hesela.dev/terms/hash-collision/)
- [checksum](https://hesela.dev/terms/checksum/)
- [end-to-end-data-protection](https://hesela.dev/terms/end-to-end-data-protection/)
- [anti-entropy-repair](https://hesela.dev/terms/anti-entropy-repair/)
- [dm-verity](https://hesela.dev/terms/dm-verity/)
- [fs-verity](https://hesela.dev/terms/fs-verity/)
- [set-reconciliation](https://hesela.dev/terms/set-reconciliation/)

Citations:
- [dynamo2007] DeCandia et al. Dynamo: Amazon's Highly Available Key-value Store. SOSP 2007, section 4.7.. https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf (accessed 2026-10-12)
- [rfc9162] RFC 9162: Certificate Transparency Version 2.0, sections 2.1 and 4.9-4.12. https://www.rfc-editor.org/rfc/rfc9162.html (accessed 2026-10-12)
- [hesela-integrity] Hesela: Why a valid checksum can still return the wrong data. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-12)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### Metadata update dependency

URL: https://hesela.dev/terms/metadata-update-dependency/
Status: shipping

Record updated: 2026-10-15

A metadata update dependency is an ordering requirement between persistent changes needed to preserve a filesystem invariant.

Note: Ordering changes and recording recovery information are different consistency strategies. [compare2000]

Limitations:
- An ordering constraint does not itself provide atomicity for an entire application transaction. (sources: [compare2000])

Related terms:
- [soft-updates](https://hesela.dev/terms/soft-updates/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [filesystem-consistency-invariant](https://hesela.dev/terms/filesystem-consistency-invariant/)

Citations:
- [compare2000] Seltzer, Ganger, McKusick, Smith, Soules and Stein. Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems. USENIX ATC 2000, pp. 71-84.. https://www.usenix.org/legacy/event/usenix2000/general/full_papers/seltzer/seltzer_html/ (accessed 2026-10-15)
- [hesela-soft] Hesela: Soft updates and metadata ordering. https://hesela.com/analyses/soft-updates-metadata-ordering/ (accessed 2026-10-15)

### Metal particle tape

URL: https://hesela.dev/terms/metal-particle-tape/
Status: eol

Earlier tape coatings using magnetic metal particles before barium ferrite advances.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)

Citations:
- [c1] Metal particle tape. https://en.wikipedia.org/wiki/Magnetic_tape (accessed 2026-03-26)

### Mirror set

URL: https://hesela.dev/terms/mirror-set/
Also known as: Mirror group, Mirrored set
Status: shipping

Record updated: 2026-10-15

A mirror set is a group of storage members configured to maintain copies of the same logical data.

Note: OpenZFS permits mirrors with two or more members: an N-member mirror can retain its data after N-1 complete member failures when the remaining copy is current and readable. Multiple top-level data mirrors hold different portions of a pool; they are not copies of the entire pool. [zconcepts23] A set is a redundancy group, whereas a failure domain identifies a shared cause of unavailability. The fixed-pair example counts failure sets that remove every copy from at least one pair; it does not estimate real failure rates. [hesela-mirror-topology]

Limitations:
- A configured but unsynchronized replacement does not yet provide a complete current copy. (sources: [zattach23])

Related terms:
- [mirroring](https://hesela.dev/terms/mirroring/)
- [raid-10](https://hesela.dev/terms/raid-10/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [resilver](https://hesela.dev/terms/resilver/)

Citations:
- [zconcepts23] OpenZFS 2.3: zpoolconcepts(7), mirror virtual devices. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpoolconcepts.7.html (accessed 2026-10-15)
- [zattach23] OpenZFS 2.3: zpool-attach(8), redundancy after resilver. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-attach.8.html (accessed 2026-10-15)
- [hesela-mirror-topology] Hesela: RAID 10 mirror topology and exact failure-set counts. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#mirror-topology-heading (accessed 2026-10-15)

### Mirroring (storage)

URL: https://hesela.dev/terms/mirroring/
Status: shipping

Record updated: 2026-10-15

Storage mirroring maintains a copy of source data on another storage device or system.

Note: Mirroring describes a maintained-copy relationship, not an unconditional promise of instantaneous failover. The acknowledgement policy determines how far an update must progress before success is reported. Failover additionally depends on failure detection, replica eligibility and preventing conflicting writers. DRBD illustrates different completion boundaries for replicated block writes; those are not database query-visibility guarantees. A mirror set is one local redundancy group, not necessarily a full copy of a striped array or pool. The RAID10 example explains why the positions of failed members matter. [hesela-mirror-topology]

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [synchronous-replication](https://hesela.dev/terms/synchronous-replication/)
- [asynchronous-replication](https://hesela.dev/terms/asynchronous-replication/)
- [replication-lag](https://hesela.dev/terms/replication-lag/)
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [mirror-set](https://hesela.dev/terms/mirror-set/)
- [raid-10](https://hesela.dev/terms/raid-10/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Mirroring (storage). https://en.wikipedia.org/wiki/RAID (accessed 2026-03-26)
- [snia-mirror] SNIA Swordfish 1.2.8: ReplicaType Mirror. https://www.snia.org/sites/default/files/technical-work/swordfish/release/v1.2.8/html/Specification/Swordfish_v1.2.8_Specification.html (accessed 2026-10-12)
- [drbd] LINBIT DRBD 9 guide: section 2.3, replication modes. https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/ (accessed 2026-10-12)
- [hesela-replication] Replication acknowledgements: received, durable, applied. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-12)
- [hesela-mirror-topology] Hesela: RAID 10 mirror topology and exact failure-set counts. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#mirror-topology-heading (accessed 2026-10-15)

### Misdirected write

URL: https://hesela.dev/terms/misdirected-write/
Status: unknown

Record updated: 2026-10-11

A misdirected write stores an update at the wrong address or on the wrong device.

Note: The original destination may remain stale while another location is overwritten; a valid checksum does not by itself bind returned data to the requested location.

Related terms:
- [lost-write](https://hesela.dev/terms/lost-write/)
- [protection-information](https://hesela.dev/terms/protection-information/)
- [parity-pollution](https://hesela.dev/terms/parity-pollution/)

Citations:
- [field] Bairavasundaram et al. An Analysis of Data Corruption in the Storage Stack. FAST 2008, sections 2-3 and 6.. https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html (accessed 2026-10-11)
- [hesela-integrity] Hesela: checksum, identity and freshness boundaries with executable synthetic examples. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-11)

### Mission-critical HDD

URL: https://hesela.dev/terms/mission-critical-hdd/
Status: limited

High-RPM enterprise HDDs for transactional workloads before flash adoption.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] Mission-critical HDD. https://en.wikipedia.org/wiki/Hard_disk_drive (accessed 2026-03-26)

### MLC SSD

URL: https://hesela.dev/terms/mlc-ssd/
Status: eol

SSDs using two-bit-per-cell NAND, now largely replaced by TLC in consumer lines.

Related terms:
- [mlc](https://hesela.dev/terms/mlc/)
- [tlc](https://hesela.dev/terms/tlc/)

Citations:
- [c1] MLC SSD. https://en.wikipedia.org/wiki/Multi-level_cell (accessed 2026-03-26)

### Multi-level cell (MLC)

URL: https://hesela.dev/terms/mlc/
Also known as: 2 bits per cell
Status: limited

NAND flash that stores two bits per cell using four distinguishable threshold-voltage states.

Note: This glossary uses MLC in the two-bit sense; TLC and QLC have separate entries. Bits per cell describe the encoding density, not whether the device uses floating-gate or charge-trap storage. Lower and upper pages can share cells, so programming and protection must be interpreted at the physical-page level rather than inferred from host addresses.

Related terms:
- [slc](https://hesela.dev/terms/slc/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [nand-page-pairing](https://hesela.dev/terms/nand-page-pairing/)
- [program-interference](https://hesela.dev/terms/program-interference/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Supersedes:
- [slc](https://hesela.dev/terms/slc/)

Superseded by:
- [tlc](https://hesela.dev/terms/tlc/)

Citations:
- [c1] Multi-level cell. https://en.wikipedia.org/wiki/Multi-level_cell (accessed 2026-03-26)
- [n2] Samsung — Evaluating MLC vs TLC vs V-NAND. https://s7d2.scene7.com/is/content/SamsungUS/b2b/resource/2015/11/25/WHP-SSD-MLCvsTLC-OCT15J_1.pdf (accessed 2026-10-07)
- [n3] Micron — NAND flash. https://www.micron.com/products/storage/nand-flash (accessed 2026-10-07)
- [linux] Linux v6.12, include/linux/mtd/mtd.h: mtd_pairing_info and mtd_pairing_scheme. https://github.com/torvalds/linux/blob/v6.12/include/linux/mtd/mtd.h (accessed 2026-10-11)
- [cai] Cai, Ghose, Luo, Mai, Mutlu and Haratsch. Vulnerabilities in MLC NAND Flash Memory Programming: Experimental Analysis, Exploits, and Mitigation Techniques. HPCA 2017, sections 2-4 and 6. DOI: 10.1109/HPCA.2017.61. https://research.ece.cmu.edu/safari/pubs/flash-memory-programming-vulnerabilities_hpca17.pdf (accessed 2026-10-11)
- [hesela-pairing] Hesela: NAND paired pages and durability boundaries. https://hesela.com/analyses/nand-paired-pages-durability/ (accessed 2026-10-11)

### Monotonic reads

URL: https://hesela.dev/terms/monotonic-reads/
Also known as: Monotonic-read consistency
Status: shipping

Record updated: 2026-10-13

Monotonic reads is a session guarantee requiring successive reads to observe states that include the effects of writes relevant to the session's earlier reads.

Note: Changing replicas must not make the session lose previously observed write effects. Values themselves need not increase numerically: a later valid update may decrease a counter. Monotonic reads does not alone require the freshest global state or visibility of the session's own writes that have not yet been read; read-your-writes is a separate guarantee.

Related terms:
- [linearizability](https://hesela.dev/terms/linearizability/)
- [read-your-writes](https://hesela.dev/terms/read-your-writes/)
- [session-guarantees](https://hesela.dev/terms/session-guarantees/)

Citations:
- [session-guarantees] Douglas B. Terry et al. Session Guarantees for Weakly Consistent Replicated Data. PDIS 1994, sections 3.1 and 3.2.. https://classes.cs.uchicago.edu/archive/2026/spring/23380-1/papers/terry_sessionguarantees.pdf (accessed 2026-10-12)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-12)

### Monotonic writes

URL: https://hesela.dev/terms/monotonic-writes/
Also known as: Monotonic-write consistency, MW session guarantee
Status: shipping

Record updated: 2026-10-13

Monotonic writes requires every replica incorporating a later session write to incorporate the session's earlier writes and order them before it.

Note: This is write ordering, not increasing numeric values. MongoDB's causal-session documentation allows unrelated writes to interleave; one thread must use the session at a time. Its documented majority read and write concerns provide all four causal guarantees with durability; weaker configurations require separate analysis.

Related terms:
- [session-guarantees](https://hesela.dev/terms/session-guarantees/)
- [writes-follow-reads](https://hesela.dev/terms/writes-follow-reads/)

Citations:
- [session-guarantees] Douglas B. Terry et al. Session Guarantees for Weakly Consistent Replicated Data. PDIS 1994, sections 3.1-3.4, pp. 142-144.. https://classes.cs.uchicago.edu/archive/2026/spring/23380-1/papers/terry_sessionguarantees.pdf (accessed 2026-10-13)
- [mongodb-sessions] MongoDB Manual: Read Isolation, Consistency, and Recency; client sessions, causal guarantees and isolation.. https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency/ (accessed 2026-10-13)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-13)
- [mongodb-concerns] MongoDB Manual: Causal Consistency and Read and Write Concerns; durability and rollback distinctions.. https://www.mongodb.com/docs/manual/core/causal-consistency-read-write-concerns/ (accessed 2026-10-13)

### msync

URL: https://hesela.dev/terms/msync/
Also known as: msync()
Status: shipping

Record updated: 2026-10-13

msync is an operation that synchronizes a range of a shared file-backed memory mapping with its underlying file, with MS_SYNC waiting for completion.

Note: On Linux, MS_ASYNC has been a no-op since 2.6.19 because dirty-page tracking already drives writeback; it is not a durability completion point. MAP_PRIVATE modifications do not update the backing file. MS_SYNC is not the distinct MAP_SYNC mapping flag used with DAX-capable files.

Advantages:
- Provides explicit synchronization for a selected mapped range.

Limitations:
- The starting address must be page-aligned; portable callers specify exactly one of MS_SYNC and MS_ASYNC.
- Does not make private mapping changes persistent or provide an atomic application transaction.

Related terms:
- [fsync](https://hesela.dev/terms/fsync/)
- [fdatasync](https://hesela.dev/terms/fdatasync/)
- [sync-file-range](https://hesela.dev/terms/sync-file-range/)

Citations:
- [msync-api] Linux man-pages 6.19: msync(2), flags and Linux behavior. https://man7.org/linux/man-pages/man2/msync.2.html (accessed 2026-10-13)
- [mmap-api] Linux man-pages 6.19: mmap(2), shared/private mappings and MAP_SYNC. https://man7.org/linux/man-pages/man2/mmap.2.html (accessed 2026-10-13)
- [hesela-fsync] Hesela: File and mapped-range synchronization boundaries. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-13)

### MTBF

URL: https://hesela.dev/terms/mtbf/
Status: shipping

Record updated: 2026-10-12

Mean time between failures (MTBF) is the expected operating time between successive failures of a repairable system under specified conditions.

Note: For a constant-rate repairable-system model, estimate MTBF as total operating exposure divided by the failure count. It is not a warranty or a calendar replacement age for an individual drive. MTTF describes time to first failure of a non-repairable item; check which quantity a drive specification actually reports. Converting a mean into a failure probability requires a lifetime model.

Related terms:
- [afr](https://hesela.dev/terms/afr/)
- [hdd](https://hesela.dev/terms/hdd/)
- [smart](https://hesela.dev/terms/smart/)
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)
- [annual-replacement-rate](https://hesela.dev/terms/annual-replacement-rate/)
- [rate-of-occurrence-of-failures](https://hesela.dev/terms/rate-of-occurrence-of-failures/)

Citations:
- [nist-intervals] NIST e-Handbook: Constant repair rate model and confidence bounds (8.4.5.1). https://www.itl.nist.gov/div898/handbook/apr/section4/apr451.htm (accessed 2026-10-10)
- [nist-exponential] NIST e-Handbook: Exponential distribution (8.1.6.1). https://www.itl.nist.gov/div898/handbook/apr/section1/apr161.htm (accessed 2026-10-10)
- [hesela-methods] Hesela: AFR is a rate, not a one-year failure probability. https://hesela.com/analyses/afr-rate-not-probability/ (accessed 2026-10-10)

### Multipart upload

URL: https://hesela.dev/terms/multipart-upload/
Also known as: Multipart object upload
Status: shipping

Record updated: 2026-10-12

Multipart upload is an object-transfer process that sends numbered parts independently and assembles them into one object when the upload is completed.

Note: Amazon S3 initiates an upload, accepts parts under an upload ID, and assembles the submitted parts in part-number order at completion. The part ETags submitted in the completion manifest are distinct from the destination object's current ETag used by an If-Match precondition. These details describe S3; another object-storage service may implement different limits or semantics.

Advantages:
- Parts can transfer in parallel, and a failed part transfer can be retried without retransmitting parts that have already succeeded. (sources: [c1])
- S3 CompleteMultipartUpload can apply If-None-Match or If-Match to the destination object when publishing the assembled upload. (sources: [c2])

Limitations:
- A multipart S3 object's ETag is not the MD5 digest of the complete object; integrity checks must use the documented checksum algorithm and full-object or composite scope. (sources: [c3], [c4])
- An in-progress S3 multipart upload does not reserve its destination key, so another writer can publish before its conditional completion. (sources: [c5])
- A 409 ConditionalRequestConflict at S3 completion requires a new multipart upload and re-uploading every part; merely repeating completion with the old upload ID is insufficient. (sources: [c2])
- Unfinished S3 uploads retain part storage until completed or aborted, so abandoned uploads need cleanup; the initial HTTP 200 at completion can also contain an embedded error that a raw API client must parse. (sources: [c1], [c2])

Related terms:
- [object-storage](https://hesela.dev/terms/object-storage/)
- [entity-tag](https://hesela.dev/terms/entity-tag/)
- [conditional-write](https://hesela.dev/terms/conditional-write/)

Citations:
- [c1] Amazon S3: Uploading and copying objects using multipart upload. https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html (accessed 2026-10-12)
- [c2] Amazon S3 API Reference: CompleteMultipartUpload. https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html (accessed 2026-10-12)
- [c3] Amazon S3 API Reference: Object, ETag semantics. https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html (accessed 2026-10-12)
- [c4] Amazon S3: Checking object integrity for data uploads. https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity-upload.html (accessed 2026-10-12)
- [c5] Amazon S3: How to prevent object overwrites with conditional writes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html (accessed 2026-10-12)
- [c6] Object ETags: checksums and conditional writes are different. https://hesela.com/analyses/object-etags-checksums-conditional-writes/ (accessed 2026-10-12)

### Multipath I/O

URL: https://hesela.dev/terms/multipath-io/
Status: shipping

Record updated: 2026-10-11

Multipath I/O manages multiple paths to the same storage device for failover and, where supported, load distribution.

Note: Redundant paths are alternative routes to the same logical storage, not additional replicas. Path selection and access exclusion solve different problems: a surviving route does not establish which application node may write. For shared storage, check the deployed reservation or fencing mechanism across all relevant paths. All-paths-down queueing policy is a separate availability decision; inspect it alongside recovery timers.

Related terms:
- [dual-port](https://hesela.dev/terms/dual-port/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [nvme](https://hesela.dev/terms/nvme/)
- [alua](https://hesela.dev/terms/alua/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)
- [asymmetric-namespace-access](https://hesela.dev/terms/asymmetric-namespace-access/)
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [scsi-persistent-reservations](https://hesela.dev/terms/scsi-persistent-reservations/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)
- [no-path-retry](https://hesela.dev/terms/no-path-retry/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Multipath I/O. https://en.wikipedia.org/wiki/Multipath_I/O (accessed 2026-03-26)
- [linux-ana] Linux kernel documentation: Linux NVMe multipath, introduction and policies.. https://docs.kernel.org/admin-guide/nvme-multipath.html (accessed 2026-10-11)
- [linux-pr] Linux kernel documentation: Block layer support for Persistent Reservations.. https://docs.kernel.org/block/pr.html (accessed 2026-10-11)
- [hesela-fencing] Storage fencing: why a lost heartbeat does not stop writes. https://hesela.com/analyses/storage-fencing-stale-writes/ (accessed 2026-10-11)
- [multipath-man] multipath-tools: multipath.conf(5), no_path_retry and FC timeout options; pinned commit d53932bdbee02f440518ea384e63d7c4d3f66685.. https://github.com/opensvc/multipath-tools/blob/d53932bdbee02f440518ea384e63d7c4d3f66685/multipath/multipath.conf.5.in (accessed 2026-10-11)
- [hesela-timeouts] Storage timeouts: an expired timer is not a cancelled write. https://hesela.com/analyses/storage-timeouts-uncertain-completion/ (accessed 2026-10-11)

### NVMe multipath

URL: https://hesela.dev/terms/multipath-nvme/
Status: shipping

Record updated: 2026-10-15

Using multiple routes to the same NVMe namespace for path failover and, where supported, load distribution.

Note: Linux native NVMe multipath presents paths to the same namespace within an NVM subsystem as one block device. ANA access preference precedes the host's selection policy. [linux-ana] More routes are not more replicas, and their physical failure independence must be checked separately. If no usable path exists, I/O can wait or fail; this is not a guarantee of interruption-free failover. [linux-code] Path routing also does not grant exclusive write ownership. [hesela-fencing]

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [alua](https://hesela.dev/terms/alua/)
- [asymmetric-namespace-access](https://hesela.dev/terms/asymmetric-namespace-access/)
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [nvme-multipath-io-policy](https://hesela.dev/terms/nvme-multipath-io-policy/)
- [namespace-nvme](https://hesela.dev/terms/namespace-nvme/)

Citations:
- [c1] NVMe multipath. https://en.wikipedia.org/wiki/Multipath_I/O (accessed 2026-03-26)
- [linux-ana] Linux kernel documentation: Linux NVMe multipath, introduction and policies.. https://docs.kernel.org/admin-guide/nvme-multipath.html (accessed 2026-10-11)
- [hesela-fencing] Storage fencing: why a lost heartbeat does not stop writes. https://hesela.com/analyses/storage-fencing-stale-writes/ (accessed 2026-10-11)
- [linux-code] Linux v6.12, drivers/nvme/host/multipath.c: ANA selection, controller nr_active accounting and subsystem iopolicy.. https://github.com/torvalds/linux/blob/v6.12/drivers/nvme/host/multipath.c (accessed 2026-10-15)
- [hesela-paths] Hesela: NVMe multipath: ANA access states and Linux path policies. https://hesela.com/analyses/nvme-multipath-ana-path-selection/ (accessed 2026-10-15)

### NVMe namespace

URL: https://hesela.dev/terms/namespace-nvme/
Status: shipping

Record updated: 2026-10-15

An NVMe resource collection that a host can address through a namespace identifier, such as formatted non-volatile storage.

Note: A namespace need not belong exclusively to one controller: a shared namespace can be accessible through multiple controllers. A logical namespace is not a promise of physically separate media. [base21] FDP placement handles are namespace-scoped mappings, distinct from the reclaim unit handles they select. [base21] ANA groups coordinate namespace access-state transitions relative to each controller; a group is not a namespace or a physical failure domain. [base23]

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [ssd](https://hesela.dev/terms/ssd/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)
- [nvm-subsystem](https://hesela.dev/terms/nvm-subsystem/)
- [nvme-fdp](https://hesela.dev/terms/nvme-fdp/)
- [nvme-placement-identifier](https://hesela.dev/terms/nvme-placement-identifier/)
- [ana-group](https://hesela.dev/terms/ana-group/)
- [multipath-nvme](https://hesela.dev/terms/multipath-nvme/)

Citations:
- [base21] NVM Express Base Specification 2.1 (5 August 2024), section 1.5, printed pp. 11-12, and section 2.4.1, pp. 33-34. Copyright 2008-2024 NVM Express, Inc. All rights reserved.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)
- [base23] NVM Express Base Specification 2.3 (1 August 2025), section 8.1.1: Asymmetric Namespace Access. Pinned edition, not a claim about the latest revision.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [hesela-paths] Hesela: NVMe multipath: ANA access states and Linux path policies. https://hesela.com/analyses/nvme-multipath-ana-path-selection/ (accessed 2026-10-15)

### NAND copyback

URL: https://hesela.dev/terms/nand-copyback/
Also known as: copy-back, internal data move, IDM
Status: shipping

Record updated: 2026-10-11

NAND copyback relocates page data through an on-chip buffer to a destination page without transferring the payload to an external controller.

Note: The studied implementations constrain source and destination placement; a host copy command does not establish that NAND copyback occurred. Bypassing controller ECC can preserve read errors in the new copy, so the correction path must be specified.

Advantages:
- Can avoid the off-chip payload transfers used by a controller-mediated relocation. (sources: [hu2011])

Limitations:
- Placement restrictions are device-specific; historical odd/even rules must not be applied to every NAND generation. (sources: [hu2011])
- Restricted-copyback research uses conditional consecutive-copy budgets, not a universal safe count. (sources: [hong2018])

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [ftl](https://hesela.dev/terms/ftl/)
- [ldpc](https://hesela.dev/terms/ldpc/)
- [data-retention](https://hesela.dev/terms/data-retention/)

Citations:
- [hong2018] Hong, Kim, Park, Jung and Kim. Revitalizing Copybacks in Modern SSDs: Why and How. Author manuscript arXiv:1810.04603v1, 2018, sections 3-5.. https://arxiv.org/abs/1810.04603v1 (accessed 2026-10-11)
- [hu2011] Hu, Jiang, Feng, Tian, Luo and Zhang. Performance Impact and Interplay of SSD Parallelism through Advanced Commands, Allocation Strategy and Data Granularity. ICS 2011, sections 2.2 and 4.3.. https://ranger.uta.edu/~jiang/publication/Conferences/2011/2011-ICS-Performance%20Impact%20and%20Interplay%20of%20SSD%20Parallelism%20through%20Advanced%20Commands,%20Allocation%20Strategy%20and%20Data%20Granularity.pdf (accessed 2026-10-11)
- [han2021] Han, Gwak, Shin and Hwang. ZNS+: Advanced Zoned Namespace Interface for Supporting In-Storage Zone Compaction. OSDI 2021, sections 2.1 and 3.3.1.. https://www.usenix.org/system/files/osdi21-han.pdf (accessed 2026-10-11)
- [hesela-copyback] Hesela: NAND copyback, faster relocation is not fewer writes. https://hesela.com/analyses/nand-copyback-ecc-boundary/ (accessed 2026-10-11)
- [example] Hesela illustrative copyback payload accounting: assumptions, results and model hash. https://hesela.dev/research/copyback-accounting.json (accessed 2026-10-11)

### NAND erase block

URL: https://hesela.dev/terms/nand-erase-block/
Also known as: flash erase block
Status: shipping

Record updated: 2026-10-15

A NAND erase block is a group of flash pages erased together by a block-erase operation.

Note: It is not a host logical block or a filesystem block. Geometry is device-specific; preserving live pages before reuse adds copying work. [agrawal2008] [cai2017]

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [nand-page](https://hesela.dev/terms/nand-page/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [program-erase-cycle](https://hesela.dev/terms/program-erase-cycle/)
- [ftl](https://hesela.dev/terms/ftl/)

Citations:
- [agrawal2008] Agrawal et al. Design Tradeoffs for SSD Performance. USENIX ATC 2008, section 2 and Table 1.. https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal_html/index.html (accessed 2026-10-15)
- [cai2017] Cai et al. Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives. 2017, sections 2.1 and 2.3.. https://arxiv.org/pdf/1706.08642v3 (accessed 2026-10-15)

### NAND flash

URL: https://hesela.dev/terms/nand-flash/
Also known as: NAND
Status: shipping

A non-volatile memory type arranged in NAND strings, forming the storage media in most SSDs and flash cards.

Related terms:
- [nor-flash](https://hesela.dev/terms/nor-flash/)
- [slc](https://hesela.dev/terms/slc/)
- [mlc](https://hesela.dev/terms/mlc/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [ssd](https://hesela.dev/terms/ssd/)
- [ftl](https://hesela.dev/terms/ftl/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)
- [sd-express](https://hesela.dev/terms/sd-express/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] Flash memory. https://en.wikipedia.org/wiki/Flash_memory (accessed 2026-03-26)

### NAND page pairing

URL: https://hesela.dev/terms/nand-page-pairing/
Also known as: Paired pages, Shared pages
Status: shipping

NAND page pairing is the grouping of pages whose bits occupy the same physical memory cells.

Note: Linux MTD identifies a pair and a group (bit position); its pairing abstraction also accommodates TLC groups of three pages. Device-specific pairing is not a host-LBA adjacency rule.

Limitations:
- A raw-NAND pairing map is not exposed by this MTD API as an NVMe logical-block map. (sources: [linux])
- Interrupted programming of a partner page can corrupt earlier data in the studied MLC devices; this is not a current-fleet failure rate. (sources: [tseng])

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [mlc](https://hesela.dev/terms/mlc/)
- [ftl](https://hesela.dev/terms/ftl/)
- [program-interference](https://hesela.dev/terms/program-interference/)

Citations:
- [linux] Linux v6.12, include/linux/mtd/mtd.h: mtd_pairing_info and mtd_pairing_scheme. https://github.com/torvalds/linux/blob/v6.12/include/linux/mtd/mtd.h (accessed 2026-10-11)
- [tseng] Tseng, Grupp and Swanson. Understanding the Impact of Power Loss on Flash Memory. DAC 2011, sections 3 and 4.1.2. DOI: 10.1145/2024724.2024733. https://cseweb.ucsd.edu/users/swanson/papers/DAC2011PowerCut.pdf (accessed 2026-10-11)
- [hesela-pairing] Hesela: NAND paired pages and durability boundaries. https://hesela.com/analyses/nand-paired-pages-durability/ (accessed 2026-10-11)

### NAND page

URL: https://hesela.dev/terms/nand-page/
Also known as: flash page
Status: shipping

Record updated: 2026-10-15

A NAND page is a group of data bits addressed together for a page read or program operation within an erase block.

Note: A host sector and an FTL mapping entry need not have the same size as a physical page. In multi-bit NAND, different logical pages can share cells on a wordline. [agrawal2008] [cai2017]

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [nand-erase-block](https://hesela.dev/terms/nand-erase-block/)
- [nand-wordline](https://hesela.dev/terms/nand-wordline/)
- [nand-page-pairing](https://hesela.dev/terms/nand-page-pairing/)
- [ftl](https://hesela.dev/terms/ftl/)

Citations:
- [agrawal2008] Agrawal et al. Design Tradeoffs for SSD Performance. USENIX ATC 2008, section 2 and Table 1.. https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal_html/index.html (accessed 2026-10-15)
- [cai2017] Cai et al. Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives. 2017, sections 2.1 and 2.3.. https://arxiv.org/pdf/1706.08642v3 (accessed 2026-10-15)

### NAND wordline

URL: https://hesela.dev/terms/nand-wordline/
Also known as: wordline, WL
Status: shipping

Record updated: 2026-10-15

A NAND wordline is a shared control-gate connection used to address a group of flash memory cells.

Note: A wordline is not synonymous with a page: the planar two-bit MLC example has separate LSB and MSB pages on one wordline. [cai]

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [nand-page-pairing](https://hesela.dev/terms/nand-page-pairing/)
- [read-disturb](https://hesela.dev/terms/read-disturb/)
- [read-pass-voltage](https://hesela.dev/terms/read-pass-voltage/)
- [nand-page](https://hesela.dev/terms/nand-page/)

Citations:
- [cai] Cai et al. Read Disturb Errors in MLC NAND Flash Memory: Characterization, Mitigation, and Recovery. DSN 2015, sections 2.1 and 3.6-3.7. DOI 10.1109/DSN.2015.49.. https://people.inf.ethz.ch/~omutlu/pub/flash-read-disturb-errors_dsn15.pdf (accessed 2026-10-14)

### NAS

URL: https://hesela.dev/terms/nas/
Status: shipping

Network-attached storage serves files over IP to clients without block-level host attachment.

Related terms:
- [file-storage](https://hesela.dev/terms/file-storage/)
- [smb-protocol](https://hesela.dev/terms/smb-protocol/)

Citations:
- [c1] NAS. https://en.wikipedia.org/wiki/Network-attached_storage (accessed 2026-03-26)

### Native Command Queuing

URL: https://hesela.dev/terms/native-command-queuing/
Also known as: NCQ
Status: shipping

Record updated: 2026-10-15

Native Command Queuing (NCQ) allows multiple tagged ATA commands to be outstanding so a supporting device can schedule their execution.

Note: Linux's documented NCQ error path uses log page 0x10 to identify the failed tag, while other affected commands may be retried. In v6.12, attribution is conditional on a readable log, an active tag and the port state. Several recovery messages do not establish several independent device failures. NCQ is not a write-durability guarantee.

Related terms:
- [sata](https://hesela.dev/terms/sata/)
- [ahci](https://hesela.dev/terms/ahci/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [ata-doc] Linux v6.12: libata device, NCQ and bus error documentation. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/Documentation/driver-api/libata.rst (accessed 2026-10-15)
- [ata-sata] Linux v6.12: ata_eh_analyze_ncq_error and failed-tag attribution. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/drivers/ata/libata-sata.c (accessed 2026-10-15)
- [hesela-link] SATA link errors: what CRC flags, NCQ recovery and PHY counters prove. https://hesela.com/analyses/sata-sas-link-failure-signatures/ (accessed 2026-10-15)

### Nearline HDD

URL: https://hesela.dev/terms/nearline-hdd/
Also known as: capacity HDD, archive disk
Status: shipping

A class of high-capacity, lower-RPM hard drives intended for always-on but not primary-tier storage.

Note: In contemporary vendor language, “nearline” means high-capacity enterprise HDDs kept online for bulk cloud object, analytics, and backup-target tiers—typically 7200 RPM 3.5-inch SATA or SAS drives with enterprise duty-cycle and vibration specs—not low-latency transactional spindles. Recording tech on these lines adopts density tools first (helium, SMR, HAMR, MAMR). The word historically also meant automated tape/optical “near online” libraries in IBM-era usage; do not confuse marketing nearline HDD with that older library sense. Nearline is a product class and workload target, not a single recording mode.

Advantages:
- Lowest cost per terabyte among spinning disk offerings for warm/cold data. (sources: [c1])

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [helium-hdd](https://hesela.dev/terms/helium-hdd/)
- [smr](https://hesela.dev/terms/smr/)
- [cmr](https://hesela.dev/terms/cmr/)
- [hamr](https://hesela.dev/terms/hamr/)
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)

Citations:
- [c1] Nearline storage. https://en.wikipedia.org/wiki/Nearline_storage (accessed 2026-03-26)
- [n2] Seagate — Exos enterprise / mass capacity HDD family. https://www.seagate.com/products/enterprise-drives/exos/ (accessed 2026-10-07)
- [n3] Toshiba — MG09 nearline enterprise capacity HDD. https://storage.toshiba.com/enterprise-hdd/cloud-scale-capacity/mg09-series (accessed 2026-10-07)

### Nearline SAS

URL: https://hesela.dev/terms/nearline-sas/
Status: shipping

Lower-RPM SAS drives tuned for capacity and always-on use in servers.

Related terms:
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [sas](https://hesela.dev/terms/sas/)

Citations:
- [c1] Nearline SAS. https://en.wikipedia.org/wiki/Nearline_storage (accessed 2026-03-26)

### NFS attribute cache

URL: https://hesela.dev/terms/nfs-attribute-cache/
Also known as: NFS metadata attribute cache
Status: shipping

Record updated: 2026-10-14

An NFS attribute cache is a client-side copy of file or directory metadata reused until refresh or revalidation is required.

Note: Metadata such as size and change information is not the file's cached payload. Attribute freshness does not create an atomic snapshot across multiple files. Linux actimeo configures attribute-cache timers; noac additionally makes application writes synchronous, so they are not interchangeable settings.

Limitations:
- Disabling attribute caching does not disable all file-data caching or eliminate every coherence race. (sources: [nfs-client])

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [close-to-open-consistency](https://hesela.dev/terms/close-to-open-consistency/)
- [nfs-delegation](https://hesela.dev/terms/nfs-delegation/)
- [page-cache](https://hesela.dev/terms/page-cache/)
- [nfs-lookup-cache](https://hesela.dev/terms/nfs-lookup-cache/)

Citations:
- [nfs-client] nfs-utils nfs(5), Debian trixie: data and metadata coherence and version-specific cto/nocto options.. https://manpages.debian.org/trixie/nfs-common/nfs.5.en.html (accessed 2026-10-14)
- [rfc7530] Haynes and Noveck (editors). NFS Version 4 Protocol. RFC 7530, sections 10.3, 10.4 and 10.6 (NFSv4.0).. https://datatracker.ietf.org/doc/html/rfc7530#section-10 (accessed 2026-10-14)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-14)

### NFS COMMIT

URL: https://hesela.dev/terms/nfs-commit/
Also known as: NFSv3 COMMIT
Status: shipping

Record updated: 2026-10-12

NFSv3 COMMIT requests stable storage of previously buffered writes and associated metadata for a specified file range.

Note: RFC 1813 section 3.3.21 defines the operation; count zero means from offset to end of file. The client compares the returned verifier with those associated with its outstanding writes, retransmitting uncommitted buffers if the verifier changes. A successful status alone is insufficient evidence that earlier volatile data survived a server restart. This is a file-range persistence operation, not a transaction across several files; NFSv4 recovery is outside this record's scope.

Advantages:
- Allows clients to batch unstable writes before requesting their persistence. (sources: [rfc1813])

Limitations:
- Cannot recover a lost client copy of data that never reached stable server storage. (sources: [rfc1813])

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [nfs-write-verifier](https://hesela.dev/terms/nfs-write-verifier/)
- [cache-flush](https://hesela.dev/terms/cache-flush/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [rfc1813] B. Callaghan, B. Pawlowski and P. Staubach. NFS Version 3 Protocol Specification. RFC 1813, June 1995, sections 3.3.7, 3.3.21 and 4.8.. https://www.rfc-editor.org/rfc/rfc1813.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)

### NFSv4 file delegation

URL: https://hesela.dev/terms/nfs-delegation/
Also known as: NFS delegation, NFS read delegation, NFS write delegation
Status: shipping

Record updated: 2026-10-14

An NFSv4 file delegation is a recallable server grant allowing a client to manage specified opens and cached file state locally while conflicting access is coordinated by the server.

Note: Read and write delegations have different permissions. A write delegation may defer transmitting modified data at application close; conflicting access must be coordinated through return or revocation under the protocol rules. Delegation is not permanent ownership, a backup, or evidence that the server already stores the latest bytes durably.

Limitations:
- Without an OPEN delegation, NFSv4.0 and NFSv4.1 require modified data on server stable storage before protocol CLOSE; delegated close behavior must not be generalized to that case. (sources: [rfc7530], [rfc8881])

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [close-to-open-consistency](https://hesela.dev/terms/close-to-open-consistency/)
- [nfs-attribute-cache](https://hesela.dev/terms/nfs-attribute-cache/)
- [nfs-commit](https://hesela.dev/terms/nfs-commit/)

Citations:
- [rfc7530] Haynes and Noveck (editors). NFS Version 4 Protocol. RFC 7530, sections 10.3, 10.4 and 10.6 (NFSv4.0).. https://datatracker.ietf.org/doc/html/rfc7530#section-10 (accessed 2026-10-14)
- [rfc8881] Noveck and Lever (editors). NFS Version 4 Minor Version 1 Protocol. RFC 8881, sections 10.3-10.6 (NFSv4.1).. https://www.rfc-editor.org/rfc/rfc8881.html#section-10 (accessed 2026-10-14)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-14)

### NFS lookup cache

URL: https://hesela.dev/terms/nfs-lookup-cache/
Also known as: NFS name cache, NFS dentry cache
Status: shipping

Record updated: 2026-10-14

An NFS lookup cache retains directory-name resolution results, including found and missing entries, subject to revalidation.

Note: Linux lookupcache=positive revalidates negative entries; lookupcache=none revalidates both positive and negative entries before use. These controls do not disable file-data caching. More validation can increase server work.

Limitations:
- Name visibility is not evidence of durable file contents or a multi-file transaction. (sources: [rfc7530], [hesela-stability])

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [nfs-attribute-cache](https://hesela.dev/terms/nfs-attribute-cache/)
- [close-to-open-consistency](https://hesela.dev/terms/close-to-open-consistency/)

Citations:
- [nfs-client] nfs-utils nfs(5), Debian trixie: lookupcache option.. https://manpages.debian.org/trixie/nfs-common/nfs.5.en.html (accessed 2026-10-14)
- [rfc7530] RFC 7530, section 10.8: Name Caching.. https://datatracker.ietf.org/doc/html/rfc7530#section-10.8 (accessed 2026-10-14)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-14)

### NFS open-file preservation

URL: https://hesela.dev/terms/nfs-preserve-unlinked/
Also known as: OPEN4_RESULT_PRESERVE_UNLINKED, preserve unlinked
Status: shipping

Record updated: 2026-10-16

NFS open-file preservation is the NFSv4.1 OPEN-result promise to retain a file removed while open, including through the server-restart grace period for open reclamation.

Note: RFC 8881 section 18.16.3 defines the capability; a version label alone does not show that it was returned. [rfc8881] Linux v6.12 records the result on the inode and uses it to bypass the silly-rename branch. [linux-open] [linux-dir] Erratum 6865 identifies contradictory REMOVE wording; its status was Reported, not Verified, on 2026-10-16. [erratum]

Advantages:
- Moves the advertised open-file lifetime guarantee to the server rather than relying solely on a client's temporary name.

Limitations:
- Not proof of data-write durability, indefinite retention or a successful reclaim.
- Client implementation, server behavior and returned flags must be evaluated together.

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [nfs-silly-rename](https://hesela.dev/terms/nfs-silly-rename/)
- [unlink](https://hesela.dev/terms/unlink/)
- [nfs-delegation](https://hesela.dev/terms/nfs-delegation/)

Citations:
- [linux-open] Linux v6.12, fs/nfs/nfs4proc.c: _nfs4_do_open records the server's preservation flag.. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/nfs/nfs4proc.c (accessed 2026-10-16)
- [linux-dir] Linux v6.12, fs/nfs/dir.c: nfs_unlink gates silly rename on the inode preservation flag.. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/nfs/dir.c (accessed 2026-10-16)
- [rfc8881] D. Noveck and C. Lever (editors). RFC 8881, sections 18.16.3 and 18.25.4: OPEN and REMOVE.. https://www.rfc-editor.org/rfc/rfc8881.html#section-18.16.3 (accessed 2026-10-16)
- [erratum] RFC 8881 technical erratum 6865, reported by David Noveck on 2022-02-28; status Reported when checked.. https://www.rfc-editor.org/errata/eid6865 (accessed 2026-10-16)
- [hesela-unlink] Why deleted NFS files become .nfs files. https://hesela.com/analyses/nfs-silly-rename-open-unlink/ (accessed 2026-10-16)

### NFS silly rename

URL: https://hesela.dev/terms/nfs-silly-rename/
Also known as: silly rename, NFS .nfs file
Status: shipping

Record updated: 2026-10-16

NFS silly rename is a client workaround that temporarily renames an in-use file's directory entry and defers its removal until local references are released.

Note: Linux v6.12 uses a hidden .nfs name and deferred unlink. The nfs_unlink branch is conditional on a dentry reference count above one and absence of the inode's preservation flag; this count is not a file-descriptor count. [linux-dir] [linux-unlink] The original Sun paper documents client-crash leftovers and a cross-client removal limitation, not modern fleet rates. [sandberg]

Advantages:
- Helps preserve access through existing local references while removing the application's original name.

Limitations:
- Does not establish a complete inventory of other clients' opens.
- A hidden name is not evidence of media failure, successful cleanup or secure erasure.

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [nfs-preserve-unlinked](https://hesela.dev/terms/nfs-preserve-unlinked/)
- [unlink](https://hesela.dev/terms/unlink/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)

Citations:
- [sandberg] R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh and B. Lyon. Design and Implementation of the Sun Network Filesystem. Summer USENIX 1985, pp. 119-130; open-file semantics, pp. 126-127.. https://www.cs.wisc.edu/~dusseau/Classes/CS736/Papers/nfs.pdf (accessed 2026-10-16)
- [linux-unlink] Linux v6.12, fs/nfs/unlink.c: nfs_sillyrename and asynchronous cleanup.. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/nfs/unlink.c (accessed 2026-10-16)
- [linux-dir] Linux v6.12, fs/nfs/dir.c: nfs_unlink gates silly rename on the inode preservation flag.. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/nfs/dir.c (accessed 2026-10-16)
- [hesela-unlink] Why deleted NFS files become .nfs files. https://hesela.com/analyses/nfs-silly-rename-open-unlink/ (accessed 2026-10-16)

### NFS

URL: https://hesela.dev/terms/nfs-storage/
Also known as: Network File System, NFSv3, NFSv4
Status: shipping

Record updated: 2026-10-16

Network File System is a family of protocols for accessing files and directories on a remote server over a network.

Note: Persistence and recovery depend on protocol version and implementation. In NFSv3, WRITE requests UNSTABLE, DATA_SYNC or FILE_SYNC and returns the achieved level in committed; the server may return a stronger level than requested. COMMIT persists buffered file-range writes and metadata, with write-verifier comparison needed to detect lost uncommitted state. Do not infer durable server storage from an application write return or generalize the complete v3 recovery procedure to v4. The Linux server's async export option explicitly weakens protocol persistence guarantees. Cache visibility is a separate concern: close-to-open checks support sequential sharing, and NFSv4 delegations can change when validation and writeback occur. See the related cache records for version-specific boundaries. Open-file lifetime is separate from write stability: Linux can use silly rename, while NFSv4.1 defines an advertised preservation capability. [hesela-unlink]

Advantages:
- Provides a network file interface while separating client access from server storage implementation. (sources: [rfc1813])

Limitations:
- Client buffering, server export policy and storage-cache behavior are distinct durability boundaries. (sources: [rfc1813], [exports], [hesela-stability])

Related terms:
- [nas](https://hesela.dev/terms/nas/)
- [file-storage](https://hesela.dev/terms/file-storage/)
- [nfs-commit](https://hesela.dev/terms/nfs-commit/)
- [nfs-write-verifier](https://hesela.dev/terms/nfs-write-verifier/)
- [fsync](https://hesela.dev/terms/fsync/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [close-to-open-consistency](https://hesela.dev/terms/close-to-open-consistency/)
- [nfs-attribute-cache](https://hesela.dev/terms/nfs-attribute-cache/)
- [nfs-delegation](https://hesela.dev/terms/nfs-delegation/)
- [nfs-lookup-cache](https://hesela.dev/terms/nfs-lookup-cache/)
- [nfs-silly-rename](https://hesela.dev/terms/nfs-silly-rename/)
- [nfs-preserve-unlinked](https://hesela.dev/terms/nfs-preserve-unlinked/)

Citations:
- [rfc1813] B. Callaghan, B. Pawlowski and P. Staubach. NFS Version 3 Protocol Specification. RFC 1813, June 1995, sections 3.3.7, 3.3.21 and 4.8.. https://www.rfc-editor.org/rfc/rfc1813.html (accessed 2026-10-12)
- [exports] nfs-utils exports(5), Debian trixie manual: async and sync export options.. https://manpages.debian.org/trixie/nfs-kernel-server/exports.5.en.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)
- [nfs-client] nfs-utils nfs(5), Debian trixie: data and metadata coherence and version-specific cto/nocto options.. https://manpages.debian.org/trixie/nfs-common/nfs.5.en.html (accessed 2026-10-14)
- [rfc7530] Haynes and Noveck (editors). NFS Version 4 Protocol. RFC 7530, sections 10.3, 10.4 and 10.6 (NFSv4.0).. https://datatracker.ietf.org/doc/html/rfc7530#section-10 (accessed 2026-10-14)
- [rfc8881] Noveck and Lever (editors). NFS Version 4 Minor Version 1 Protocol. RFC 8881, sections 10.3-10.6 (NFSv4.1).. https://www.rfc-editor.org/rfc/rfc8881.html#section-10 (accessed 2026-10-14)
- [hesela-unlink] Why deleted NFS files become .nfs files. https://hesela.com/analyses/nfs-silly-rename-open-unlink/ (accessed 2026-10-16)

### NFS write verifier

URL: https://hesela.dev/terms/nfs-write-verifier/
Also known as: NFSv3 write verifier, writeverf3
Status: shipping

Record updated: 2026-10-12

An NFSv3 write verifier is a server cookie returned by WRITE and COMMIT that lets clients detect state changes that may have lost uncommitted writes.

Note: The verifier distinguishes server states relevant to buffered-write recovery; it is not a data checksum, transaction identifier or cryptographic authentication token. When a returned verifier differs from the one associated with uncommitted buffers, the client retransmits those buffers and establishes stable completion again. Verifier comparison accompanies status, byte-count and stability checks; equality alone does not establish that a write was stable.

Limitations:
- Detection requires retained client state and does not itself supply or repair lost data. (sources: [rfc1813])

Related terms:
- [nfs-storage](https://hesela.dev/terms/nfs-storage/)
- [nfs-commit](https://hesela.dev/terms/nfs-commit/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [rfc1813] B. Callaghan, B. Pawlowski and P. Staubach. NFS Version 3 Protocol Specification. RFC 1813, June 1995, sections 3.3.7, 3.3.21 and 4.8.. https://www.rfc-editor.org/rfc/rfc1813.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)

### no_path_retry

URL: https://hesela.dev/terms/no-path-retry/
Also known as: DM Multipath no-path retry
Status: shipping

Record updated: 2026-10-11

no_path_retry is a DM Multipath setting that controls queueing behavior when every path to a mapped device is unavailable.

Note: The upstream interface accepts a positive retry count, fail for no queueing, or queue for indefinite queueing. A numeric count is not seconds. This is not an application deadline or a native NVMe multipath setting; verify the effective configuration and installed version.

Related terms:
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [multipath-man] multipath-tools: multipath.conf(5), no_path_retry and FC timeout options; pinned commit d53932bdbee02f440518ea384e63d7c4d3f66685.. https://github.com/opensvc/multipath-tools/blob/d53932bdbee02f440518ea384e63d7c4d3f66685/multipath/multipath.conf.5.in (accessed 2026-10-11)
- [hesela-timeouts] Storage timeouts: an expired timer is not a cancelled write. https://hesela.com/analyses/storage-timeouts-uncertain-completion/ (accessed 2026-10-11)

### NOR flash

URL: https://hesela.dev/terms/nor-flash/
Also known as: NOR
Status: shipping

A random-access flash memory type often used for firmware execute-in-place rather than bulk SSD storage.

Advantages:
- Byte-addressable reads suitable for code storage. (sources: [c1])

Limitations:
- Poor cost per bit for large capacities versus NAND. (sources: [c1])

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] Flash memory. https://en.wikipedia.org/wiki/Flash_memory (accessed 2026-03-26)

### Normalized magnitude of data loss (NOMDL)

URL: https://hesela.dev/terms/normalized-magnitude-data-loss/
Also known as: NOMDL
Status: research

Record updated: 2026-10-15

Normalized magnitude of data loss (NOMDL) is the expected number of bytes lost per usable terabyte within a stated mission time.

Note: Greenan, Plank and Wylie proposed NOMDL in 2010 to report loss magnitude and capacity together. [greenan-hotstorage10-pdf] The time horizon and underlying model must accompany the value; normalization does not validate failure assumptions.

Related terms:
- [mean-time-to-data-loss](https://hesela.dev/terms/mean-time-to-data-loss/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)

Citations:
- [greenan-hotstorage10-pdf] Mean time to meaningless: MTTDL, Markov models, and storage system reliability, Greenan, Plank, and Wylie, USENIX HotStorage 2010 (USENIX PDF, independent academic source). https://www.usenix.org/legacy/event/hotstorage10/tech/full_papers/Greenan.pdf (accessed 2026-10-15)
- [hesela-durability] Eleven nines: what a durability model does not prove. https://hesela.com/analyses/s3-durability-eleven-nines-derivation/ (accessed 2026-10-15)

### Noise-predictive maximum-likelihood detection

URL: https://hesela.dev/terms/npml-detection/
Also known as: NPML
Status: unknown

Record updated: 2026-10-11

Noise-predictive maximum-likelihood (NPML) detection incorporates noise prediction or whitening into sequence-detector branch metrics for a partial-response recording channel.

Note: Eleftheriou and Hirt (1996) describe incorporating noise prediction into a Viterbi detector and report simulation gains over PRML and EPRML for the studied configurations. This is a detector refinement, not a new storage medium or an error-correcting code. The 2001 Cideciyan et al. study distinguishes bit, byte and sector error performance when combining detection with parity post-processing and Reed-Solomon decoding. Its abstract reports that an improvement in bit and byte metrics did not yield the same sector-level separation for two compared schemes. Neither abstract supplies a universal improvement for arbitrary drives, firmware or workloads.

Advantages:
- Models noise structure within sequence detection rather than treating noise prediction as a separate storage technology. (sources: [ibm1996])

Limitations:
- Published simulated gains depend on the channel, detector and coding configuration; current product support is not established by these historical papers. (sources: [ibm1996], [ibm2001])

Related terms:
- [prml-encoding](https://hesela.dev/terms/prml-encoding/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [bit-error-rate](https://hesela.dev/terms/bit-error-rate/)

Citations:
- [ibm1996] E. Eleftheriou and W. Hirt, Improving performance of PRML/EPRML through noise prediction (1996), IBM Research abstract. https://research.ibm.com/publications/improving-performance-of-prmleprml-through-noise-prediction (accessed 2026-10-11)
- [ibm2001] Cideciyan et al., Noise predictive maximum likelihood detection combined with parity-based post-processing (2001), IBM Research abstract. https://research.ibm.com/publications/noise-predictive-maximum-likelihood-detection-combined-with-parity-based-post-processing (accessed 2026-10-11)

### NVDIMM-N

URL: https://hesela.dev/terms/nvdimm-n/
Status: limited

A DIMM form factor combining DRAM with flash backup to persist memory contents across power loss.

Related terms:
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [storage-class-memory](https://hesela.dev/terms/storage-class-memory/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)

Citations:
- [c1] NVDIMM-N. https://en.wikipedia.org/wiki/NVDIMM (accessed 2026-03-26)

### NVM subsystem

URL: https://hesela.dev/terms/nvm-subsystem/
Status: shipping

Record updated: 2026-10-12

An NVMe system containing one or more controllers, domains and ports, with zero or more namespaces.

Note: The subsystem is broader than an individual controller and need not expose a storage namespace. For example, a Discovery Service contains only Discovery controllers and does not expose namespaces. [base21]

Related terms:
- [namespace-nvme](https://hesela.dev/terms/namespace-nvme/)
- [nvme](https://hesela.dev/terms/nvme/)

Citations:
- [base21] NVM Express Base Specification 2.1 (5 August 2024), section 1.5, printed pp. 8 and 11: Discovery Service and NVM subsystem. Copyright 2008-2024 NVM Express, Inc. All rights reserved.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)

### NVMe Available Spare

URL: https://hesela.dev/terms/nvme-available-spare/
Also known as: Available Spare, AVSP, avail_spare
Status: shipping

Record updated: 2026-10-15

NVMe Available Spare is the normalized percentage of spare capacity remaining in the NVM subsystem.

Note: The SMART / Health Information log reports Available Spare at byte 3 and its threshold at byte 4, each on a 0-to-100 percentage scale. Critical Warning bit 0 indicates that spare capacity has fallen below the reported threshold; equality alone does not satisfy that condition. [nvme-base-2-3-smart]

Limitations:
- Available Spare is not filesystem free space or the complement of Percentage Used; the two fields describe different quantities and need not change together. (sources: [microsoft-nvme-health], [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-percentage-used](https://hesela.dev/terms/nvme-percentage-used/)
- [nvme-critical-warning](https://hesela.dev/terms/nvme-critical-warning/)
- [nvme-endurance-group](https://hesela.dev/terms/nvme-endurance-group/)

Citations:
- [microsoft-nvme-health] Microsoft: NVME_HEALTH_INFO_LOG, AvailableSpare and AvailableSpareThreshold members. https://learn.microsoft.com/en-us/windows/win32/api/nvme/ns-nvme-nvme_health_info_log (accessed 2026-10-14)
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, p. 214: Available Spare and threshold. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)

### NVMe backplane

URL: https://hesela.dev/terms/nvme-backplane/
Status: shipping

Midplane wiring routing PCIe signals from server motherboards to U.2 or EDSFF drive bays.

Related terms:
- [u2](https://hesela.dev/terms/u2/)
- [edsff](https://hesela.dev/terms/edsff/)
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] NVMe backplane. https://en.wikipedia.org/wiki/NVM_Express (accessed 2026-03-26)

### NVMe base specification

URL: https://hesela.dev/terms/nvme-base-spec/
Status: shipping

The core NVM Express document defining admin and I/O command sets for PCIe SSDs.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [nvme-of](https://hesela.dev/terms/nvme-of/)
- [sd-express](https://hesela.dev/terms/sd-express/)

Citations:
- [c1] NVMe base specification. https://en.wikipedia.org/wiki/NVM_Express (accessed 2026-03-26)

### NVMe Composite Temperature

URL: https://hesela.dev/terms/nvme-composite-temperature/
Also known as: Composite Temperature, NVMe CTEMP
Status: shipping

Record updated: 2026-10-16

NVMe Composite Temperature is an implementation-specific temperature value in kelvins representing the controller and its associated namespaces in the SMART / Health Information log.

Note: Base 2.3 Figure 210 places the field at bytes 1-2 and does not require its value to match any physical point in the NVM subsystem. Separate Temperature Sensor 1-8 fields are distinct telemetry. WCTEMP and CCTEMP in Identify Controller specify warning and critical overheating composite thresholds. [nvme-base-2-3-smart]

Limitations:
- A monitoring label such as NAND temperature or controller-die temperature requires device-specific evidence; the composite field alone does not establish either interpretation. (sources: [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [thermal-throttling-ssd](https://hesela.dev/terms/thermal-throttling-ssd/)
- [host-controlled-thermal-management](https://hesela.dev/terms/host-controlled-thermal-management/)
- [nvme-warning-composite-temperature-time](https://hesela.dev/terms/nvme-warning-composite-temperature-time/)
- [nvme-critical-composite-temperature-time](https://hesela.dev/terms/nvme-critical-composite-temperature-time/)

Citations:
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, Figure 210, printed pp. 214, 216-217. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)

### NVMe Controller Busy Time

URL: https://hesela.dev/terms/nvme-controller-busy-time/
Also known as: Controller Busy Time, controller_busy_time, NVMe CBT
Status: shipping

Record updated: 2026-10-14

NVMe Controller Busy Time is the cumulative number of minutes during which the controller has an outstanding I/O command, as defined by the SMART / Health Information log.

Note: Base 2.3 Figure 210 places this 128-bit field at bytes 96-111. Busy time runs from an I/O Submission Queue Tail doorbell write while a command remains outstanding until its corresponding completion entry has been posted. Overlapping commands do not create additive elapsed time. [nvme-base-2-3-smart]

Limitations:
- Busy-time-normalized bandwidth is not wall-clock bandwidth, and this coarse cumulative duration is not a per-command latency distribution or an average of individual latencies. (sources: [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)

Citations:
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, Figure 210, printed p. 216. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)

### NVMe Critical Composite Temperature Time

URL: https://hesela.dev/terms/nvme-critical-composite-temperature-time/
Also known as: CCTT, critical_comp_time
Status: shipping

Record updated: 2026-10-16

NVMe Critical Composite Temperature Time is a cumulative SMART / Health log duration in minutes of controller operation with Composite Temperature at or above the critical composite-temperature threshold.

Note: NVMe Base 2.3 Figure 210 defines the threshold as CCTEMP from Identify Controller; if CCTEMP is zero, this timer is always zero regardless of Composite Temperature. [base23] It is separate from Warning Composite Temperature Time, from HCTM action timers measured in seconds, and from the current Critical Warning temperature bit, which can reflect an over-temperature or under-temperature condition. [base23]

Limitations:
- The timer is not a shutdown count, a damage measurement or a calibrated failure probability; zero does not prove the drive has never been hot. (sources: [base23])

Related terms:
- [nvme-composite-temperature](https://hesela.dev/terms/nvme-composite-temperature/)
- [nvme-warning-composite-temperature-time](https://hesela.dev/terms/nvme-warning-composite-temperature-time/)
- [host-controlled-thermal-management](https://hesela.dev/terms/host-controlled-thermal-management/)
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-critical-warning](https://hesela.dev/terms/nvme-critical-warning/)
- [thermal-throttling-ssd](https://hesela.dev/terms/thermal-throttling-ssd/)

Citations:
- [base23] NVM Express Base Specification 2.3, Figure 210, printed pp. 214, 216-217: temperature conditions and timers. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-16)

### NVMe Critical Warning

URL: https://hesela.dev/terms/nvme-critical-warning/
Also known as: Critical Warning, critical_warning, NVMe SMART warning bitmask
Status: shipping

Record updated: 2026-10-16

NVMe Critical Warning is the SMART / Health Information log bitmask identifying controller warning conditions at the time the log is read.

Note: NVMe Base 2.3 defines bits 0 through 6: spare below threshold, temperature threshold condition, degraded reliability, all media read-only, failed volatile-memory backup, PMR read-only or unreliable, and indeterminate personality state. Bit 7 is reserved. Bit 6 covers a failed personality-settings change when the previous personality could not be restored. NVMe 1.4a defined bits 0 through 5 with bits 6 and 7 reserved. [nvme-base-2-3-smart] The temperature bit reports a current over-temperature or under-temperature threshold condition; it is not the cumulative Critical Composite Temperature Time counter and need not imply that CCTEMP was crossed. [nvme-base-2-3-smart]

Limitations:
- The mask is a current-state report, not a persistent event history; several flags can coexist, and a clear mask is not a guarantee against future failure. (sources: [nvme-base-2-3-smart], [nvme-1-4a-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-available-spare](https://hesela.dev/terms/nvme-available-spare/)
- [nvme-media-data-integrity-errors](https://hesela.dev/terms/nvme-media-data-integrity-errors/)
- [nvme-critical-composite-temperature-time](https://hesela.dev/terms/nvme-critical-composite-temperature-time/)

Citations:
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, p. 214: Critical Warning. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)
- [nvme-1-4a-smart] NVM Express 1.4a, Figure 196, p. 122: historical six-bit Critical Warning layout. https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4a-2020.03.09-Ratified.pdf (accessed 2026-10-14)

### NVMe Data Units Written

URL: https://hesela.dev/terms/nvme-data-units-written/
Also known as: Data Units Written, DUW, data_units_written
Status: shipping

Record updated: 2026-10-15

NVMe Data Units Written is the SMART / Health Information log counter of host-written data, excluding metadata, in rounded-up groups of 1,000 units of 512 bytes.

Note: One reported unit corresponds to a 512000-byte quantum. For nonzero raw value v, multiplying v by 512000 gives the upper edge of the reporting bucket, not an exact byte total. Zero means the amount is not reported. Bytes 48 through 63 hold a 128-bit counter: preserve integer precision, for example with a decimal string or BigInt rather than an unrestricted JavaScript Number. [nvme-base-2-3-smart] Log 09h uses a different quantum; do not reuse this conversion there. [nvme-base-2-3-endurance]

Limitations:
- Host writes are not physical NAND writes, so this counter alone cannot measure write amplification; interval differences also retain the rounding uncertainty of the two readings. (sources: [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-percentage-used](https://hesela.dev/terms/nvme-percentage-used/)
- [nvme-endurance-group](https://hesela.dev/terms/nvme-endurance-group/)

Citations:
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, p. 215: Data Units Written. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)
- [nvme-base-2-3-endurance] NVM Express Base 2.3: section 3.2.3, pp. 81-82; section 5.2.12.1.10, pp. 230-232. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)

### NVMe Device Self-test log

URL: https://hesela.dev/terms/nvme-device-self-test-log/
Also known as: NVMe self-test log, NVMe log page 06h
Status: shipping

Record updated: 2026-10-15

The NVMe Device Self-test log is log page 06h, which reports current operation progress and twenty slots for results of completed or aborted self-test operations.

Note: Base 2.3 Figures 215-216 place the newest completed or aborted result first. Result 0h indicates completion without detected error; 6h and 7h indicate completed tests with failed segments, 5h an incomplete fatal or unknown test error, and Fh an empty slot. Abort codes are not passes. Current operation 0h means idle, not success, and the progress percentage is then ignored. Diagnostic NSID, failing-LBA, status-code type and status-code fields require their respective validity bits; Segment Number is meaningful for result 7h. The result NSID identifies a failure location rather than all namespaces tested. [base23-self-test] Retrieve results separately after initiating a test; successful submission alone is insufficient. [nvme-cli-self-test-manual]

Limitations:
- This is bounded result retention, not a lifetime fault history; invalid diagnostic fields must not be treated as zero observations. (sources: [base23-self-test])

Related terms:
- [nvme-device-self-test](https://hesela.dev/terms/nvme-device-self-test/)
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-error-information-log-entries](https://hesela.dev/terms/nvme-error-information-log-entries/)

Citations:
- [base23-self-test] NVM Express Base 2.3: sections 5.2.5, 5.2.12.1.7 and 8.1.8; Figures 174-177, 215-216 and 328. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [nvme-cli-self-test] nvme-cli v2.13: device_self_test and wait_self_test implementation. https://github.com/linux-nvme/nvme-cli/blob/v2.13/nvme.c (accessed 2026-10-15)
- [nvme-cli-self-test-manual] nvme-cli v2.13: Device Self-test command, result retrieval and SIGINT behavior. https://github.com/linux-nvme/nvme-cli/blob/v2.13/Documentation/nvme-device-self-test.txt (accessed 2026-10-15)
- [hesela-self-test] Hesela: NVMe self-test scope, result validity and diagnostic boundaries. https://hesela.com/analyses/nvme-health-log-coverage/#device-self-test (accessed 2026-10-15)

### NVMe Device Self-test

URL: https://hesela.dev/terms/nvme-device-self-test/
Also known as: NVMe DST, NVMe short self-test, NVMe extended self-test
Status: shipping

Record updated: 2026-10-15

NVMe Device Self-test is an optional controller-executed diagnostic capability with short and extended operations whose namespace scope is selected by the initiating command.

Note: Support is advertised by Identify Controller OACS bit 4, not inferred from a readable SMART log. For short and extended operations (codes 1h and 2h), NSID 0 excludes namespaces, a valid active specific NSID includes that namespace, and 0xffffffff includes attached namespaces accessible through the controller at start. Base 2.3 also defines Host-Initiated Refresh (code 3h), which ignores NSID; this record focuses on diagnostic short/extended tests. [base23-self-test] Command acceptance starts an operation; obtain its result from log 06h. nvme-cli v2.13 defaults to all namespaces and its --wait does not evaluate the newest result. The CLI treats omitted code or --self-test-code=0 as a log read, not submission of protocol-reserved code 0h; its status/wait paths inspect progress rather than a diagnostic verdict. [nvme-cli-self-test] Background testing can affect performance. Base 2.3 requires a short operation to abort on a controller-level reset affecting the testing controller but an extended operation to persist and resume. [base23-self-test]

Limitations:
- Segments are vendor-specific; a completed result without detected error does not certify all application data or future reliability. (sources: [base23-self-test])

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-device-self-test-log](https://hesela.dev/terms/nvme-device-self-test-log/)

Citations:
- [base23-self-test] NVM Express Base 2.3: sections 5.2.5, 5.2.12.1.7 and 8.1.8; Figures 174-177, 215-216 and 328. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [nvme-cli-self-test] nvme-cli v2.13: device_self_test and wait_self_test implementation. https://github.com/linux-nvme/nvme-cli/blob/v2.13/nvme.c (accessed 2026-10-15)
- [nvme-cli-self-test-manual] nvme-cli v2.13: Device Self-test command, result retrieval and SIGINT behavior. https://github.com/linux-nvme/nvme-cli/blob/v2.13/Documentation/nvme-device-self-test.txt (accessed 2026-10-15)
- [hesela-self-test] Hesela: NVMe self-test scope, result validity and diagnostic boundaries. https://hesela.com/analyses/nvme-health-log-coverage/#device-self-test (accessed 2026-10-15)

### NVMe Endurance Group

URL: https://hesela.dev/terms/nvme-endurance-group/
Also known as: Endurance Group, ENDGID
Status: shipping

Record updated: 2026-10-15

An NVMe Endurance Group is a scope within which an NVM subsystem manages endurance.

Note: It may contain zero or more NVM Sets. Log 09h uses ENDGID to select the group. Its Data Units Written quantum is 1000000000 bytes, not SMART 02h's 512000 bytes. Preserve log identity before conversion. [nvme-base-2-3-endurance]

Limitations:
- An Endurance Group is not a failure-independent replica or a namespace synonym. (sources: [nvme-base-2-3-endurance])

Related terms:
- [nvme-data-units-written](https://hesela.dev/terms/nvme-data-units-written/)
- [nvme-percentage-used](https://hesela.dev/terms/nvme-percentage-used/)
- [nvme-available-spare](https://hesela.dev/terms/nvme-available-spare/)

Citations:
- [nvme-base-2-3-endurance] NVM Express Base 2.3: section 3.2.3, pp. 81-82; section 5.2.12.1.10, pp. 230-232. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)

### NVMe Error Information Log Entries

URL: https://hesela.dev/terms/nvme-error-information-log-entries/
Also known as: Number of Error Information Log Entries, NEILE, num_err_log_entries, ErrorInfoLogEntryCount
Status: shipping

Record updated: 2026-10-15

NVMe Error Information Log Entries is the SMART / Health Information log counter of Error Information log entries accumulated over the controller's life.

Note: The counter at bytes 176 through 191 is separate from Error Information log 01h, which supplies error details. That log can describe failed commands or errors not associated with a particular command. Inspect the reported status and context before treating an increase as a media failure. [nvme-base-2-3-smart]

Limitations:
- The lifetime total is not the number of records returned by a particular log request and is not interchangeable with Media and Data Integrity Errors. (sources: [microsoft-nvme-health], [libnvme-error-log], [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-unexpected-power-losses](https://hesela.dev/terms/nvme-unexpected-power-losses/)
- [nvme-media-data-integrity-errors](https://hesela.dev/terms/nvme-media-data-integrity-errors/)
- [nvme-device-self-test-log](https://hesela.dev/terms/nvme-device-self-test-log/)

Citations:
- [microsoft-nvme-health] Microsoft: NVME_HEALTH_INFO_LOG, ErrorInfoLogEntryCount member. https://learn.microsoft.com/en-us/windows/win32/api/nvme/ns-nvme-nvme_health_info_log (accessed 2026-10-14)
- [libnvme-error-log] libnvme: nvme_get_log_error, request count and scope of error details. https://github.com/linux-nvme/libnvme/blob/master/doc/rst/ioctl.rst (accessed 2026-10-14)
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, p. 216: Number of Error Information Log Entries. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)

### NVMe FDP

URL: https://hesela.dev/terms/nvme-fdp/
Also known as: Flexible Data Placement, FDP
Status: limited

Record updated: 2026-10-12

An optional NVMe capability that lets a host guide write placement through placement identifiers while retaining conventional logical-block reads and writes.

Note: Grouping writes with similar invalidation lifetimes can reduce live-data copying during garbage collection; the SSD still manages logical-to-physical mapping and its media. A supported feature does not prove that the application sends useful placement information. [placement] Reclaim units, their handles and placement identifiers are different objects. [base] WARP distinguishes placement segregation from cross-handle garbage-collection pressure; its policy experiments use an emulator, not a universal device guarantee. [warp]

Advantages:
- Host-guided placement can be adopted without imposing ZNS-style sequential zone writes on every application. (sources: [overview])

Limitations:
- Lower write amplification depends on workload and placement policy; WAF = 1 is not a universal guarantee. (sources: [placement])
- QEMU interface emulation is not evidence of NAND performance or endurance. (sources: [overview], [qemu])

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [ftl](https://hesela.dev/terms/ftl/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [hot-cold-data-separation](https://hesela.dev/terms/hot-cold-data-separation/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [zns](https://hesela.dev/terms/zns/)
- [nvme-reclaim-unit](https://hesela.dev/terms/nvme-reclaim-unit/)
- [nvme-reclaim-unit-handle](https://hesela.dev/terms/nvme-reclaim-unit-handle/)
- [nvme-placement-identifier](https://hesela.dev/terms/nvme-placement-identifier/)

Citations:
- [base] NVM Express Base Specification 2.1 (5 August 2024), sections 1.5.73-74 and 1.5.82-84: FDP terminology.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)
- [overview] NVM Express. Flexible Data Placement Overview, FMS 2023, slides 6-7 and 16-23. Historical architecture overview, not a current software-support matrix.. https://nvmexpress.org/wp-content/uploads/FMS-2023-Flexible-Data-Placement-FDP-Overview.pdf (accessed 2026-10-12)
- [qemu] QEMU NVMe Emulation documentation: Flexible Data Placement, emulation configuration and deviations.. https://www.qemu.org/docs/master/system/devices/nvme.html (accessed 2026-10-12)
- [placement] Samsung. NVMe FDP: A Promising New SSD Data Placement Approach, sections 2-6. Vendor explanation and workload-specific claims.. https://semiconductor.samsung.com/news-events/tech-blog/nvme-fdp-a-promising-new-ssd-data-placement-approach/ (accessed 2026-10-12)
- [warp] Inho Song, Shoaib Asif Qazi, Javier Gonzalez, Matias Bjorling, Sam H. Noh and Huaicheng Li. Characterizing and Emulating FDP SSDs with WARP. FAST 2026, pp. 347-362, sections 3 and 5; Figures 11 and 18.. https://www.usenix.org/system/files/fast26-song.pdf (accessed 2026-10-12)

### NVMe Media and Data Integrity Errors

URL: https://hesela.dev/terms/nvme-media-data-integrity-errors/
Also known as: Media and Data Integrity Errors, MDIE, NVMe Media Errors, media_errors
Status: shipping

Record updated: 2026-10-14

NVMe Media and Data Integrity Errors is the SMART / Health Information log counter of unrecovered data-integrity errors detected by the controller.

Note: Examples include uncorrectable ECC, CRC checksum failures and LBA tag mismatches. Errors introduced by Write Uncorrectable may or may not be included. The 128-bit field occupies bytes 160 through 175 of log 02h; it is separate from the lifetime count of Error Information log entries. [nvme-base-2-3-smart]

Limitations:
- The total does not identify affected files or provide a bit-error rate: interpreting it requires the error details and an appropriate observation interval and denominator. (sources: [libnvme-smart-log], [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-critical-warning](https://hesela.dev/terms/nvme-critical-warning/)
- [nvme-unexpected-power-losses](https://hesela.dev/terms/nvme-unexpected-power-losses/)
- [nvme-error-information-log-entries](https://hesela.dev/terms/nvme-error-information-log-entries/)

Citations:
- [libnvme-smart-log] libnvme: struct nvme_smart_log, media_errors member. https://github.com/linux-nvme/libnvme/blob/master/src/nvme/types.h (accessed 2026-10-14)
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, p. 216: Media and Data Integrity Errors. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)

### NVMe-MI

URL: https://hesela.dev/terms/nvme-mi/
Also known as: NVMe-MI
Status: shipping

NVMe Management Interface for out-of-band monitoring and firmware management of SSDs and enclosures.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] NVMe-MI. https://en.wikipedia.org/wiki/NVM_Express (accessed 2026-03-26)

### NVMe multipath I/O policy

URL: https://hesela.dev/terms/nvme-multipath-io-policy/
Also known as: NVMe iopolicy
Status: shipping

Record updated: 2026-10-15

An NVMe multipath I/O policy is a host-side rule for choosing among eligible routes to one namespace.

Note: Linux v6.12 provides numa, round-robin and queue-depth policies. ANA preference takes precedence over load distribution. The queue-depth implementation compares controller-level active-request counters, not just a namespace's outstanding I/O. The module parameter supplies a default; inspect the existing subsystem's iopolicy separately. [linux-code]

Related terms:
- [multipath-nvme](https://hesela.dev/terms/multipath-nvme/)
- [asymmetric-namespace-access](https://hesela.dev/terms/asymmetric-namespace-access/)

Citations:
- [linux-code] Linux v6.12, drivers/nvme/host/multipath.c: ANA selection, controller nr_active accounting and subsystem iopolicy.. https://github.com/torvalds/linux/blob/v6.12/drivers/nvme/host/multipath.c (accessed 2026-10-15)
- [linux-ana] Linux kernel documentation: native NVMe multipath policies.. https://docs.kernel.org/admin-guide/nvme-multipath.html (accessed 2026-10-15)
- [hesela-paths] Hesela: NVMe multipath: ANA access states and Linux path policies. https://hesela.com/analyses/nvme-multipath-ana-path-selection/ (accessed 2026-10-15)

### NVMe over Fabrics

URL: https://hesela.dev/terms/nvme-of/
Status: shipping

An extension that carries NVMe commands across RDMA, Fibre Channel, or TCP networks to remote namespaces.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [alua](https://hesela.dev/terms/alua/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)

Citations:
- [c1] NVMe over Fabrics. https://en.wikipedia.org/wiki/NVMe_over_Fabrics (accessed 2026-03-26)

### NVMe Percentage Used

URL: https://hesela.dev/terms/nvme-percentage-used/
Also known as: Percentage Used, PUSED, percent_used
Status: shipping

Record updated: 2026-10-15

NVMe Percentage Used is a vendor-specific estimate of the percentage of NVM endurance consumed by actual use.

Note: At 100, the estimated endurance has been consumed, but failure is not implied. Values may exceed 100; values above 254 are encoded as 255. The controller updates the estimate once per power-on hour outside sleep. This entry describes byte 5 of SMART / Health Information log 02h, not similarly named fields with a different scope. [nvme-base-2-3-smart]

Limitations:
- This manufacturer-dependent estimate is neither a failure probability nor a direct measure of remaining calendar life; comparisons across devices require knowledge of the estimation method. (sources: [libnvme-smart-log], [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-available-spare](https://hesela.dev/terms/nvme-available-spare/)
- [nvme-data-units-written](https://hesela.dev/terms/nvme-data-units-written/)
- [nvme-endurance-group](https://hesela.dev/terms/nvme-endurance-group/)

Citations:
- [libnvme-smart-log] libnvme: struct nvme_smart_log, percent_used member. https://github.com/linux-nvme/libnvme/blob/master/src/nvme/types.h (accessed 2026-10-14)
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, p. 215: Percentage Used. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)

### NVMe placement identifier

URL: https://hesela.dev/terms/nvme-placement-identifier/
Also known as: FDP placement identifier, PID (FDP)
Status: limited

Record updated: 2026-10-12

An FDP value combining a reclaim group identifier with a namespace-scoped placement handle that maps to a reclaim unit handle.

Note: The placement identifier supplements the logical block address; it does not replace it or directly name a NAND page. [base] Namespace mappings mean that a placement handle number must not be assumed equal to the controller's RUH identifier. [nvm] Use reported status descriptors rather than assuming every namespace exposes the same identifiers. [xnvme]

Limitations:
- Available identifiers and mappings are configuration-dependent, not universal constants. (sources: [nvm], [xnvme])

Related terms:
- [nvme-fdp](https://hesela.dev/terms/nvme-fdp/)
- [nvme-reclaim-unit](https://hesela.dev/terms/nvme-reclaim-unit/)
- [nvme-reclaim-unit-handle](https://hesela.dev/terms/nvme-reclaim-unit-handle/)
- [namespace-nvme](https://hesela.dev/terms/namespace-nvme/)

Citations:
- [base] NVM Express Base Specification 2.1 (5 August 2024), sections 1.5.73-74 and 1.5.82-84: FDP terminology.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)
- [nvm] NVM Express NVM Command Set Specification 1.1 (5 August 2024), section 3.2.1.1 Figure 20 and section 4.1.6 Figure 125.. https://nvmexpress.org/wp-content/uploads/NVM-Express-NVM-Command-Set-Specification-Revision-1.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)
- [xnvme] xNVMe v0.7.5 tutorial: Flexible Data Placement, log pages and feature controls.. https://xnvme.io/tutorial/fdp/index.html (accessed 2026-10-12)

### NVMe reclaim unit handle

URL: https://hesela.dev/terms/nvme-reclaim-unit-handle/
Also known as: FDP reclaim unit handle, RUH
Status: limited

Record updated: 2026-10-12

An FDP controller resource that references one reclaim unit in each reclaim group of an endurance group.

Note: A namespace-scoped placement handle maps to an endurance-group-scoped RUH. [base] A handle can switch to another RU when its current unit fills; it is not a permanent physical address. [overview] Initially Isolated and Persistently Isolated handle types have different rules for preserving segregation during controller relocation. [samsung]

Limitations:
- An RUH does not by itself promise permanent physical isolation from every other workload. (sources: [samsung])

Related terms:
- [nvme-fdp](https://hesela.dev/terms/nvme-fdp/)
- [nvme-reclaim-unit](https://hesela.dev/terms/nvme-reclaim-unit/)
- [nvme-placement-identifier](https://hesela.dev/terms/nvme-placement-identifier/)
- [namespace-nvme](https://hesela.dev/terms/namespace-nvme/)

Citations:
- [base] NVM Express Base Specification 2.1 (5 August 2024), sections 1.5.73-74 and 1.5.82-84: FDP terminology.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)
- [overview] NVM Express. Flexible Data Placement Overview, FMS 2023, slides 6-7 and 16-23. Historical architecture overview, not a current software-support matrix.. https://nvmexpress.org/wp-content/uploads/FMS-2023-Flexible-Data-Placement-FDP-Overview.pdf (accessed 2026-10-12)
- [samsung] Samsung. Getting Started with Flexible Data Placement, v4, sections 4.1.1 and 6.1. Vendor implementation guide.. https://download.semiconductor.samsung.com/resources/white-paper/getting-started-with-fdp-v4.pdf (accessed 2026-10-12)

### NVMe reclaim unit

URL: https://hesela.dev/terms/nvme-reclaim-unit/
Also known as: FDP reclaim unit, RU (FDP)
Status: limited

Record updated: 2026-10-12

An FDP storage abstraction within a reclaim group that the controller can physically erase independently of other reclaim units.

Note: A reclaim group contains reclaim units; an RU is not a host logical-address interval or a ZNS zone. [base] In NVM Command Set 1.1, RUAMW reports the currently writable logical-block count. After conversion using the namespace's formatted LBA size, the amount may be smaller or larger than the Reclaim Unit Nominal Size. [nvm]

Limitations:
- Do not substitute a nominal RU size for the currently reported remaining write capacity. (sources: [nvm])

Related terms:
- [nvme-fdp](https://hesela.dev/terms/nvme-fdp/)
- [nvme-reclaim-unit-handle](https://hesela.dev/terms/nvme-reclaim-unit-handle/)
- [nvme-placement-identifier](https://hesela.dev/terms/nvme-placement-identifier/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [zns](https://hesela.dev/terms/zns/)

Citations:
- [base] NVM Express Base Specification 2.1 (5 August 2024), sections 1.5.73-74 and 1.5.82-84: FDP terminology.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)
- [nvm] NVM Express NVM Command Set Specification 1.1 (5 August 2024), section 3.2.1.1 Figure 20 and section 4.1.6 Figure 125.. https://nvmexpress.org/wp-content/uploads/NVM-Express-NVM-Command-Set-Specification-Revision-1.1-2024.08.05-Ratified.pdf (accessed 2026-10-12)

### NVMe SMART log

URL: https://hesela.dev/terms/nvme-smart-log/
Also known as: NVMe SMART / Health Information log, NVMe health log, NVMe log page 02h
Status: shipping

Record updated: 2026-10-16

The NVMe SMART log is the standardized log page containing controller health indicators and cumulative usage, endurance and error counters.

Note: Log identifier 02h is retrieved with Get Log Page. Its fields need separate interpretations: Critical Warning reports current conditions, Percentage Used estimates endurance consumption, and the error and power-loss counters describe different events. NVMe Base 2.3 defines the field layout in Figure 210; older specification and tool versions can use different warning-bit assignments or field names. [nvme-base-2-3-smart] Base 2.3 section 5.2.12.1.3 defines no namespace-specific information in this log: supported per-namespace requests return information identical to the controller log. Do not add repeated controller telemetry across namespace paths. [nvme-base-2-3-smart] Reading health log 02h does not execute a Device Self-test or prove support for that optional command; diagnostic progress and results use log 06h. [base23-self-test] Temperature-exposure counters use minutes, whereas HCTM action timers use seconds; Warning Composite Temperature Time may also include configured hysteresis. [nvme-base-2-3-smart]

Limitations:
- A successful log read supplies telemetry, not a guarantee of data integrity or future availability; a zero field must be interpreted according to that field's reporting rules. (sources: [nvme-base-2-3-smart], [libnvme-health-log])

Related terms:
- [smart](https://hesela.dev/terms/smart/)
- [nvme](https://hesela.dev/terms/nvme/)
- [nvme-percentage-used](https://hesela.dev/terms/nvme-percentage-used/)
- [nvme-available-spare](https://hesela.dev/terms/nvme-available-spare/)
- [nvme-critical-warning](https://hesela.dev/terms/nvme-critical-warning/)
- [nvme-data-units-written](https://hesela.dev/terms/nvme-data-units-written/)
- [nvme-unexpected-power-losses](https://hesela.dev/terms/nvme-unexpected-power-losses/)
- [nvme-media-data-integrity-errors](https://hesela.dev/terms/nvme-media-data-integrity-errors/)
- [nvme-error-information-log-entries](https://hesela.dev/terms/nvme-error-information-log-entries/)
- [nvme-controller-busy-time](https://hesela.dev/terms/nvme-controller-busy-time/)
- [nvme-composite-temperature](https://hesela.dev/terms/nvme-composite-temperature/)
- [nvme-device-self-test](https://hesela.dev/terms/nvme-device-self-test/)
- [nvme-device-self-test-log](https://hesela.dev/terms/nvme-device-self-test-log/)
- [nvme-critical-composite-temperature-time](https://hesela.dev/terms/nvme-critical-composite-temperature-time/)
- [host-controlled-thermal-management](https://hesela.dev/terms/host-controlled-thermal-management/)
- [nvme-warning-composite-temperature-time](https://hesela.dev/terms/nvme-warning-composite-temperature-time/)

Citations:
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, printed pp. 213-217: SMART / Health Information. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)
- [libnvme-health-log] libnvme: nvme_get_log_smart, SMART / Health Information retrieval. https://github.com/linux-nvme/libnvme/blob/master/doc/rst/ioctl.rst (accessed 2026-10-14)
- [base23-self-test] NVM Express Base 2.3: sections 5.2.5, 5.2.12.1.7 and 8.1.8; Figures 174-177, 215-216 and 328. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)

### NVMe Unexpected Power Losses

URL: https://hesela.dev/terms/nvme-unexpected-power-losses/
Also known as: Unexpected Power Losses, UPL, NVMe Unsafe Shutdowns, Unsafe Shutdowns, unsafe_shutdowns
Status: shipping

Record updated: 2026-10-14

NVMe Unexpected Power Losses is the SMART / Health Information log counter of main-power losses that meet the specification's incomplete-shutdown conditions.

Note: Formerly named Unsafe Shutdowns, the field counts power loss before the controller reports ready to be powered off (CSTS.SHST = 10b), plus specified out-of-band Admin-command cases in which Ignore Shutdown permits media access during or after shutdown processing. NVMe Base 2.3 places it at bytes 144 through 159. Its definition is not limited to a missing CC.SHN notification; readiness and media shutdown state matter. [nvme-base-2-3-smart]

Limitations:
- This is a power-loss event count, not a count of corrupted files: an increase does not by itself prove data loss or identify its cause, while unprotected systems may suffer corruption. (sources: [nvme-changes-2-1], [nvme-base-2-3-smart])

Related terms:
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [nvme-media-data-integrity-errors](https://hesela.dev/terms/nvme-media-data-integrity-errors/)
- [nvme-error-information-log-entries](https://hesela.dev/terms/nvme-error-information-log-entries/)

Citations:
- [nvme-changes-2-1] Changes in NVM Express Specifications (August 2024), section 1.2.23.1, p. 15: rename and revised counting conditions. https://nvmexpress.org/wp-content/uploads/NVM-Express-Revision-2.1-Changes-08_07.pdf (accessed 2026-10-14)
- [nvme-base-2-3-smart] NVM Express Base Specification 2.3, section 5.2.12.1.3, Figure 210, p. 216: Unexpected Power Losses. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-14)

### NVMe Warning Composite Temperature Time

URL: https://hesela.dev/terms/nvme-warning-composite-temperature-time/
Also known as: WCTT, warning_temp_time
Status: shipping

Record updated: 2026-10-16

NVMe Warning Composite Temperature Time is a cumulative health-log duration in minutes governed by composite-temperature thresholds and, in supporting revisions and configurations, temperature hysteresis.

Note: Base 2.3 Figure 210 defines controller-operational time with WCTEMP <= Composite Temperature < CCTEMP when TMPTHHA is zero and includes hysteresis time when TMPTHMH and TMPTHH are nonzero. Either WCTEMP or CCTEMP being zero forces this field to zero. [base23] It is distinct from Critical Composite Temperature Time and from the HCTM action timers, which use seconds. [nvmelog]

Limitations:
- A zero is not proof that a drive never ran hot; this counter is neither a complete temperature history nor a failure-probability estimate. (sources: [base23], [nvmelog])

Related terms:
- [nvme-composite-temperature](https://hesela.dev/terms/nvme-composite-temperature/)
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [host-controlled-thermal-management](https://hesela.dev/terms/host-controlled-thermal-management/)
- [thermal-throttling-ssd](https://hesela.dev/terms/thermal-throttling-ssd/)
- [nvme-critical-composite-temperature-time](https://hesela.dev/terms/nvme-critical-composite-temperature-time/)

Citations:
- [base23] NVM Express Base Specification 2.3: Figure 210 (pp. 214-217), temperature hysteresis section 5.2.26.1.3.1, HCTM Figure 417 (p. 410). https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [nvmelog] libnvme v1.15: nvme_smart_log field definitions (July 2025). https://github.com/linux-nvme/libnvme/blob/v1.15/doc/man/nvme_smart_log.2 (accessed 2026-10-15)

### NVMe

URL: https://hesela.dev/terms/nvme/
Also known as: NVM Express, NVMe protocol
Status: shipping

Record updated: 2026-10-15

Recorded firstSeen: 2014 (sources: [c1])

A host controller interface and command set optimized for PCIe-attached non-volatile memory such as NAND SSDs.

Note: NVM Express is a register-level and command-set interface originally designed for PCIe-attached non-volatile memory, later generalized across transports (PCIe, RDMA, TCP). Hosts submit commands into memory-based submission queues, ring doorbells, and reap completion queues—supporting deep parallelism without AHCI/SCSI translation layers built for spinning disks. Form factors (M.2, U.2, EDSFF, AIC) carry NVMe over PCIe; the protocol is not itself a drive shape. The NVMe specification family splits Base, I/O command sets (NVM, ZNS, KV, etc.), and transport bindings. Compared with SATA/AHCI, NVMe targets lower latency and far higher queue depth and bandwidth for flash and future NVM.

Advantages:
- Lower per-command overhead and deeper queues than legacy SATA/AHCI for flash. (sources: [c1])

Related terms:
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [ssd](https://hesela.dev/terms/ssd/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [m2](https://hesela.dev/terms/m2/)
- [u2](https://hesela.dev/terms/u2/)
- [edsff](https://hesela.dev/terms/edsff/)
- [zns](https://hesela.dev/terms/zns/)
- [ahci](https://hesela.dev/terms/ahci/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)
- [sd-express](https://hesela.dev/terms/sd-express/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)
- [nvme-device-self-test](https://hesela.dev/terms/nvme-device-self-test/)

Citations:
- [c1] NVM Express specifications. https://nvmexpress.org/specifications/ (accessed 2026-03-26)
- [n2] NVM Express — Base Specification page (spec family overview). https://nvmexpress.org/specification/nvm-express-base-specification/ (accessed 2026-10-07)
- [n3] NVM Express — NVMe overview PDF. https://nvmexpress.org/wp-content/uploads/NVMe_Overview.pdf (accessed 2026-10-07)

### O_DSYNC

URL: https://hesela.dev/terms/o-dsync/
Also known as: synchronized I/O data integrity completion
Status: shipping

Record updated: 2026-10-15

O_DSYNC is an open-file status flag requiring write operations to complete with synchronized I/O data integrity, covering data and the metadata needed to retrieve it.

Note: A file-length extension is retrieval-critical; a timestamp-only update is not. Linux compares O_DSYNC write completion to a write followed by fdatasync, not to a metadata-free write. [open-api] Handle a short write using its returned byte count; the flag does not promise that one call transfers the entire requested application record. [write-api] Like fdatasync, it is not a replacement for the containing directory's synchronization when name persistence matters. [fsync-api]

Advantages:
- Can avoid synchronization of metadata not required for data retrieval.

Limitations:
- Does not guarantee lower latency than O_SYNC on every filesystem.
- Does not provide crash-atomic writes or a multi-file transaction.
- Does not imply direct I/O or page-cache bypass.

Related terms:
- [o-sync](https://hesela.dev/terms/o-sync/)
- [fdatasync](https://hesela.dev/terms/fdatasync/)
- [fsync](https://hesela.dev/terms/fsync/)
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)
- [direct-io](https://hesela.dev/terms/direct-io/)

Citations:
- [open-api] Linux man-pages 6.19: open(2), O_SYNC and O_DSYNC. https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-15)
- [write-api] POSIX.1-2024: write(), synchronized I/O and partial writes. https://pubs.opengroup.org/onlinepubs/9799919799/functions/write.html (accessed 2026-10-15)
- [fsync-api] Linux man-pages 6.19: fsync(2), metadata and directory synchronization. https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-15)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-15)

### O_SYNC

URL: https://hesela.dev/terms/o-sync/
Also known as: synchronized I/O file integrity completion
Status: shipping

Record updated: 2026-10-15

O_SYNC is an open-file status flag requiring write operations to complete with synchronized I/O file integrity, covering data and associated file metadata.

Note: On Linux this provides the completion semantics of a write followed by fsync, whereas O_DSYNC requires only the metadata needed to retrieve the data. Neither flag requires O_DIRECT or means the page cache is bypassed. [open-api] A positive write result can be shorter than requested: check the returned byte count as well as errors before declaring the application record complete. [write-api] File synchronization does not by itself establish persistence of a newly created directory entry. [fsync-api]

Advantages:
- Requests file-integrity completion as part of each write operation.

Limitations:
- Does not make multiple writes or files one atomic transaction.
- Does not repair earlier failed writes.
- Metadata synchronization can add work; no universal latency benefit is implied.

Related terms:
- [o-dsync](https://hesela.dev/terms/o-dsync/)
- [fdatasync](https://hesela.dev/terms/fdatasync/)
- [fsync](https://hesela.dev/terms/fsync/)
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)

Citations:
- [open-api] Linux man-pages 6.19: open(2), O_SYNC and O_DSYNC. https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-15)
- [write-api] POSIX.1-2024: write(), synchronized I/O and partial writes. https://pubs.opengroup.org/onlinepubs/9799919799/functions/write.html (accessed 2026-10-15)
- [fsync-api] Linux man-pages 6.19: fsync(2), metadata and directory synchronization. https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-15)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-15)

### Object lock

URL: https://hesela.dev/terms/object-lock/
Also known as: S3 Object Lock, Object retention lock
Status: shipping

Record updated: 2026-10-15

An object lock enforces retention restrictions on a specified object version through a retention policy or hold.

Note: S3 requires versioning; enabling Object Lock and protecting a particular version are distinct configuration steps. [configure] Its retention API distinguishes GOVERNANCE and COMPLIANCE and includes event-hold settings for variable retention; do not assume every retention date was fixed at upload. [retentionapi]

Advantages:
- A protected version survives a new upload under the same key; protection is version-scoped. (sources: [lock])

Limitations:
- Governance bypass requires permission and an explicit request; it does not clear a legal hold. (sources: [manage])
- For S3 variable retention, an Inventory report reflects its generation time; query GetObjectRetention for current metadata instead of treating the report as live state. (sources: [manage])
- Neither retained bytes nor a lock label proves that encryption keys remain usable. (sources: [manage])

Related terms:
- [object-versioning](https://hesela.dev/terms/object-versioning/)
- [legal-hold](https://hesela.dev/terms/legal-hold/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [worm-storage](https://hesela.dev/terms/worm-storage/)
- [restore-test](https://hesela.dev/terms/restore-test/)

Citations:
- [configure] Amazon S3: Configuring S3 Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-configure.html (accessed 2026-10-15)
- [retentionapi] Amazon S3 API: PutObjectRetention. https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectRetention.html (accessed 2026-10-15)
- [lock] Amazon S3: Locking objects with Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html (accessed 2026-10-15)
- [manage] Amazon S3: Object Lock considerations. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html (accessed 2026-10-15)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-15)

### Object storage

URL: https://hesela.dev/terms/object-storage/
Status: shipping

Record updated: 2026-10-15

Object storage organizes data as independently addressed objects with associated metadata, accessed through object identifiers or keys rather than a block-device interface.

Note: An object API's guarantees depend on the provider and operation. In Amazon S3, an object key identifies an object within a bucket, with a version ID identifying a retained version when versioning is enabled. Distinguish the object's bytes, its ETag validator, explicitly named checksums, and any version ID when designing integrity checks or concurrent updates.

Advantages:
- Objects package data with descriptive metadata and can be addressed by bucket and key, with optional version-specific retrieval in S3. (sources: [c2])
- S3 supports multipart transfers and conditional publication, allowing large-object transfer workflows to combine independent part uploads with a destination-object precondition. (sources: [c3], [c4])

Limitations:
- Object-storage interfaces do not imply identical consistency guarantees across providers; S3's strong consistency and single-key atomic updates still do not provide a multi-key transaction. (sources: [c2], [c7])
- An S3 ETag is not a universal full-object checksum: multipart construction and encryption affect its meaning, and metadata-only changes are not reflected in it. (sources: [c5])
- S3 versioning preserves versions for recovery but does not reject a stale application update; preventing lost updates requires an appropriate conditional-write protocol or other coordination. (sources: [c4], [c6], [c7])

Related terms:
- [file-storage](https://hesela.dev/terms/file-storage/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [cold-archive](https://hesela.dev/terms/cold-archive/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [entity-tag](https://hesela.dev/terms/entity-tag/)
- [multipart-upload](https://hesela.dev/terms/multipart-upload/)
- [conditional-write](https://hesela.dev/terms/conditional-write/)
- [object-versioning](https://hesela.dev/terms/object-versioning/)
- [object-version-id](https://hesela.dev/terms/object-version-id/)

Citations:
- [c1] Object storage. https://en.wikipedia.org/wiki/Object_storage (accessed 2026-03-26)
- [c2] Amazon S3: Objects, keys, version IDs, and data consistency. https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html (accessed 2026-10-12)
- [c3] Amazon S3: Uploading and copying objects using multipart upload. https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html (accessed 2026-10-12)
- [c4] Amazon S3: How to prevent object overwrites with conditional writes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/conditional-writes.html (accessed 2026-10-12)
- [c5] Amazon S3 API Reference: Object, ETag semantics. https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html (accessed 2026-10-12)
- [c6] Amazon S3: Retaining multiple versions of objects with S3 Versioning. https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html (accessed 2026-10-12)
- [c7] Object ETags: checksums and conditional writes are different. https://hesela.com/analyses/object-etags-checksums-conditional-writes/ (accessed 2026-10-12)

### Object version ID

URL: https://hesela.dev/terms/object-version-id/
Also known as: S3 version ID, VersionId
Status: shipping

Record updated: 2026-10-15

An object version ID is a service-assigned identifier used with a bucket and key to select an S3 object version.

Note: Scope: S3 general-purpose buckets. Generated S3 IDs are opaque, not chronological counters or checksums. A version can also be a delete marker rather than data. The literal null ID is a special case: a same-key write while versioning is suspended can replace that version's contents without changing its ID. [s3-version-ids] [s3-suspended-write]

Advantages:
- An explicit versionId selects a retained revision for GET even when it is not current, subject to s3:GetObjectVersion permission. (sources: [get])

Limitations:
- Existing objects retain null IDs when versioning is first enabled; generated version IDs are not retroactively assigned. (sources: [s3-version-ids])
- A version identifier does not prevent an authorized permanent deletion of that version. (sources: [s3-delete-api])
- A checksum must still be verified separately; selecting a version is not proof that downloaded bytes match the expected data. (sources: [get])

Related terms:
- [object-versioning](https://hesela.dev/terms/object-versioning/)
- [delete-marker](https://hesela.dev/terms/delete-marker/)
- [entity-tag](https://hesela.dev/terms/entity-tag/)
- [object-storage](https://hesela.dev/terms/object-storage/)

Citations:
- [s3-version-ids] Amazon S3: How S3 Versioning works, version IDs. https://docs.aws.amazon.com/AmazonS3/latest/userguide/versioning-workflows.html (accessed 2026-10-15)
- [s3-suspended-write] Amazon S3: Adding objects to versioning-suspended buckets. https://docs.aws.amazon.com/AmazonS3/latest/userguide/AddingObjectstoVersionSuspendedBuckets.html (accessed 2026-10-15)
- [s3-delete-api] Amazon S3 API: DeleteObject, versioning-dependent effects. https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteObject.html (accessed 2026-10-15)
- [get] Amazon S3 API: GetObject, version selection and checksum fields. https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html (accessed 2026-10-15)
- [hesela-object] Hesela: Object ETags, checksums and conditional writes. https://hesela.com/analyses/object-etags-checksums-conditional-writes/ (accessed 2026-10-15)

### Object versioning

URL: https://hesela.dev/terms/object-versioning/
Also known as: Object storage versioning, S3 Versioning
Status: shipping

Record updated: 2026-10-15

Object versioning retains separately identifiable revisions of an object under the same key.

Note: In a versioning-enabled S3 general-purpose bucket, a replacement creates a new current version and retains the previous one; a delete without versionId creates a marker. Versions are complete objects, not differential backups. [version] Suspended versioning differs: new writes use null and replace any same-key null version, while non-null versions remain. [s3-suspended-write]

Advantages:
- A known version ID identifies which retained revision a recovery process requests. (sources: [get])

Limitations:
- Versioning alone does not prohibit permanent deletion of a version by an authorized caller. (sources: [version])
- For a current delete marker, the documented GET response without versionId is 404 even when older versions remain; authorization failures can differ. (sources: [marker], [get])
- With versioning suspended, a DELETE without versionId can permanently remove the null-version payload before inserting a null marker. (sources: [s3-suspended-delete])

Related terms:
- [object-storage](https://hesela.dev/terms/object-storage/)
- [object-lock](https://hesela.dev/terms/object-lock/)
- [conditional-write](https://hesela.dev/terms/conditional-write/)
- [backup-manifest](https://hesela.dev/terms/backup-manifest/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [delete-marker](https://hesela.dev/terms/delete-marker/)
- [object-version-id](https://hesela.dev/terms/object-version-id/)

Citations:
- [version] Amazon S3: How S3 Versioning works. https://docs.aws.amazon.com/AmazonS3/latest/userguide/versioning-workflows.html (accessed 2026-10-15)
- [marker] Amazon S3: Working with delete markers. https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeleteMarker.html (accessed 2026-10-15)
- [get] Amazon S3 API: GetObject. https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html (accessed 2026-10-15)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-15)
- [s3-suspended-write] Amazon S3: Adding objects to versioning-suspended buckets. https://docs.aws.amazon.com/AmazonS3/latest/userguide/AddingObjectstoVersionSuspendedBuckets.html (accessed 2026-10-15)
- [s3-suspended-delete] Amazon S3: Deleting objects from versioning-suspended buckets. https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectsfromVersioningSuspendedBuckets.html (accessed 2026-10-15)
- [hesela-object] Hesela: Object ETags, checksums and conditional writes. https://hesela.com/analyses/object-etags-checksums-conditional-writes/ (accessed 2026-10-15)

### Open-channel SSD

URL: https://hesela.dev/terms/open-channel-ssd/
Also known as: OCSSD, OC SSD
Status: unknown

Record updated: 2026-10-15

An open-channel SSD exposes media parallelism and placement controls so host software can manage data placement and I/O scheduling.

Note: Open-channel does not mean controller-free raw NAND. LightNVM separates host-managed placement and scheduling from device-specific ECC and read-threshold tuning; its pblk host layer can expose an ordinary block device. [lightnvm] The project documentation describes host-side garbage collection while retaining media-centric work on the controller, so the exact responsibility split must be tied to the interface and implementation. [project] In the Perseus deployment, CPU preemption of host-managed SSD work caused slowdowns in two clusters; this is a specific software mechanism, not a hardware failure rate. [perseus]

Limitations:
- Host control enables workload-specific policies; it does not by itself guarantee a latency bound. (sources: [lightnvm])

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [zns](https://hesela.dev/terms/zns/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [garbage-collection-host](https://hesela.dev/terms/garbage-collection-host/)
- [fail-slow](https://hesela.dev/terms/fail-slow/)
- [slowdown-ratio](https://hesela.dev/terms/slowdown-ratio/)

Citations:
- [lightnvm] Bjorling, Gonzalez and Bonnet. LightNVM: The Linux Open-Channel SSD Subsystem. FAST 2017, sections 2.3 and 4.2.. https://www.usenix.org/system/files/conference/fast17/fast17-bjorling.pdf (accessed 2026-10-15)
- [project] Open-Channel Solid State Drives project documentation: division of responsibility between host and SSD.. https://openchannelssd.readthedocs.io/en/latest/ (accessed 2026-10-15)
- [perseus] Lu et al. Perseus. FAST 2023, section 6.1.1: host CPU scheduling in two open-channel clusters.. https://www.usenix.org/system/files/fast23-lu.pdf#page=12 (accessed 2026-10-15)

### Open-file-description lock

URL: https://hesela.dev/terms/open-file-description-lock/
Also known as: OFD-owned file lock, OFD record lock
Status: shipping

Record updated: 2026-10-16

An open-file-description lock is a byte-range file lock owned by an open file description rather than by a process.

Note: Linux supports the fcntl F_OFD_* operations from 3.15. Duplicated descriptors share ownership; independent opens can conflict. Automatic release occurs on the last close of that description, unlike traditional process-owned record locks, which a close of any descriptor for the file can release. Explicit unlocking is separate. Although flock() also has open-description ownership on Linux, it is not this byte-range API. [fcntl] In Hesela's local Linux observation, a duplicate could reapply the held lock, closing the initial holder did not release it while the duplicate stayed open, and explicit unlock through the duplicate released it. These are ownership observations, not crash tests. [hesela-ofd]

Limitations:
- Conflicting traditional fcntl and OFD record locks interact, even within one process. (sources: [fcntl])
- Hesela exercised nonblocking calls in one Linux process; this does not validate fork inheritance, thread scheduling, network filesystems or other platforms. (sources: [hesela-ofd])

Related terms:
- [advisory-file-lock](https://hesela.dev/terms/advisory-file-lock/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [atomic-rename](https://hesela.dev/terms/atomic-rename/)
- [process-associated-record-lock](https://hesela.dev/terms/process-associated-record-lock/)

Citations:
- [fcntl] Linux man-pages 6.19: fcntl_locking(2), record and open-file-description locks. https://man7.org/linux/man-pages/man2/fcntl_locking.2.html (accessed 2026-10-16)
- [hesela-locks] Hesela: A lock follows the opened file, not the replacement name. https://hesela.com/analyses/atomic-rename-directory-durability/#lock-identity (accessed 2026-10-16)
- [hesela-ofd] Hesela: Native OFD ownership experiment, source, controls and observations. https://hesela.com/analyses/atomic-rename-directory-durability/#ofd-lifetime (accessed 2026-10-16)

### Open file description

URL: https://hesela.dev/terms/open-file-description/
Also known as: OFD
Status: shipping

Record updated: 2026-10-16

An open file description is a system-wide open-file object referenced by one or more file descriptors and holding state such as the current file offset and file status flags.

Note: On Linux, each successful open creates a new open file description; dup and descriptors inherited through fork refer to the existing object. In the generic writeback-error path, that object's f_wb_err cursor is shared by its aliases. This source-code relationship explains why two descriptor numbers need not provide independent error observations. A descriptor opened before pathname replacement keeps referring to the file it originally opened; a fresh open() after replacement can reach a different inode. Separate opens of the same inode do not share an open file description merely because the inode matches.

Limitations:
- File descriptor flags, such as close-on-exec, are not shared state of the open file description.
- Sharing an offset or error cursor does not establish persistence or application-level recovery.

Related terms:
- [fsync](https://hesela.dev/terms/fsync/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [errseq-t](https://hesela.dev/terms/errseq-t/)
- [atomic-rename](https://hesela.dev/terms/atomic-rename/)
- [inode](https://hesela.dev/terms/inode/)
- [hard-link](https://hesela.dev/terms/hard-link/)
- [unlink](https://hesela.dev/terms/unlink/)
- [syncfs](https://hesela.dev/terms/syncfs/)
- [o-sync](https://hesela.dev/terms/o-sync/)
- [advisory-file-lock](https://hesela.dev/terms/advisory-file-lock/)
- [open-file-description-lock](https://hesela.dev/terms/open-file-description-lock/)

Citations:
- [open-api] Linux man-pages 6.19: open(2), open file descriptions. https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-13)
- [dup-api] Linux man-pages 6.19: dup(2), shared open file descriptions. https://man7.org/linux/man-pages/man2/dup.2.html (accessed 2026-10-13)
- [filemap-source] Linux v6.12: file_check_and_advance_wb_err in mm/filemap.c. https://github.com/torvalds/linux/blob/v6.12/mm/filemap.c (accessed 2026-10-13)
- [hesela-fsync] Hesela: Two descriptors are not necessarily two error observers. https://hesela.com/analyses/fsync-failure-retry-durability/#descriptor-sharing (accessed 2026-10-13)
- [hesela-namespace] Hesela: The name changes; existing readers do not. https://hesela.com/analyses/atomic-rename-directory-durability/#namespace-identity (accessed 2026-10-15)
- [hesela-locks] Hesela: A lock follows the opened file, not the replacement name. https://hesela.com/analyses/atomic-rename-directory-durability/#lock-identity (accessed 2026-10-16)

### Open-loop load

URL: https://hesela.dev/terms/open-loop-load/
Also known as: Open workload model
Status: unknown

Record updated: 2026-10-11

An open-loop load model schedules request arrivals independently of earlier request completions.

Note: Finite generators still have capacity limits; retain scheduled, submitted, rejected and completed counts to check whether the intended arrival policy was achieved.

Related terms:
- [closed-loop-load](https://hesela.dev/terms/closed-loop-load/)
- [coordinated-omission](https://hesela.dev/terms/coordinated-omission/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)

Citations:
- [schroeder] Schroeder, Wierman and Harchol-Balter. Open Versus Closed: A Cautionary Tale. USENIX NSDI 2006, sections 2-5 and 7.. https://www.usenix.org/legacy/events/nsdi06/tech/full_papers/schroeder/schroeder_html/index.html (accessed 2026-10-11)
- [wrk2] Gil Tene, wrk2: scheduled-arrival latency and coordinated omission; maintainer documentation, not an SSD benchmark.. https://github.com/giltene/wrk2 (accessed 2026-10-11)
- [hesela-latency] Hesela: synthetic arrival cohorts, timing boundaries and percentile pooling. https://hesela.com/analyses/storage-latency-coordinated-omission/ (accessed 2026-10-11)

### Open-zone limit

URL: https://hesela.dev/terms/open-zone-limit/
Also known as: maximum open zones
Status: shipping

Record updated: 2026-10-14

An open-zone limit caps the zones simultaneously in implicitly open or explicitly open states.

Note: Closing a partially written zone releases an open slot but leaves an active slot occupied. Decoded Linux zonefs maximum counts use zero for no limit; do not apply that convention to raw NVMe MAR/MOR fields. Raw MOR = 0 permits one open zone; 0xffffffff denotes no advertised limit, and other raw values decode to value + 1.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [active-zone-limit](https://hesela.dev/terms/active-zone-limit/)
- [zone-append](https://hesela.dev/terms/zone-append/)
- [zone-finish](https://hesela.dev/terms/zone-finish/)

Citations:
- [zonefs] Linux kernel documentation, zonefs: sequential files, explicit-open and runtime sysfs attributes.. https://docs.kernel.org/filesystems/zonefs.html (accessed 2026-10-11)
- [zns-spec] NVM Express, Zoned Namespace Command Set Specification, revision 1.1 (cover: 18 May 2021), Figure 48, sections 2.1.1.4, 3.4.1, 3.4.3 and Annex A. Copyright 2007-2021 NVM Express, Inc. ALL RIGHTS RESERVED.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-1.1-2021.06.02-Ratified.pdf (accessed 2026-10-14)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-11)

### Intel Optane

URL: https://hesela.dev/terms/optane/
Also known as: Optane SSD, Optane memory
Status: eol

Recorded firstSeen: 2017 (sources: [c1])

Recorded lastSeen: 2022 (sources: [c2])

Intel's brand for storage products built on 3D XPoint non-volatile memory before the business was wound down.

Note: Intel Optane was Intel’s product brand for devices built on 3D XPoint media: NVMe SSDs, small client caching modules, and datacenter persistent memory (DCPMM) DIMMs. It sat in the storage-class memory gap—lower latency and different endurance economics than NAND, but not DRAM. Micron exited 3D XPoint in 2021; Intel announced in 2022 that it would wind down Optane and stop future product development while supporting existing warranties. Treat Optane as a legacy technology family for archival understanding and remaining installed base—not an active procurement roadmap. Media details live under the 3D XPoint term; Optane is the Intel-branded productization.

Related terms:
- [3d-xpoint](https://hesela.dev/terms/3d-xpoint/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)

Citations:
- [c1] Intel Optane SSD 900p series brief. https://www.intel.com/content/www/us/en/products/docs/memory-storage/optane-memory-series/intel-optane-ssd-900p-series-brief.html (accessed 2026-03-26)
- [c2] Intel winding down Optane memory business. https://www.intel.com/content/www/us/en/newsroom/news/intel-winding-down-optane-memory-business.html (accessed 2026-03-26)
- [n3] Intel — Optane business update (warranty and support implications). https://www.intel.com/content/www/us/en/support/articles/000091826/memory-and-storage.html (accessed 2026-10-07)
- [n4] Intel — Customer support options for discontinued Optane SSDs. https://www.intel.com/content/www/us/en/support/articles/000024320/technologies/memory-and-storage.html (accessed 2026-10-07)

### Optical archival storage

URL: https://hesela.dev/terms/optical-archival/
Also known as: write-once optical archive
Status: limited

Record updated: 2026-10-15

Optical archival storage preserves data on removable laser-readable media as part of a long-term retention and migration workflow.

Note: Media longevity and recoverability are separate claims: a usable archive also needs a functioning reader and software [locfaq]. The NIST/LC final report estimates a survival percentile under temperature/humidity assumptions for products purchased in 2005; it does not certify present-day brands or every file on a disc [nist2007]. Preserve format, recorder, initial error measurements, scan coverage and independent content-verification records. A lifetime estimate is not a replacement for verified copies or migration planning [analysis].

Related terms:
- [glass-storage](https://hesela.dev/terms/glass-storage/)
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)
- [tape](https://hesela.dev/terms/tape/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [optical-bler](https://hesela.dev/terms/optical-bler/)
- [dvd-pi-sum8](https://hesela.dev/terms/dvd-pi-sum8/)
- [optical-disc-lifetime-estimate](https://hesela.dev/terms/optical-disc-lifetime-estimate/)

Citations:
- [nist2007] NIST/Library of Congress. Optical Disc Longevity Study, final report (September 2007), sections 1-5 and Appendix I.. https://www.loc.gov/preservation/resources/rt/NIST_LC_OpticalDiscLongevity.pdf (accessed 2026-10-15)
- [locfaq] Library of Congress: Audio/Visual Materials FAQ, preservation and playback-system longevity.. https://www.loc.gov/preservation/about/faqs/audio.html (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates, error thresholds and uncertainty. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### CD block error rate (BLER)

URL: https://hesela.dev/terms/optical-bler/
Also known as: CD BLER
Status: unknown

Record updated: 2026-10-15

CD BLER counts blocks containing detectable errors per second at the input to the C1 decoder.

Note: BLER is measured before correction, unlike E32 errors that remain uncorrectable at the C2 stage [nist2004]. The cited studies use 220 blocks/s as the CD threshold; this is not a count of lost files and must not be applied to DVD PI Sum8 or Blu-ray. Preserve analyzer settings and scan coverage when comparing measurements.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [dvd-pi-sum8](https://hesela.dev/terms/dvd-pi-sum8/)

Citations:
- [nist2004] Slattery, Lu, Zheng, Byers and Tang. Stability Comparison of Recordable Optical Discs: A Study of Error Rates in Harsh Conditions. J. Res. NIST 109(5), 517-524 (2004), sections 2-4.. https://nvlpubs.nist.gov/nistpubs/jres/109/5/j95sla.pdf (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates, error thresholds and uncertainty. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### Optical-disc lifetime estimate

URL: https://hesela.dev/terms/optical-disc-lifetime-estimate/
Also known as: standardized optical life expectancy
Status: unknown

Record updated: 2026-10-15

An optical-disc lifetime estimate predicts time to a defined error threshold for a stated population percentile and storage environment under an aging model.

Note: The NIST/LC 2007 method combines accelerated temperature/humidity tests, an Eyring model and log-normal lifetimes at 25 degrees Celsius and 50% relative humidity [nist2007]. Its 95% survival target differs from its 95% confidence calculation. The report concerns 2005 products and selected test bands; it is not a warranty, a complete-disc readability certificate or a modern-media forecast.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [optical-bler](https://hesela.dev/terms/optical-bler/)

Citations:
- [nist2007] NIST/Library of Congress. Optical Disc Longevity Study, final report (September 2007), sections 1-5 and Appendix I.. https://www.loc.gov/preservation/resources/rt/NIST_LC_OpticalDiscLongevity.pdf (accessed 2026-10-15)
- [analysis] Hesela: optical-disc lifetime estimates, error thresholds and uncertainty. https://hesela.com/analyses/optical-disc-lifetime-estimates/ (accessed 2026-10-15)

### Optical jukebox

URL: https://hesela.dev/terms/optical-jukebox/
Status: limited

Robotic libraries swapping optical discs for archival retrieval.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [blu-ray-archive](https://hesela.dev/terms/blu-ray-archive/)

Citations:
- [c1] Optical jukebox. https://en.wikipedia.org/wiki/Optical_disc (accessed 2026-03-26)

### Over-provisioning

URL: https://hesela.dev/terms/over-provisioning/
Also known as: SSD over-provisioning, overprovisioning
Status: shipping

Record updated: 2026-10-12

SSD over-provisioning is flash capacity withheld from host-addressable user storage to support controller management such as garbage collection and wear leveling.

Note: State the denominator: for physical capacity P and logical capacity L in the same units, reserve/logical is (P-L)/L while reserve/physical is (P-L)/P. A 20% physical-basis reserve is 25% on the logical basis. Filesystem free space alone does not establish the controller's valid-page state.

Limitations:
- Capacity percentages do not uniquely predict write amplification; workload, placement and cleaning policy also matter. (sources: [desnoyers])

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [ssd](https://hesela.dev/terms/ssd/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [greedy-garbage-collection](https://hesela.dev/terms/greedy-garbage-collection/)
- [hot-cold-data-separation](https://hesela.dev/terms/hot-cold-data-separation/)
- [discard](https://hesela.dev/terms/discard/)

Citations:
- [c1] Over-provisioning. https://en.wikipedia.org/wiki/Write_amplification (accessed 2026-03-26)
- [xiang] Luojie Xiang and Brian M. Kurkoski. An Improved Analytic Expression for Write Amplification in NAND Flash. arXiv:1110.4245v1 (19 October 2011), sections II-IV, equation 12 and Table I.. https://arxiv.org/abs/1110.4245v1 (accessed 2026-10-11)
- [desnoyers] Peter Desnoyers. Analytic Modeling of SSD Write Performance. SYSTOR 2012, sections 2-6, Tables 1-2. DOI: 10.1145/2367589.2367603.. https://www.ccs.neu.edu/home/pjd/papers/pjd-systor12.pdf (accessed 2026-10-11)
- [kingston] Kingston. Understanding SSD Over-provisioning (OP). March 2019; user-capacity denominator.. https://www.kingston.com/en/blog/pc-performance/overprovisioning (accessed 2026-10-11)
- [hesela-op] Hesela: SSD over-provisioning, capacity denominators and analytical-model limits. https://hesela.com/analyses/ssd-overprovisioning-denominators/ (accessed 2026-10-11)

### Page cache

URL: https://hesela.dev/terms/page-cache/
Also known as: Linux page cache
Status: shipping

Record updated: 2026-10-15

The page cache is the kernel-managed memory that holds cached file contents for access and writeback.

Note: Linux iomap manages cached folios and their up-to-date and dirty state. Its direct-I/O path still flushes dirty cached data and invalidates cached ranges where required, so bypassing cached transfers does not eliminate coherence work. [iomap]

Advantages:
- Can serve reusable file contents from memory.

Limitations:
- A cached copy is not an independent backup or proof of durable storage.

Related terms:
- [buffered-io](https://hesela.dev/terms/buffered-io/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [posix-fadv-noreuse](https://hesela.dev/terms/posix-fadv-noreuse/)
- [posix-fadv-dontneed](https://hesela.dev/terms/posix-fadv-dontneed/)
- [rwf-dontcache](https://hesela.dev/terms/rwf-dontcache/)

Citations:
- [iomap] Linux v6.17: iomap supported file operations, sections 2.2.1-2.2.3.. https://www.kernel.org/doc/html/v6.17/filesystems/iomap/operations.html (accessed 2026-10-14)

### Page LSN

URL: https://hesela.dev/terms/page-lsn/
Also known as: pageLSN, page_LSN
Status: shipping

Record updated: 2026-10-15

A page LSN records the log sequence number of the latest logged change reflected in a database page under the engine's recovery protocol.

Note: In original ARIES, redo uses the page LSN, after dirty-page-table and recovery-LSN filtering, to avoid reapplying an update already present on the page. The page state and its LSN must agree; the number alone does not detect torn or corrupt pages. Undo does not reuse that redo test: history has first been repeated, and compensation records track rollback progress. [aries] A page LSN is not the global durable-log flush position or a timestamp, and this description must not be generalized to every engine. [aries-beyond]

Related terms:
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [compensation-log-record](https://hesela.dev/terms/compensation-log-record/)
- [torn-write](https://hesela.dev/terms/torn-write/)
- [fuzzy-checkpoint](https://hesela.dev/terms/fuzzy-checkpoint/)

Citations:
- [aries] Mohan, Haderle, Lindsay, Pirahesh and Schwarz. ARIES. ACM TODS 17(1), 1992, sections 3, 5.2 and 6.2-6.3.. https://www.cs.cmu.edu/~15849g/readings/mohan92.pdf (accessed 2026-10-15)
- [aries-beyond] C. Mohan. Repeating History Beyond ARIES. VLDB 1999, sections 3.2.1-3.2.2.. https://www.vldb.org/conf/1999/P1.pdf (accessed 2026-10-15)
- [hesela-wal] Hesela: ARIES rollback progress, with a synthetic executable trace. https://hesela.com/analyses/wal-checkpoints-torn-pages/#aries-rollback (accessed 2026-10-15)

### Parity declustering

URL: https://hesela.dev/terms/parity-declustering/
Also known as: declustered parity
Status: shipping

Record updated: 2026-10-13

Parity declustering places parity groups across a larger device pool to distribute reconstruction work.

Note: Stripe width and placement scope are separate parameters; lower peak survivor load does not by itself establish shorter repair time.

Related terms:
- [raid-5](https://hesela.dev/terms/raid-5/)
- [distributed-spare](https://hesela.dev/terms/distributed-spare/)
- [repair-read-amplification](https://hesela.dev/terms/repair-read-amplification/)
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)

Citations:
- [holland1992] Mark Holland and Garth A. Gibson. Parity Declustering for Continuous Operation in Redundant Disk Arrays. ASPLOS 1992, pp. 23-35; sections 2, 4-8.. https://www.cs.cmu.edu/~riedel/ftp/Declustering/ASPLOS.pdf (accessed 2026-10-13)
- [hesela-declustering] Parity declustering: less load per disk, not fewer reads. https://hesela.com/analyses/parity-declustering-rebuild-load/ (accessed 2026-10-13)

### Parity pollution

URL: https://hesela.dev/terms/parity-pollution/
Status: unknown

Record updated: 2026-10-11

Parity pollution is propagation of incorrect data into redundancy information through parity calculations.

Note: The FAST 2008 model demonstrates why maintenance reads need suitable validation before their data influences reconstruction or parity updates; it does not show that all scrubbing is harmful.

Related terms:
- [lost-write](https://hesela.dev/terms/lost-write/)
- [misdirected-write](https://hesela.dev/terms/misdirected-write/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [raid-5](https://hesela.dev/terms/raid-5/)

Citations:
- [parity] Krioukov et al. Parity Lost and Parity Regained. FAST 2008, sections 3-4.. https://www.usenix.org/legacy/event/fast08/tech/full_papers/krioukov/krioukov_html/index.html (accessed 2026-10-11)
- [hesela-integrity] Hesela: checksum, identity and freshness boundaries with executable synthetic examples. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-11)

### Parity RAID

URL: https://hesela.dev/terms/parity-raid/
Status: shipping

Record updated: 2026-10-15

Parity RAID uses computed redundancy across striped data to reconstruct missing chunks without storing complete mirrored copies.

Note: Distributed parity occupies the equivalent capacity of one member in RAID 5 or two in conventional RAID 6, rather than requiring dedicated parity devices [md-layout]. This is coded redundancy, not a full duplicate of the data. Parity consistency after an interrupted update depends on the write and recovery protocol [md]. A RAID level describes a reconstruction capability, not a measured probability of data loss [hesela-parity].

Limitations:
- An interrupted update can invalidate parity needed to recover a missing member; review the write-hole protection policy. (sources: [md])

Related terms:
- [raid-5](https://hesela.dev/terms/raid-5/)
- [raid-6](https://hesela.dev/terms/raid-6/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [partial-parity-log](https://hesela.dev/terms/partial-parity-log/)
- [write-intent-bitmap](https://hesela.dev/terms/write-intent-bitmap/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)

Citations:
- [md] Linux v6.12: RAID arrays, dirty/degraded assembly and bitmap metadata. https://github.com/torvalds/linux/blob/v6.12/Documentation/admin-guide/md.rst (accessed 2026-10-11)
- [ppl] Linux v6.12: Partial Parity Log. https://github.com/torvalds/linux/blob/v6.12/Documentation/driver-api/md/raid5-ppl.rst (accessed 2026-10-11)
- [hesela-raid] Hesela: RAID write hole, bitmap and PPL. https://hesela.com/analyses/raid-write-hole-bitmap-ppl/ (accessed 2026-10-11)
- [md-layout] mdadm md(4): RAID4/5/6 layouts and capacity (revision e5a1d3e). https://github.com/md-raid-utilities/mdadm/blob/e5a1d3ebaf95c29a7a5cf0d72fdc568138fd86dd/md.4 (accessed 2026-10-15)
- [hesela-parity] Hesela: RAID 5/6 capacity and per-stripe recovery boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#parity-budget-heading (accessed 2026-10-15)

### Partial Parity Log

URL: https://hesela.dev/terms/partial-parity-log/
Also known as: PPL
Status: shipping

Partial Parity Log is a Linux MD RAID5 mechanism that records the XOR of untouched stripe chunks before dispatching data and parity updates.

Note: The log resides on the stripe's parity member. Its recovery scope is narrower than a data journal.

Advantages:
- No separate journal device is required. (sources: [ppl])

Limitations:
- Does not guarantee preservation of in-flight data; loss of a modified member is outside that protection. (sources: [ppl])
- The documented Linux MD implementation does not combine PPL with a write-intent bitmap. (sources: [ppl])

Related terms:
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [write-intent-bitmap](https://hesela.dev/terms/write-intent-bitmap/)

Citations:
- [ppl] Linux v6.12: Partial Parity Log. https://github.com/torvalds/linux/blob/v6.12/Documentation/driver-api/md/raid5-ppl.rst (accessed 2026-10-11)
- [hesela-raid] Hesela: RAID write hole, bitmap and PPL. https://hesela.com/analyses/raid-write-hole-bitmap-ppl/ (accessed 2026-10-11)

### Partial quorum

URL: https://hesela.dev/terms/partial-quorum/
Also known as: Non-strict quorum
Status: research

Record updated: 2026-10-14

A partial quorum configuration allows a read response set and a write acknowledgement set that need not overlap.

Note: With uniform R- and W-member subsets of the same N replicas, non-intersection has probability C(N-W,R)/C(N,R); missing all k recent writes raises it to the kth power only under independent write selections. [pbs] Partial concerns overlap, whereas sloppy quorum concerns fallback membership. [dynamo]

Limitations:
- This sampling model is not a production stale-read rate or a deterministic time bound. (sources: [pbs])

Related terms:
- [quorum-intersection](https://hesela.dev/terms/quorum-intersection/)
- [sloppy-quorum](https://hesela.dev/terms/sloppy-quorum/)

Citations:
- [pbs] Bailis et al. Probabilistically Bounded Staleness for Practical Partial Quorums. PVLDB 5(8), 776-787 (2012), equations 1-2.. https://www.vldb.org/pvldb/vol5/p776_peterbailis_vldb2012.pdf (accessed 2026-10-14)
- [dynamo] DeCandia et al. Dynamo: Amazon's Highly Available Key-value Store. SOSP 2007, sections 4.5-4.6.. https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf (accessed 2026-10-14)
- [hesela-model] Hesela: exact partial-quorum examples, assumptions and executable source. https://hesela.dev/data/partial-quorum-examples.json (accessed 2026-10-14)

### Partition alignment

URL: https://hesela.dev/terms/partition-alignment/
Also known as: partition start alignment
Status: shipping

Record updated: 2026-10-12

Partition alignment places a partition's starting offset on boundaries appropriate to the storage topology reported by the underlying stack.

Note: An aligned partition does not ensure that every subsequent request has an aligned offset and length. The companion explanation separates partition geometry, individual I/O and persistence.

Advantages:
- Avoids adding a partition-start displacement to otherwise aligned requests. (sources: [microsoft-af])

Limitations:
- Linux exposes device and partition alignment offsets separately from preferred I/O sizes. (sources: [linux-abi])
- Unbuffered I/O may also impose buffer-address and request-size requirements. (sources: [microsoft-buffering])

Related terms:
- [advanced-format](https://hesela.dev/terms/advanced-format/)
- [ssd](https://hesela.dev/terms/ssd/)
- [hdd](https://hesela.dev/terms/hdd/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [physical-sector](https://hesela.dev/terms/physical-sector/)
- [512e](https://hesela.dev/terms/512e/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)

Citations:
- [c1] Partition alignment. https://en.wikipedia.org/wiki/Partition_alignment (accessed 2026-03-26)
- [microsoft-af] Microsoft: Advanced format disk compatibility update, sector formats and alignment issues. https://learn.microsoft.com/en-us/windows/compatibility/advanced-format-disk-compatibility-update (accessed 2026-10-12)
- [linux-abi] Linux 6.12: stable sysfs block ABI, sector sizes and I/O topology. https://raw.githubusercontent.com/torvalds/linux/v6.12/Documentation/ABI/stable/sysfs-block (accessed 2026-10-12)
- [microsoft-buffering] Microsoft: File buffering, alignment and file access requirements. https://learn.microsoft.com/en-us/windows/win32/fileio/file-buffering (accessed 2026-10-12)
- [hesela-sector-alignment] Hesela: 512e, 4Kn and alignment: geometry is not durability. https://hesela.com/analyses/sector-sizes-alignment-not-durability/ (accessed 2026-10-12)

### Partitioned filter

URL: https://hesela.dev/terms/partitioned-filter/
Also known as: Partitioned SST filter
Status: shipping

Record updated: 2026-10-13

An SST membership-filter layout split into independently loadable partitions located through a top-level index.

Note: Partitioning changes the unit fetched and retained in the cache, so cold ranges need not bring in the whole file's filter. It does not itself change a positive answer into proof of membership or establish a lower false-positive rate. Include top-level index overhead when evaluating memory. [partitioned-filters]

Related terms:
- [sstable](https://hesela.dev/terms/sstable/)
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [ribbon-filter](https://hesela.dev/terms/ribbon-filter/)

Citations:
- [partitioned-filters] Maysam Yabandeh. Partitioned Index/Filters. RocksDB engineering note, 12 May 2017.. https://rocksdb.org/blog/2017/05/12/partitioned-index-filter.html (accessed 2026-10-13)

### PATA

URL: https://hesela.dev/terms/pata/
Also known as: Parallel ATA, IDE
Status: eol

Recorded firstSeen: 1994 (sources: [c1])

A parallel attachment standard for storage devices, dominant in PCs before SATA.

Related terms:
- [sata](https://hesela.dev/terms/sata/)
- [hdd](https://hesela.dev/terms/hdd/)
- [ahci](https://hesela.dev/terms/ahci/)
- [st-412](https://hesela.dev/terms/st-412/)

Superseded by:
- [sata](https://hesela.dev/terms/sata/)

Citations:
- [c1] Parallel ATA. https://en.wikipedia.org/wiki/Parallel_ATA (accessed 2026-03-26)

### PCIe 4.0 storage

URL: https://hesela.dev/terms/pcie-gen4/
Status: shipping

Fourth-generation PCIe roughly doubles per-lane bandwidth used by NVMe SSDs.

Related terms:
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [nvme](https://hesela.dev/terms/nvme/)
- [sd-express](https://hesela.dev/terms/sd-express/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] PCIe 4.0 storage. https://en.wikipedia.org/wiki/PCI_Express (accessed 2026-03-26)

### PCIe 5.0 storage

URL: https://hesela.dev/terms/pcie-gen5/
Status: shipping

Fifth-generation PCIe further increases lane bandwidth for next-wave NVMe drives.

Related terms:
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [nvme](https://hesela.dev/terms/nvme/)
- [pcie-gen4](https://hesela.dev/terms/pcie-gen4/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] PCIe 5.0 storage. https://en.wikipedia.org/wiki/PCI_Express (accessed 2026-03-26)

### PCIe lanes (storage)

URL: https://hesela.dev/terms/pcie-lanes/
Status: shipping

A PCIe lane is one pair of transmit and receive signal paths between two PCI Express ports; a link bundles 1, 2, 4, 8 or 16 lanes, so the lane count (x1 to x16) together with the PCIe generation sets the peak bandwidth available to an SSD controller.

Note: In the PCI Express architecture described on Wikipedia, a lane is made of two differential signaling pairs, one for receiving and one for transmitting, so each lane has four wires and carries data in both directions at once (dual simplex). A link between two devices is built from one or more lanes, the packet data is striped across the lanes, and peak throughput scales with the link width. The standard defines x1, x2, x4, x8 and x16 widths; x12 and x32 were defined up to PCIe 5.0 but, according to the same article, virtually never used. The lane count is negotiated when the link is initialised and can be restricted by either endpoint, and a link can fall back to fewer lanes if bad or unreliable lanes are present. Per-lane throughput depends on the generation. The article's comparison table gives usable throughput per direction of 0.985 GB/s per lane for PCIe 3.0 (8 GT/s, 128b/130b), 1.969 GB/s for PCIe 4.0 (16 GT/s) and 3.938 GB/s for PCIe 5.0 (32 GT/s), which for the x4 width typical of M.2 SSDs is 3.938, 7.877 and 15.754 GB/s respectively. PCIe 6.0 moves to PAM-4 signaling with 256-byte FLITs carrying 242 bytes of data (7.563 GB/s per lane), and the article notes that PCIe 6.0 hardware was not launched until August 2025. These are link-level figures: Wikipedia states that long continuous unidirectional transfers, typical of high-performance storage controllers, can approach more than 95% of the raw lane data rate, while its packet-efficiency example gives about 86% for a 128-byte payload, 98% for 1024 bytes and as low as 16% for 4-byte accesses, because of per-packet overhead. For storage form factors, Wikipedia's M.2 article says the connector provides up to four PCI Express lanes plus one logical SATA 3.0 port: M-key sockets can carry PCIe x4 (what it calls socket 3), while B-key and B+M-key modules use up to two lanes (socket 2). The PCI Express article also notes that M.2, U.2 and SATA Express are PCIe-based storage connectors, that the SD Express bus introduced in version 7.0 of the SD specification uses a x1 PCIe link, and that CFexpress cards support 1 to 4 lanes. Slot labels can mislead: a physical x16 slot may be wired for only four lanes, often written x16 @ x4. A PCIe switch can share one upstream link among several downstream ports, which spreads bandwidth dynamically compared with statically splitting lanes (bifurcation). The sources read here do not give lane counts or real-world speeds for specific SSD models.

Advantages:
- Peak bandwidth scales with link width because data is striped across lanes, so an x4 SSD link carries about four times the throughput of an x1 link of the same generation (for example 3.938 GB/s versus 0.985 GB/s per direction at PCIe 3.0)
- Each lane is full duplex, with separate transmit and receive pairs, so reads and writes do not contend for the same wires
- Lane count is negotiated automatically and the link can down-configure to fewer lanes, so a narrower device or slot still works (at reduced bandwidth) and a link with bad lanes can keep running

Limitations:
- A drive cannot exceed the width its slot is wired for: a physical x16 slot may provide only x4, and an M.2 B-key or B+M-key module uses at most two lanes, so physical connector size does not guarantee electrical lanes
- Quoted lane bandwidth is a link-level maximum; Wikipedia notes protocol overhead lowers efficiency, especially for small transfers (about 86% for a 128-byte payload and as low as 16% for 4-byte accesses)
- Lanes are a finite resource shared across devices; a switch lets several downstream ports share the upstream link rather than each receiving dedicated bandwidth, and the SD Express bus is limited to a single lane

Related terms:
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [m2](https://hesela.dev/terms/m2/)
- [u2](https://hesela.dev/terms/u2/)
- [sata-express](https://hesela.dev/terms/sata-express/)
- [nvme](https://hesela.dev/terms/nvme/)
- [pcie-gen4](https://hesela.dev/terms/pcie-gen4/)
- [pcie-gen5](https://hesela.dev/terms/pcie-gen5/)
- [pcie-retimer](https://hesela.dev/terms/pcie-retimer/)
- [nvme-backplane](https://hesela.dev/terms/nvme-backplane/)
- [sd-express](https://hesela.dev/terms/sd-express/)
- [cxl-memory](https://hesela.dev/terms/cxl-memory/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [flash-controller](https://hesela.dev/terms/flash-controller/)
- [ahci](https://hesela.dev/terms/ahci/)

Citations:
- [c1] PCI Express (Wikipedia), sections on lanes, link widths, revision comparison table, link efficiency and storage devices. https://en.wikipedia.org/wiki/PCI_Express (accessed 2026-10-11)
- [c2] M.2 (Wikipedia), sections on features, storage interfaces and keying. https://en.wikipedia.org/wiki/M.2 (accessed 2026-10-11)

### PCIe retimer

URL: https://hesela.dev/terms/pcie-retimer/
Status: shipping

A signal conditioner extending PCIe trace length in servers with many NVMe slots.

Related terms:
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [edsff](https://hesela.dev/terms/edsff/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] PCIe retimer. https://en.wikipedia.org/wiki/PCI_Express (accessed 2026-03-26)

### PCIe storage attachment

URL: https://hesela.dev/terms/pcie-storage/
Also known as: PCI Express SSD, PCIe NVMe
Status: shipping

Use of PCI Express lanes as the electrical transport for modern high-performance SSDs, usually with NVMe as the protocol.

Note: PCIe storage attaches non-volatile devices directly to the PCI Express fabric: configuration space, memory-mapped BARs, DMA, and MSI/MSI-X interrupts—without a SATA/SAS host bus adapter in the data path. NVMe is the dominant command protocol mapped onto PCIe today; older AHCI-over-PCIe flash and proprietary drivers existed historically. Bandwidth scales with generation (Gen3/Gen4/Gen5/…) and lane width (×1–×16). Form factors (AIC, M.2, U.2, EDSFF) are mechanical/electrical packages on that fabric. Pair this term with NVMe for “what the commands look like” versus “how bits move across the motherboard.”

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [m2](https://hesela.dev/terms/m2/)
- [u2](https://hesela.dev/terms/u2/)
- [edsff](https://hesela.dev/terms/edsff/)
- [hmb](https://hesela.dev/terms/hmb/)
- [sd-express](https://hesela.dev/terms/sd-express/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] NVM Express. https://en.wikipedia.org/wiki/NVM_Express (accessed 2026-03-26)
- [n2] PCI-SIG — PCI Express specifications overview. https://pcisig.com/specifications (accessed 2026-10-07)
- [n3] NVM Express — NVMe over PCIe transport (spec family). https://nvmexpress.org/specification/nvm-express-base-specification/ (accessed 2026-10-07)

### RocksDB pending compaction bytes

URL: https://hesela.dev/terms/pending-compaction-bytes/
Also known as: rocksdb.estimate-pending-compaction-bytes
Status: shipping

Record updated: 2026-10-15

RocksDB pending compaction bytes is an estimate of rewrite work needed to bring LSM levels within their size targets under level-based compaction.

Note: The v10.10.1 property contract limits this estimate to level-based compaction. It is not occupied disk space, free capacity, WAL length or an exact prediction of physical I/O. [properties] Separate soft and hard limits govern slowdown and stop conditions; in the pinned code those limits must be positive and automatic compactions enabled for these triggers. [stall-code] Compare the estimate with actual delayed write rate and stopped-write state, not with a claimed durability guarantee. [properties]

Related terms:
- [leveled-compaction](https://hesela.dev/terms/leveled-compaction/)
- [compaction](https://hesela.dev/terms/compaction/)
- [rocksdb-write-stall](https://hesela.dev/terms/rocksdb-write-stall/)
- [rocksdb-write-slowdown](https://hesela.dev/terms/rocksdb-write-slowdown/)
- [database-write-amplification](https://hesela.dev/terms/database-write-amplification/)

Citations:
- [properties] RocksDB v10.10.1. Pending compaction bytes and write-control properties.. https://github.com/facebook/rocksdb/blob/v10.10.1/include/rocksdb/db.h#L1263 (accessed 2026-10-15)
- [stall-code] RocksDB v10.10.1. ColumnFamilyData::GetWriteStallConditionAndCause.. https://github.com/facebook/rocksdb/blob/v10.10.1/db/column_family.cc#L986 (accessed 2026-10-15)
- [hesela] RocksDB: a WAL sync is not a memtable flush; write backpressure boundaries.. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/#write-backpressure (accessed 2026-10-15)

### Perpendicular magnetic tape

URL: https://hesela.dev/terms/perpendicular-tape/
Status: shipping

Recording orientation on tape analogous to PMR on disks for higher density.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)

Citations:
- [c1] Perpendicular magnetic tape. https://en.wikipedia.org/wiki/Linear_Tape-Open (accessed 2026-03-26)

### Persistence domain

URL: https://hesela.dev/terms/persistence-domain/
Also known as: power-fail protected domain
Status: shipping

Record updated: 2026-10-13

A persistence domain is the set of components whose stored contents are guaranteed to survive a specified failure under the platform's operating contract.

Note: Protection can include volatile buffers drained using reserved energy, so the domain is not simply a list of nonvolatile chips. Intel's ADR example includes controller write-pending queues but excludes CPU caches. [intel-adr] PMDK distinguishes mappings whose protected domains require page, cache-line or byte-granularity persistence mechanisms; these are not transaction-atomicity guarantees. [pmdk-granularity]

Related terms:
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [adr](https://hesela.dev/terms/adr/)
- [eadr](https://hesela.dev/terms/eadr/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)

Citations:
- [intel-adr] Intel. Second Generation Xeon Processor Scalable Family Technical Overview: The Persistence Domain.. https://www.intel.com/content/www/us/en/developer/articles/news/second-generation-intel-xeon-processor-scalable-family-technical-overview.html (accessed 2026-10-13)
- [pmdk-granularity] PMDK 1.13.1. libpmem2(7), GRANULARITY (pinned source documentation).. https://github.com/pmem/pmdk/blob/1.13.1/doc/libpmem2/libpmem2.7.md (accessed 2026-10-13)
- [hesela-pmem] Hesela. Persistent memory: DAX is not a durable commit.. https://hesela.com/analyses/pmem-persistence-domains-dax/ (accessed 2026-10-13)

### Persistence ordering

URL: https://hesela.dev/terms/persistence-ordering/
Also known as: persist ordering
Status: shipping

Record updated: 2026-10-15

Persistence ordering is a constraint on the order in which updates become durable, rather than merely the order in which an application issues them.

Note: Pillai et al. distinguish ordering from atomicity: individually indivisible updates can still reach storage in an unsafe order. Review the application's recovery dependencies, not only the syscall trace. Historical filesystem configurations are evidence of variation, not guarantees about every current implementation.

Related terms:
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [fsync](https://hesela.dev/terms/fsync/)
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [metadata-update-dependency](https://hesela.dev/terms/metadata-update-dependency/)
- [soft-updates](https://hesela.dev/terms/soft-updates/)

Citations:
- [pillai] Pillai, Chidambaram, Alagappan, Al-Kiswany, Arpaci-Dusseau and Arpaci-Dusseau. All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications. OSDI 2014, pp. 433-448, sections 2 and 4.4.. https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf (accessed 2026-10-11)
- [hesela-rename] Hesela: Atomic rename is not a durable commit. https://hesela.com/analyses/atomic-rename-directory-durability/ (accessed 2026-10-11)

### Persistent memory

URL: https://hesela.dev/terms/persistent-memory/
Status: limited

Record updated: 2026-10-13

Persistent memory is nonvolatile storage exposed through a memory-addressable interface, with durability governed by the platform's persistence contract.

Note: A CPU store can remain in an unprotected cache even when its destination is persistent memory; another thread may observe it before it is durable. [pmdk-concurrency] ADR and eADR protect different parts of the data path. [intel-adr] [intel-eadr] DAX avoids a page-cache copy, not every CPU cache. [dax-docs] Persistence operations and a recovery protocol are still needed; byte addressability does not imply transactional atomicity. [pmdk-persist]

Related terms:
- [nvdimm-n](https://hesela.dev/terms/nvdimm-n/)
- [storage-class-memory](https://hesela.dev/terms/storage-class-memory/)
- [optane](https://hesela.dev/terms/optane/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)
- [persistence-domain](https://hesela.dev/terms/persistence-domain/)
- [adr](https://hesela.dev/terms/adr/)
- [eadr](https://hesela.dev/terms/eadr/)
- [dax](https://hesela.dev/terms/dax/)
- [map-sync](https://hesela.dev/terms/map-sync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [pmdk-concurrency] PMDK project. Concurrency considerations in libpmemobj-cpp, 17 September 2021.. https://pmem.io/blog/2021/09/concurrency-considerations-in-libpmemobj-cpp/ (accessed 2026-10-13)
- [intel-adr] Intel. Second Generation Xeon Processor Scalable Family Technical Overview: The Persistence Domain.. https://www.intel.com/content/www/us/en/developer/articles/news/second-generation-intel-xeon-processor-scalable-family-technical-overview.html (accessed 2026-10-13)
- [intel-eadr] Intel. Third Generation Xeon Processor Scalable Family on Two Socket Platforms: eADR.. https://www.intel.com/content/www/us/en/developer/articles/technical/third-generation-xeon-scalable-family-overview.html (accessed 2026-10-13)
- [dax-docs] Linux kernel documentation. Direct Access for files: motivation and S_DAX state.. https://docs.kernel.org/filesystems/dax.html (accessed 2026-10-13)
- [pmdk-persist] PMDK 1.13.1. pmem2_get_persist_fn(3): early persistence and non-transactional semantics.. https://github.com/pmem/pmdk/blob/1.13.1/doc/libpmem2/pmem2_get_persist_fn.3.md (accessed 2026-10-13)
- [hesela-pmem] Hesela. Persistent memory: DAX is not a durable commit.. https://hesela.com/analyses/pmem-persistence-domains-dax/ (accessed 2026-10-13)

### Phase-change memory (storage)

URL: https://hesela.dev/terms/phase-change-memory/
Status: cancelled

Memory that switches between amorphous and crystalline states; Intel 3D XPoint marketed a variant.

Related terms:
- [3d-xpoint](https://hesela.dev/terms/3d-xpoint/)
- [optane](https://hesela.dev/terms/optane/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)

Citations:
- [c1] Phase-change memory (storage). https://en.wikipedia.org/wiki/Phase-change_memory (accessed 2026-03-26)

### Physical journaling

URL: https://hesela.dev/terms/physical-journaling/
Status: shipping

Record updated: 2026-10-15

Physical journaling records modified on-disk representations, such as metadata buffer contents or changed regions, for recovery.

Note: Physical logging need not mean every record is a complete block image: the XFS design tracks dirty regions of modified items and combines logging mechanisms. [xfs] Keep record payload, transferred blocks and internal media writes separate when comparing overhead. [hesela]

Related terms:
- [logical-journaling](https://hesela.dev/terms/logical-journaling/)
- [ext4-fast-commit](https://hesela.dev/terms/ext4-fast-commit/)
- [journal-checkpoint](https://hesela.dev/terms/journal-checkpoint/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)

Citations:
- [xfs] Linux v6.12: XFS Logging Design, introduction. https://github.com/torvalds/linux/blob/v6.12/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-15)
- [hesela] Hesela: journal representations and FastCommit cost audit. https://hesela.com/analyses/ext4-journal-replay-revocation/#journal-cost (accessed 2026-10-15)

### Physical sector

URL: https://hesela.dev/terms/physical-sector/
Also known as: physical block (storage)
Status: shipping

Record updated: 2026-10-12

A physical sector is the device-level data unit whose reported size describes physical read/write granularity rather than logical addressing.

Note: Treat the reported value as information at a particular storage layer, not a measurement of hidden flash geometry. Do not infer application-level power-loss behavior from this field alone.

Advantages:
- Helps callers choose requests that cover complete physical sectors. (sources: [microsoft-buffering])

Limitations:
- Linux can synthesize the reported physical block size from component devices in a stacked configuration. (sources: [linux-abi])
- Torn-write protection requires a separately supported atomic-write contract. (sources: [linux-atomic])

Related terms:
- [logical-sector](https://hesela.dev/terms/logical-sector/)
- [advanced-format](https://hesela.dev/terms/advanced-format/)
- [512e](https://hesela.dev/terms/512e/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)
- [torn-write](https://hesela.dev/terms/torn-write/)
- [rwf-atomic](https://hesela.dev/terms/rwf-atomic/)

Citations:
- [linux-abi] Linux 6.12: stable sysfs block ABI, sector sizes and I/O topology. https://raw.githubusercontent.com/torvalds/linux/v6.12/Documentation/ABI/stable/sysfs-block (accessed 2026-10-12)
- [microsoft-buffering] Microsoft: File buffering, alignment and file access requirements. https://learn.microsoft.com/en-us/windows/win32/fileio/file-buffering (accessed 2026-10-12)
- [linux-atomic] Linux ext4 documentation: Atomic Block Writes, requirements and semantics. https://docs.kernel.org/filesystems/ext4/atomic_writes.html (accessed 2026-10-12)
- [hesela-sector-alignment] Hesela: 512e, 4Kn and alignment: geometry is not durability. https://hesela.com/analyses/sector-sizes-alignment-not-durability/ (accessed 2026-10-12)

### Pipelined Read-Retry

URL: https://hesela.dev/terms/pipelined-read-retry/
Also known as: PR2
Status: research

Record updated: 2026-10-14

Pipelined Read-Retry overlaps NAND retry sensing with transfer and decoding of earlier attempts.

Note: Park's research design uses CACHE READ and cancels unnecessary speculative work after successful decoding; its SSD evaluation used simulation. [park]

Related terms:
- [read-retry](https://hesela.dev/terms/read-retry/)
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)
- [adaptive-read-retry](https://hesela.dev/terms/adaptive-read-retry/)

Citations:
- [park] Park et al. Reducing Solid-State Drive Read Latency by Optimizing Read-Retry. ASPLOS 2021, sections 6-7. DOI: 10.1145/3445814.3446719. https://people.inf.ethz.ch/~omutlu/pub/Reducing-SSD-Read-Latency-by-Optimizing-Read-Retry_asplos21.pdf (accessed 2026-10-14)
- [hesela] Hesela: NAND read-retry and stage timing. https://hesela.com/analyses/nand-read-retry-latency/ (accessed 2026-10-14)

### Placement group (Ceph)

URL: https://hesela.dev/terms/placement-group/
Also known as: Ceph placement group, PG
Status: shipping

Record updated: 2026-10-13

In Ceph, a placement group is a logical grouping of objects within a pool that share storage placement and are managed together for replication and recovery.

Note: Ceph maps objects to placement groups and maps those groups to Object Storage Daemons (OSDs). [ceph-glossary] One OSD can hold data from many placement groups, so a placement group is not a dedicated physical disk or a failure domain. More placement groups can improve distribution but consume CPU, memory and network resources. [ceph-pg]

Related terms:
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [crush-placement](https://hesela.dev/terms/crush-placement/)
- [ceph-up-set](https://hesela.dev/terms/ceph-up-set/)
- [ceph-acting-set](https://hesela.dev/terms/ceph-acting-set/)
- [ceph-peering](https://hesela.dev/terms/ceph-peering/)

Citations:
- [ceph-pg] Ceph Squid documentation: Placement Groups, use and resource costs. https://docs.ceph.com/en/squid/rados/operations/placement-groups/ (accessed 2026-10-13)
- [ceph-glossary] Ceph Squid glossary: Ceph OSD means Object Storage Daemon. https://docs.ceph.com/en/squid/glossary/#term-Ceph-OSD (accessed 2026-10-13)
- [hesela-availability] Storage availability and correlated failures: placement boundaries. https://hesela.com/analyses/storage-availability-correlated-failures/ (accessed 2026-10-13)

### Planar NAND

URL: https://hesela.dev/terms/planar-nand/
Status: eol

Planar (2D) NAND is flash memory in which the cells are built in a single layer on the silicon surface, the layout that 3D NAND replaced as a way to raise bit density.

Note: In planar NAND the memory cells sit on the silicon surface in one layer, so density rises only by shrinking the cells. Wikipedia's Flash memory article says planar NAND scaling stopped at 16 nm and that 3D NAND continues cost-per-bit reduction by stacking cells vertically, starting from 16 layers; it also notes that the wafer cost of a 3D NAND is comparable with scaled-down planar NAND at 32 nm or less. Hyperstone's 2018 controller-vendor article ties the limit to the cell physics: as density grows each cell gets smaller and holds fewer electrons, which makes data retention more critical, and multi-level encoding (MLC, TLC, QLC) lowers cost per bit but costs endurance and performance, leaving the flash controller to manage program/erase cycles, retention and program disturb. Hyperstone, writing when 3D flash was still under development, described the two 3D routes as floating-gate and charge-trap cells. Wikipedia's Multi-level cell article repeats that, as of 2018, nearly all commercial MLC was planar and so subject to scaling limits. Planar NAND is end-of-life for high-capacity parts, but the same cell concepts (floating gate, charge trap, SLC through QLC) carry over to 3D designs. The cited sources give no per-vendor planar-to-3D transition dates or planar endurance figures, so none are stated here.

Advantages:
- Cells built on the silicon surface in one layer, so the structure is simpler than a stacked 3D array
- Floating-gate cells in 3D NAND can reuse the manufacturing know-how accumulated on 2D production (Hyperstone)
- Wafer cost of 3D NAND is comparable to planar NAND scaled to 32 nm or less (Wikipedia), so planar was cost-competitive until scaling ran out

Limitations:
- Density can only grow by shrinking cells; Wikipedia states planar NAND scaling stopped at 16 nm
- Smaller cells store fewer electrons, which makes data retention more critical (Hyperstone)
- Packing more bits per cell (MLC, TLC, QLC) lowers cost per bit but reduces endurance and performance, and puts more load on the flash controller
- Not the route for new high-capacity flash: the industry moved to vertically stacked cells, per the cited sources

Related terms:
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [v-nand](https://hesela.dev/terms/v-nand/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [floating-gate](https://hesela.dev/terms/floating-gate/)
- [charge-trap-flash](https://hesela.dev/terms/charge-trap-flash/)
- [slc](https://hesela.dev/terms/slc/)
- [mlc](https://hesela.dev/terms/mlc/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [plc](https://hesela.dev/terms/plc/)
- [program-interference](https://hesela.dev/terms/program-interference/)
- [data-retention](https://hesela.dev/terms/data-retention/)
- [program-erase-cycle](https://hesela.dev/terms/program-erase-cycle/)
- [die-stacking](https://hesela.dev/terms/die-stacking/)
- [flash-controller](https://hesela.dev/terms/flash-controller/)
- [wear-leveling](https://hesela.dev/terms/wear-leveling/)
- [nor-flash](https://hesela.dev/terms/nor-flash/)
- [ssd](https://hesela.dev/terms/ssd/)

Citations:
- [c1] Flash memory (Wikipedia; vertical NAND, cost and endurance sections). https://en.wikipedia.org/wiki/Flash_memory (accessed 2026-10-11)
- [c2] Multi-level cell (Wikipedia; MLC section on planar scaling limits). https://en.wikipedia.org/wiki/Multi-level_cell (accessed 2026-10-11)
- [c3] Solid State bit density and the Flash Memory Controller (Hyperstone, 2018; archived copy). https://web.archive.org/web/2023/https://www.hyperstone.com/en/Solid-State-bit-density-and-the-Flash-Memory-Controller-1235.html (accessed 2026-10-11)

### PLC (penta-level cell)

URL: https://hesela.dev/terms/plc/
Status: research

NAND storing five bits per cell; higher density with challenging endurance and read margins.

Related terms:
- [qlc](https://hesela.dev/terms/qlc/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] PLC (penta-level cell). https://en.wikipedia.org/wiki/Multi-level_cell (accessed 2026-03-26)

### Perpendicular magnetic recording (PMR)

URL: https://hesela.dev/terms/pmr/
Also known as: perpendicular recording
Status: shipping

Record updated: 2026-10-16

Recorded firstSeen: 2005 (sources: [c1])

A magnetic recording orientation where bits stand perpendicular to the platter, enabling higher areal density than longitudinal recording.

Note: Perpendicular Magnetic Recording orients each bit’s magnetization normal to the platter plane, typically on granular CoCrPt media above a soft magnetic underlayer that strengthens the write field in the media “gap.” That geometry enabled smaller grains and higher areal density than longitudinal recording. PMR is the magnetic physics layer; CMR/SMR describe whether tracks overlap. Seagate’s HAMR technical literature frames PMR as approaching roughly 1 Tb/in² practical limits before heat- or microwave-assisted writers are needed on high-coercivity media. Datasheets may say “perpendicular,” “PMR,” or simply list “CMR” for product behavior on PMR media.

Related terms:
- [cmr](https://hesela.dev/terms/cmr/)
- [smr](https://hesela.dev/terms/smr/)
- [hamr](https://hesela.dev/terms/hamr/)
- [mamr](https://hesela.dev/terms/mamr/)
- [longitudinal-recording](https://hesela.dev/terms/longitudinal-recording/)
- [areal-density](https://hesela.dev/terms/areal-density/)
- [fc-mamr](https://hesela.dev/terms/fc-mamr/)
- [mas-mamr](https://hesela.dev/terms/mas-mamr/)
- [epmr](https://hesela.dev/terms/epmr/)

Supersedes:
- [longitudinal-recording](https://hesela.dev/terms/longitudinal-recording/)

Citations:
- [c1] Perpendicular recording. https://en.wikipedia.org/wiki/Perpendicular_recording (accessed 2026-03-26)
- [n2] Seagate — HAMR technology paper TP707 (PMR context and density limits). https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/ti-dm/tech-insights/en-us/docs/TP707-1-1712US_HAMR.pdf (accessed 2026-10-07)
- [n3] Seagate — Heat-Assisted Magnetic Recording (HAMR) overview. https://www.seagate.com/innovation/hamr/ (accessed 2026-10-07)

### Point-in-time recovery

URL: https://hesela.dev/terms/point-in-time-recovery/
Also known as: PITR
Status: shipping

Record updated: 2026-10-14

Point-in-time recovery restores a database to a selected historical state by applying retained transaction-log history to a suitable backup.

Note: In PostgreSQL 18 this uses a physical base backup, not a logical pg_dump export; replay restores the whole cluster, not one table. [pg-archive]

Advantages:
- Can stop replay before an unwanted later transaction. (sources: [pg-target])

Limitations:
- Recovery requires an uninterrupted WAL sequence from the backup start through the target. (sources: [pg-archive])

Related terms:
- [wal-archiving](https://hesela.dev/terms/wal-archiving/)
- [recovery-target](https://hesela.dev/terms/recovery-target/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [recovery-point-objective](https://hesela.dev/terms/recovery-point-objective/)

Citations:
- [pg-archive] PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery. https://www.postgresql.org/docs/18/continuous-archiving.html (accessed 2026-10-14)
- [pg-target] PostgreSQL 18: Recovery Target. https://www.postgresql.org/docs/18/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET (accessed 2026-10-14)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-14)

### POSIX_FADV_DONTNEED

URL: https://hesela.dev/terms/posix-fadv-dontneed/
Also known as: FADV_DONTNEED
Status: shipping

Record updated: 2026-10-15

POSIX_FADV_DONTNEED is a file-access advice value requesting release of cached data that the application does not expect to access soon.

Note: Unwritten dirty pages are not freed, and partial pages are generally retained. The v6.14 generic implementation additionally permits the final partial page when the advised inclusive end is the last file byte; filesystem-specific implementations may differ. [fadvise-api] [fadvise-source] A successful call does not prove eviction or durable completion; posix_fadvise returns an error number directly on failure. [fadvise-api]

Advantages:
- Targets a file range rather than dropping system-wide caches.

Limitations:
- Eviction remains best effort and concurrent access can repopulate the cache.

Related terms:
- [buffered-io](https://hesela.dev/terms/buffered-io/)
- [page-cache](https://hesela.dev/terms/page-cache/)
- [posix-fadv-noreuse](https://hesela.dev/terms/posix-fadv-noreuse/)
- [rwf-dontcache](https://hesela.dev/terms/rwf-dontcache/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [fadvise-api] Linux man-pages 6.19: posix_fadvise(2), advice semantics and return values.. https://man7.org/linux/man-pages/man2/posix_fadvise.2.html (accessed 2026-10-15)
- [fadvise-source] Linux v6.14 mm/fadvise.c: generic_fadvise, including the end-of-file partial-page exception.. https://github.com/torvalds/linux/blob/v6.14/mm/fadvise.c (accessed 2026-10-15)

### POSIX_FADV_NOREUSE

URL: https://hesela.dev/terms/posix-fadv-noreuse/
Also known as: FADV_NOREUSE
Status: shipping

Record updated: 2026-10-15

POSIX_FADV_NOREUSE is a file-access advice value indicating that the application does not expect to reuse the specified data.

Note: On Linux it was a no-op from 2.6.18 through 6.2; since 6.3 it permits page replacement to discount accesses. It neither bypasses the page cache nor promises immediate eviction. [fadvise-api] The v6.14 generic implementation sets FMODE_NOREUSE on the open file description; POSIX_FADV_NORMAL clears it. [fadvise-source]

Advantages:
- Can express one-pass access without changing to direct I/O.

Limitations:
- Advice is nonbinding and kernel-version dependent.

Related terms:
- [buffered-io](https://hesela.dev/terms/buffered-io/)
- [page-cache](https://hesela.dev/terms/page-cache/)
- [posix-fadv-dontneed](https://hesela.dev/terms/posix-fadv-dontneed/)
- [rwf-dontcache](https://hesela.dev/terms/rwf-dontcache/)

Citations:
- [fadvise-api] Linux man-pages 6.19: posix_fadvise(2), advice semantics and return values.. https://man7.org/linux/man-pages/man2/posix_fadvise.2.html (accessed 2026-10-15)
- [fadvise-source] Linux v6.14 mm/fadvise.c: generic_fadvise, including the end-of-file partial-page exception.. https://github.com/torvalds/linux/blob/v6.14/mm/fadvise.c (accessed 2026-10-15)

### posix_fallocate

URL: https://hesela.dev/terms/posix-fallocate/
Also known as: POSIX file-space allocation
Status: shipping

Record updated: 2026-10-16

A POSIX library function that reserves storage for a file byte range and reports failure by returning an error number directly.

Note: It returns zero on success; do not test for -1 or use errno as its result. glibc 2.40 tries native allocation first and uses emulation after EOPNOTSUPP. Its read/write fallback can race concurrent modifications; this is not a universal property of native allocation or every C library.

Related terms:
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [sparse-file](https://hesela.dev/terms/sparse-file/)
- [unwritten-extent](https://hesela.dev/terms/unwritten-extent/)

Citations:
- [posix-fallocate] Linux man-pages: posix_fallocate(3), return convention and glibc caveats. https://man7.org/linux/man-pages/man3/posix_fallocate.3.html (accessed 2026-10-16)
- [glibc-dispatch] glibc 2.40: Linux posix_fallocate dispatch to emulation on EOPNOTSUPP. https://raw.githubusercontent.com/bminor/glibc/glibc-2.40/sysdeps/unix/sysv/linux/posix_fallocate.c (accessed 2026-10-16)
- [glibc-emulation] glibc 2.40: generic posix_fallocate read/write emulation. https://raw.githubusercontent.com/bminor/glibc/glibc-2.40/sysdeps/posix/posix_fallocate.c (accessed 2026-10-16)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-16)

### Power loss protection

URL: https://hesela.dev/terms/power-loss-protection/
Also known as: PLP
Status: shipping

Record updated: 2026-10-13

Power-loss protection is a set of hardware and firmware measures intended to preserve specified SSD data and internal state when external power is unexpectedly removed.

Note: The protection boundary is product-specific. Micron's historical white paper distinguishes protection of data already stored in NAND from protection that also commits in-flight or volatile buffered writes and mapping information. A capacitor bank or an enterprise label alone does not specify which promise applies. FAST 2013 observed failures on some PLP-labelled devices but did not isolate a failed capacitor; this is not a field failure rate or evidence about every current product. Consult the exact model and firmware documentation. [micron] [zheng-power]

Limitations:
- Data-at-rest protection does not by itself promise persistence of volatile host-write buffers. (sources: [micron])

Related terms:
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [ssd](https://hesela.dev/terms/ssd/)
- [torn-write](https://hesela.dev/terms/torn-write/)
- [ftl](https://hesela.dev/terms/ftl/)
- [force-unit-access](https://hesela.dev/terms/force-unit-access/)
- [unserializable-write](https://hesela.dev/terms/unserializable-write/)

Citations:
- [micron] Micron: How Micron SSDs Handle Unexpected Power Loss, client and enterprise countermeasures (2014). https://assets.micron.com/adobe/assets/urn%3Aaaid%3Aaem%3A1f5ebe25-dc19-4e6f-89d2-31a2c6b69548/renditions/original/as/ssd-power-loss-protection-white-paper-lo.pdf (accessed 2026-10-13)
- [zheng-power] Zheng et al., FAST 2013: Understanding the Robustness of SSDs under Power Fault. https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf (accessed 2026-10-13)

### Power-on hours

URL: https://hesela.dev/terms/power-on-hours/
Also known as: POH, accumulated power-on time
Status: shipping

Record updated: 2026-10-16

Power-on hours is accumulated powered-operation time reported for a device, interpreted according to that device's counter and interface semantics.

Note: This is not time since purchase, host uptime or a measure of write endurance. A self-test timestamp records an earlier test, not necessarily current runtime. Raw time fields may use units other than hours; missing telemetry is unknown, not zero. [smartctl] Cisco's affected-drive procedure requires fresh collection and distinguishes accumulated minutes from hours. [ciscofn]

Related terms:
- [drive-firmware-revision](https://hesela.dev/terms/drive-firmware-revision/)
- [smart](https://hesela.dev/terms/smart/)
- [smart-raw-value](https://hesela.dev/terms/smart-raw-value/)
- [drive-day](https://hesela.dev/terms/drive-day/)

Citations:
- [ciscofn] Cisco FN70545, revision 2.0: 40,000-hour failure, C405 firmware and runtime collection. https://www.cisco.com/c/en/us/support/docs/field-notices/705/fn70545.html (accessed 2026-10-16)
- [smartctl] smartmontools 7.5 smartctl manual: self-test timestamps, background-scan runtime and raw time formats. https://github.com/smartmontools/smartmontools/blob/RELEASE_7_5/smartmontools/smartctl.8.in (accessed 2026-10-16)

### Powersafe overwrite

URL: https://hesela.dev/terms/powersafe-overwrite/
Also known as: PSOW
Status: shipping

Record updated: 2026-10-14

Powersafe overwrite is the storage property that an interrupted file write leaves bytes outside its requested range unchanged.

Note: This property does not constrain the target bytes to an entirely old or new value and does not establish durable completion. [sqlite-psow] SQLite reports PSOW separately from atomic-write size, safe-append and sequential-write capabilities. [sqlite-characteristics] A psow URI parameter changes an assumption in supported VFS implementations; it is not a hardware test and may be ignored by a custom VFS. [sqlite-uri]

Limitations:
- An unchanged surrounding range can coexist with a torn write inside the target. (sources: [sqlite-psow])

Related terms:
- [torn-write](https://hesela.dev/terms/torn-write/)
- [rwf-atomic](https://hesela.dev/terms/rwf-atomic/)
- [physical-sector](https://hesela.dev/terms/physical-sector/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)

Citations:
- [sqlite-psow] SQLite: Powersafe Overwrite, scope, assumptions and torn pages.. https://www.sqlite.org/psow.html (accessed 2026-10-14)
- [sqlite-characteristics] SQLite C interface: Device Characteristics.. https://sqlite.org/c3ref/c_iocap_atomic.html (accessed 2026-10-14)
- [sqlite-uri] SQLite: URI filenames, enabling URI handling and psow overrides.. https://sqlite.org/uri.html (accessed 2026-10-14)
- [hesela-psow] Hesela: atomic writes and powersafe overwrite, synthetic byte-state examples.. https://hesela.com/analyses/linux-atomic-writes-durability/#powersafe-overwrite (accessed 2026-10-14)
- [hesela-examples] Hesela: synthetic recovery-state examples, code hash and executable tests.. https://hesela.dev/data/powersafe-overwrite-examples.json (accessed 2026-10-14)

### Precision

URL: https://hesela.dev/terms/precision/
Also known as: positive predictive value, PPV
Status: shipping

Record updated: 2026-10-14

Precision is the fraction of positive predictions that match observed positive outcomes at a specified decision threshold.

Note: For binary failure prediction, precision = TP / (TP + FP), where TP counts correct positive predictions and FP counts false positives. Its denominator is alerts, not healthy observations. It is undefined when no positives are predicted; report any software convention used for that case. [sklearn-precision] A different failure prevalence can change precision even when recall and false positive rate stay fixed. [saito2015]

Limitations:
- Specify the failure label, prediction horizon and counting unit; a drive-day alert is not automatically a distinct drive selected for replacement. (sources: [hesela-prediction])

Related terms:
- [recall](https://hesela.dev/terms/recall/)
- [false-positive-rate](https://hesela.dev/terms/false-positive-rate/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [average-precision](https://hesela.dev/terms/average-precision/)
- [smart](https://hesela.dev/terms/smart/)
- [f1-score](https://hesela.dev/terms/f1-score/)
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)

Citations:
- [sklearn-precision] scikit-learn: precision_score; binary precision and zero-division behavior.. https://scikit-learn.org/stable/modules/generated/sklearn.metrics.precision_score.html (accessed 2026-10-12)
- [saito2015] Saito and Rehmsmeier. The Precision-Recall Plot Is More Informative than the ROC Plot When Evaluating Binary Classifiers on Imbalanced Datasets. PLOS ONE 10(3): e0118432 (2015).. https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0118432 (accessed 2026-10-12)
- [hesela-prediction] Hesela: disk failure prediction, metric denominators and a synthetic alert-count example.. https://hesela.com/analyses/ml-disk-failure-prediction/ (accessed 2026-10-12)

### Prediction horizon

URL: https://hesela.dev/terms/prediction-horizon/
Also known as: forecast horizon
Status: shipping

Record updated: 2026-10-14

A prediction horizon is the future interval after a prediction time in which a specified target event is evaluated.

Note: State the time origin, event and interval boundaries. A horizon differs from the historical input window and from achieved alarm-to-event delay; an event inside a ten-day horizon can occur much sooner than ten days. Lu et al. use failure within the next ten days as their target. [lu-fast20]

Limitations:
- A horizon does not guarantee enough time for migration or repair; measure actual warning delays and missed events separately. (sources: [lu-fast20])

Related terms:
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)
- [grouped-cross-validation](https://hesela.dev/terms/grouped-cross-validation/)
- [recall](https://hesela.dev/terms/recall/)
- [smart](https://hesela.dev/terms/smart/)
- [failure-label](https://hesela.dev/terms/failure-label/)

Citations:
- [lu-fast20] Lu et al. Making Disk Failure Predictions SMARTer! FAST 2020, section 4, p. 159: prediction horizon.. https://www.usenix.org/system/files/fast20-lu.pdf (accessed 2026-10-14)

### Prefix Bloom filter

URL: https://hesela.dev/terms/prefix-bloom-filter/
Also known as: Prefix membership filter
Status: shipping

Record updated: 2026-10-13

A Bloom filter built over extracted key prefixes rather than only whole keys, allowing negative membership tests for those represented prefixes.

Note: A present prefix can belong to an absent full key; that is not a false positive for prefix membership. A single negative prefix test cannot prove an interval crossing other prefixes empty. RocksDB prefix iteration requires the matching query contract. [prefix-guide]

Related terms:
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [prefix-extractor](https://hesela.dev/terms/prefix-extractor/)
- [succinct-range-filter](https://hesela.dev/terms/succinct-range-filter/)

Citations:
- [prefix-guide] RocksDB project. Prefix Seek: comparator compatibility, iterator modes and extractor changes.. https://github.com/facebook/rocksdb/wiki/Prefix-Seek (accessed 2026-10-13)
- [hesela] Hesela: filter predicates, prefix correctness and SuRF boundaries. https://hesela.com/analyses/bloom-filters-lsm-read-cost/#predicates (accessed 2026-10-13)

### Prefix extractor

URL: https://hesela.dev/terms/prefix-extractor/
Also known as: Key prefix transform
Status: shipping

Record updated: 2026-10-13

A key transformation with a defined input domain that produces the prefix used for prefix-based indexing or filtering.

Note: RocksDB's SliceTransform contract distinguishes keys inside its domain and constrains compatibility with comparator ordering. A fixed-length extractor and a capped-length extractor handle short keys differently; do not infer a bytewise query contract from a character count. [prefix-transform]

Related terms:
- [prefix-bloom-filter](https://hesela.dev/terms/prefix-bloom-filter/)
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)

Citations:
- [prefix-transform] RocksDB v9.7.3. SliceTransform: domain, ordering and prefix-extraction contracts.. https://github.com/facebook/rocksdb/blob/v9.7.3/include/rocksdb/slice_transform.h (accessed 2026-10-13)
- [hesela] Hesela: filter predicates, prefix correctness and SuRF boundaries. https://hesela.com/analyses/bloom-filters-lsm-read-cost/#predicates (accessed 2026-10-13)

### Prefix-preserving crash consistency

URL: https://hesela.dev/terms/prefix-preserving-crash-consistency/
Also known as: Prefix-preserving disk model
Status: research

Record updated: 2026-10-15

A recovery contract in which surviving updates form a prefix of the specified write order, including all writes covered by the last successful flush.

Note: OPTR defines order at device request receipt and adds request-level atomicity; this is not application submission order or atomicity of an entire multi-request transaction. Its no-barrier usage relaxes durability. [optr]

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [snapshot-consistent-ftl](https://hesela.dev/terms/snapshot-consistent-ftl/)
- [torn-write](https://hesela.dev/terms/torn-write/)

Citations:
- [optr] Yun-Sheng Chang and Ren-Shuo Liu. OPTR: Order-Preserving Translation and Recovery Design for SSDs with a Standard Block Device Interface. USENIX ATC 2019, pp. 1009-1024; introduction and sections 3, 5-7.. https://www.usenix.org/system/files/atc19-chang_0.pdf (accessed 2026-10-15)
- [hesela] Hesela: SSD mapping caches and recovery contracts. https://hesela.com/analyses/ssd-mapping-cache-hmb/#crash-contracts (accessed 2026-10-15)

### PRML detection

URL: https://hesela.dev/terms/prml-encoding/
Also known as: PRML, partial-response maximum-likelihood, PRML read channel
Status: unknown

Record updated: 2026-10-11

Partial-response maximum-likelihood (PRML) detection recovers a recorded symbol sequence by equalizing readback to a chosen partial-response target and evaluating sequence likelihoods under a channel model.

Note: Partial response retains controlled intersymbol interference; it does not mean removing every overlap before deciding each bit. Cideciyan et al. (1992) describe a class-IV system with Viterbi sequence detection, gain and timing recovery, and rate-8/9 constrained coding. These receiver and modulation functions are not interchangeable with error-correcting codes. Cideciyan et al. (2001) separately evaluate detector output errors, Reed-Solomon decoder input errors and sector errors: improvement at one stage need not translate equally to another. The stable slug prml-encoding is retained for compatibility, but this record names a detection approach, not a standalone encoding format. Historical density gains are implementation-specific, not a universal percentage.

Advantages:
- Sequence detection can exploit a model of controlled interference rather than relying only on isolated peak decisions. (sources: [ibm1992])

Limitations:
- A likelihood decision is conditional on the assumed channel and noise model; it is not a guarantee of correct recovered data. (sources: [ibm1992], [ibm2001])

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [pmr](https://hesela.dev/terms/pmr/)
- [run-length-limited](https://hesela.dev/terms/run-length-limited/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [npml-detection](https://hesela.dev/terms/npml-detection/)

Citations:
- [c1] PRML detection. https://en.wikipedia.org/wiki/Partial-response_maximum-likelihood (accessed 2026-03-26)
- [ibm1992] Cideciyan et al., A PRML System for Digital Magnetic Recording (1992), IBM Research abstract; DOI 10.1109/49.124468. https://research.ibm.com/publications/a-prml-system-for-digital-magnetic-recording (accessed 2026-10-11)
- [ibm2001] Cideciyan et al., Noise predictive maximum likelihood detection combined with parity-based post-processing (2001), IBM Research abstract. https://research.ibm.com/publications/noise-predictive-maximum-likelihood-detection-combined-with-parity-based-post-processing (accessed 2026-10-11)

### Process-associated record lock

URL: https://hesela.dev/terms/process-associated-record-lock/
Also known as: process-owned record lock, traditional POSIX record lock
Status: shipping

Record updated: 2026-10-16

A process-associated record lock is a byte-range file lock whose ownership is attached to a process rather than to an open file description.

Note: On Linux, closing any descriptor for the file in the owning process releases that process's traditional record locks on it. A read-only descriptor or a hard-link alias can trigger this even while the original holder remains open. Hesela's six-case local experiment contrasts these closes with flock; it does not test F_OFD_* or database corruption. [fcntl] [observation]

Limitations:
- Threads in one process share ownership; this lock class cannot provide exclusion between those threads. (sources: [fcntl])
- Advisory locking requires compatible participation and does not establish durability. (sources: [fcntl])

Related terms:
- [advisory-file-lock](https://hesela.dev/terms/advisory-file-lock/)
- [open-file-description-lock](https://hesela.dev/terms/open-file-description-lock/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [hard-link](https://hesela.dev/terms/hard-link/)

Citations:
- [fcntl] Linux man-pages 6.19: fcntl_locking(2), process-associated locks. https://man7.org/linux/man-pages/man2/fcntl_locking.2.html (accessed 2026-10-16)
- [observation] Hesela: six-case descriptor-close observation, controls and source SHA-256. https://hesela.dev/research/lock-close/observation.json (accessed 2026-10-16)
- [hesela-close] Hesela: A second close can end a process-owned lock. https://hesela.com/analyses/atomic-rename-directory-durability/#lock-close (accessed 2026-10-16)

### Program/erase cycle

URL: https://hesela.dev/terms/program-erase-cycle/
Status: shipping

Record updated: 2026-10-15

One complete program and erase of a NAND erase block, a core endurance metric.

Note: A host write is not a complete P/E cycle. An endurance rating depends on retention and error-correction conditions; it is not directly a TBW warranty. [cai2017]

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [wear-leveling](https://hesela.dev/terms/wear-leveling/)
- [dwpd](https://hesela.dev/terms/dwpd/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)
- [nand-erase-block](https://hesela.dev/terms/nand-erase-block/)

Citations:
- [c1] Program/erase cycle. https://en.wikipedia.org/wiki/Flash_memory (accessed 2026-03-26)
- [cai2017] Cai et al. Error Characterization, Mitigation, and Recovery in Flash-Memory-Based Solid-State Drives. 2017, sections 2.1 and 2.3.. https://arxiv.org/pdf/1706.08642v3 (accessed 2026-10-15)

### NAND program interference

URL: https://hesela.dev/terms/program-interference/
Also known as: Cell-to-cell program interference
Status: shipping

NAND program interference is an unintended shift in a cell's threshold voltage caused by programming neighboring cells.

Note: This differs from page pairing (shared cells), read disturb (read-induced effects) and retention loss (time-dependent degradation). In the HPCA 2017 experiments, capacitive coupling affected partially programmed planar MLC cells.

Limitations:
- The chip generation and internal programming path constrain the result; controller ECC does not automatically cover every internal reread. (sources: [cai])

Related terms:
- [nand-page-pairing](https://hesela.dev/terms/nand-page-pairing/)
- [mlc](https://hesela.dev/terms/mlc/)
- [read-disturb](https://hesela.dev/terms/read-disturb/)
- [data-retention](https://hesela.dev/terms/data-retention/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [cai] Cai, Ghose, Luo, Mai, Mutlu and Haratsch. Vulnerabilities in MLC NAND Flash Memory Programming: Experimental Analysis, Exploits, and Mitigation Techniques. HPCA 2017, sections 2-4 and 6. DOI: 10.1109/HPCA.2017.61. https://research.ece.cmu.edu/safari/pubs/flash-memory-programming-vulnerabilities_hpca17.pdf (accessed 2026-10-11)
- [hesela-pairing] Hesela: NAND paired pages and durability boundaries. https://hesela.com/analyses/nand-paired-pages-durability/ (accessed 2026-10-11)

### Protection information (PI)

URL: https://hesela.dev/terms/protection-information/
Status: shipping

Record updated: 2026-10-15

Protection information is integrity metadata accompanying storage I/O, with checks determined by the protocol, protection format and participating layers.

Note: A guard check and a location check answer different questions. Do not assume that PI verifies the newest committed generation or application semantics. Describe the configured format and which components generate, preserve and verify it; device capability is not proof of an application-to-media boundary. Linux v6.14 can receive application-supplied PI through io_uring attributes, subject to direct-I/O and lower-layer support. Supplying metadata is distinct from selecting checks. [pi-rw] [pi-map]

Related terms:
- [end-to-end-data-protection](https://hesela.dev/terms/end-to-end-data-protection/)
- [sas](https://hesela.dev/terms/sas/)
- [nvme](https://hesela.dev/terms/nvme/)
- [misdirected-write](https://hesela.dev/terms/misdirected-write/)
- [lost-write](https://hesela.dev/terms/lost-write/)
- [io-uring-integrity-metadata](https://hesela.dev/terms/io-uring-integrity-metadata/)

Citations:
- [c1] Linux v6.14: userspace protection-information ABI.. https://github.com/torvalds/linux/blob/v6.14/include/uapi/linux/io_uring.h (accessed 2026-10-15)
- [linux] Linux kernel documentation: Data Integrity, protection boundaries and automatic metadata generation.. https://docs.kernel.org/block/data-integrity.html (accessed 2026-10-11)
- [hesela-integrity] Hesela: checksum, identity and freshness boundaries with executable synthetic examples. https://hesela.com/analyses/checksums-identity-and-lost-writes/ (accessed 2026-10-11)
- [pi-rw] Linux v6.14: io_prep_rw_pi, io_prep_rw and io_rw_init_file in io_uring/rw.c.. https://github.com/torvalds/linux/blob/v6.14/io_uring/rw.c (accessed 2026-10-15)
- [pi-map] Linux v6.14: bio_integrity_map_iter and explicit integrity-check flags.. https://github.com/torvalds/linux/blob/v6.14/block/bio-integrity.c (accessed 2026-10-15)

### Pseudo-SLC (pSLC)

URL: https://hesela.dev/terms/pseudo-slc/
Also known as: pSLC, SLC mode
Status: shipping

Record updated: 2026-10-16

Operation of multi-bit-capable NAND in one-bit-per-cell mode, trading storage density for single-bit behavior.

Note: This operating mode is not proof of native SLC media. Swissbit's 2020 EN-26 announcement specifies a full pSLC configuration, rather than only a transient write cache. The mode and the cache role are different concepts. Endurance and retention still require product-specific evidence. [slc-swissbit] [slc-swissbit-full]

Advantages:
- Allows supported multi-bit NAND to use single-bit programming. (sources: [slc-swissbit])

Limitations:
- SLC-like operation does not establish a universal endurance multiplier. (sources: [slc-swissbit])

Related terms:
- [slc](https://hesela.dev/terms/slc/)
- [slc-cache](https://hesela.dev/terms/slc-cache/)
- [mlc](https://hesela.dev/terms/mlc/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)

Citations:
- [slc-swissbit] Swissbit - Storage technology, pSLC Mode and Powersafe sections. https://www.swissbit.com/en/technology/storage-technology/ (accessed 2026-10-16)
- [slc-swissbit-full] Swissbit - EN-20 and EN-26 announcement, 6 August 2020, page 1 (full pSLC mode). https://www.swissbit.com/files/public/press_news/Press_Releases/2020/2020-08-06_Miniaturized_highly_reliable_PCIe_M.2_BGA_SSD_for_ultra-small_industrial_applications_EN.pdf (accessed 2026-10-16)

### Purge sanitization

URL: https://hesela.dev/terms/purge-sanitization/
Also known as: Purge sanitization method
Status: shipping

Record updated: 2026-10-14

Purge sanitization uses suitable logical or physical techniques to make target-data recovery infeasible even with current state-of-the-art laboratory techniques while potentially allowing the medium to be reused.

Note: NIST SP 800-88 Rev. 2 section 3.1.2 defines an assurance objective, not a synonym for a particular erase command. Cryptographic erase can be a purge technique when its prerequisites are met. Reuse is possible, not guaranteed: a physical purge technique can leave some media inoperable. Degaussing requires a magnetic field suited to the medium's coercivity, does not sanitize flash components (including those in hybrid devices), and is not classified as destroy merely because hardware stops working. [nist-r2]

Advantages:
- Can provide a higher recovery-resistance objective than clear without necessarily destroying reusable media. (sources: [nist-r2])

Limitations:
- A technique must be appropriate for the medium and implementation; command acceptance alone does not establish successful purge. (sources: [nist-r2])

Related terms:
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [clear-sanitization](https://hesela.dev/terms/clear-sanitization/)
- [destroy-sanitization](https://hesela.dev/terms/destroy-sanitization/)
- [cryptographic-erase](https://hesela.dev/terms/cryptographic-erase/)
- [sanitization-verification](https://hesela.dev/terms/sanitization-verification/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, 3.1.2 and 3.2, printed pages 10-16. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-14)

### QLC SSD

URL: https://hesela.dev/terms/qlc-ssd/
Status: shipping

Solid-state drives built primarily from quad-level cell NAND for capacity-centric workloads.

Related terms:
- [qlc](https://hesela.dev/terms/qlc/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] QLC SSD. https://en.wikipedia.org/wiki/Quad-level_cell (accessed 2026-03-26)

### Quad-level cell (QLC)

URL: https://hesela.dev/terms/qlc/
Also known as: 4 bits per cell
Status: shipping

Record updated: 2026-10-16

NAND flash that stores four bits per cell using sixteen threshold-voltage states.

Note: The cell-density label does not specify an SSD's interface, cache policy or power-loss protection. Samsung announced the QLC-based 860 QVO on 27 November 2018, documenting commercial use by that date. That dated commercialization example is not the invention of QLC; firstSeen remains unknown. Use the exact drive's endurance and post-cache performance specifications. [qlc-launch] [slc-qvo-datasheet]

Advantages:
- Stores four bits per cell rather than TLC's three. (sources: [slc-kioxia])

Limitations:
- Headline write performance can differ from the post-cache rate; the 860 QVO datasheet separates them explicitly. (sources: [slc-qvo-datasheet])

Related terms:
- [tlc](https://hesela.dev/terms/tlc/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [ftl](https://hesela.dev/terms/ftl/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)
- [slc](https://hesela.dev/terms/slc/)
- [slc-cache](https://hesela.dev/terms/slc-cache/)
- [pseudo-slc](https://hesela.dev/terms/pseudo-slc/)

Supersedes:
- [tlc](https://hesela.dev/terms/tlc/)

Citations:
- [slc-kioxia] KIOXIA - Multi-level cell technology: threshold states and capacity. https://www.kioxia.com/en-jp/rd/technology/multi-level-cell.html (accessed 2026-10-16)
- [slc-qvo-datasheet] Samsung - 860 QVO datasheet, Revision 1.0 (October 2018), page 5, notes 2-3. https://download.semiconductor.samsung.com/resources/data-sheet/Samsung%20SSD%20860%20QVO%20Data%20Sheet_Rev1.pdf (accessed 2026-10-16)
- [qlc-launch] Samsung - 860 QVO announcement, 27 November 2018 (not a technology-origin claim). https://news.samsung.com/us/samsung-860-qvo-ssd-announcement/ (accessed 2026-10-16)

### Queue depth

URL: https://hesela.dev/terms/queue-depth/
Status: shipping

Record updated: 2026-10-13

Queue depth is the number of outstanding I/O requests at a specified boundary, while a configured depth limit is the maximum or target allowed in flight.

Note: Distinguish in-flight requests from waiting-only counts and queue capacity; report achieved depth rather than treating a configured fio iodepth as an observation. Little's law uses time-averaged occupancy and a matching per-operation mean residence time, not a configured maximum or a tail percentile [little2011].

Related terms:
- [iops](https://hesela.dev/terms/iops/)
- [nvme](https://hesela.dev/terms/nvme/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [open-loop-load](https://hesela.dev/terms/open-loop-load/)
- [closed-loop-load](https://hesela.dev/terms/closed-loop-load/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [little-law](https://hesela.dev/terms/little-law/)
- [io-request-size](https://hesela.dev/terms/io-request-size/)

Citations:
- [c1] Queue depth. https://en.wikipedia.org/wiki/IOPS (accessed 2026-03-26)
- [fio] fio documentation: I/O depth, io_submit_mode and interpreting slat/clat/lat. Online manual reviewed 11 October 2026.. https://fio.readthedocs.io/en/master/fio_doc.html (accessed 2026-10-11)
- [hesela-latency] Hesela: synthetic arrival cohorts, timing boundaries and percentile pooling. https://hesela.com/analyses/storage-latency-coordinated-omission/ (accessed 2026-10-11)
- [little2011] John D. C. Little. Little's Law as Viewed on Its 50th Anniversary. Operations Research 59(3), 536-549 (2011), pp. 537-539. DOI: 10.1287/opre.1110.0940.. https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf (accessed 2026-10-13)

### Quorum intersection

URL: https://hesela.dev/terms/quorum-intersection/
Also known as: Read-write quorum overlap
Status: shipping

Record updated: 2026-10-14

Quorum intersection is the property that every relevant pair of allowed quorums shares at least one replica.

Note: For arbitrary R-member read sets and W-member write sets drawn from the same fixed N replicas, R + W > N guarantees overlap; this is the equal-vote case of quorum voting. [gifford] Two W-member write sets must overlap when 2W > N. These are set properties, not standalone consistency protocols.

Limitations:
- Intersection alone does not establish linearizability, repair coverage or persistent storage of acknowledged data. (sources: [guarantees], [gifford])

Related terms:
- [read-quorum](https://hesela.dev/terms/read-quorum/)
- [write-quorum](https://hesela.dev/terms/write-quorum/)
- [sloppy-quorum](https://hesela.dev/terms/sloppy-quorum/)
- [linearizability](https://hesela.dev/terms/linearizability/)
- [partial-quorum](https://hesela.dev/terms/partial-quorum/)

Citations:
- [gifford] David K. Gifford. Weighted Voting for Replicated Data, SOSP 1979, sections 1 and 3.. https://www.cs.sfu.ca/~vaughan/teaching/401/papers/gifford79.pdf (accessed 2026-10-13)
- [guarantees] Apache Cassandra 5.0.0: Guarantees, including lightweight transactions.. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/architecture/guarantees.adoc (accessed 2026-10-13)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### Racetrack memory

URL: https://hesela.dev/terms/racetrack-memory/
Status: research

Research memory moving magnetic domain walls along nanowires; not a shipping bulk store.

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)

Citations:
- [c1] Racetrack memory. https://en.wikipedia.org/wiki/Racetrack_memory (accessed 2026-03-26)

### RAID 10

URL: https://hesela.dev/terms/raid-10/
Also known as: RAID10, RAID 1+0
Status: shipping

Record updated: 2026-10-15

RAID 10 combines replicated data copies with striping across storage members.

Note: Conventional RAID 1+0 uses fixed mirror groups; with two members per group, every group needs a current, readable survivor. Any single member may fail, but two failures in one pair remove both copies of its data. Linux MD also supports near, far and offset layouts and odd member counts, so copy placement must be checked. [mdadm-layout] Hesela's fixed-pair enumeration counts failure combinations, not observed reliability or repair timing. [hesela-mirror-topology] Ratios of counted subsets describe conditional probabilities only when same-size failure sets are equally likely; failure-count timing and member placement require separate evidence. [hesela-mirror-topology]

Limitations:
- A count of failed disks does not identify whether every required mirror retains a usable copy. (sources: [hesela-mirror-topology])

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [mirroring](https://hesela.dev/terms/mirroring/)
- [striping](https://hesela.dev/terms/striping/)
- [mirror-set](https://hesela.dev/terms/mirror-set/)
- [failure-domain](https://hesela.dev/terms/failure-domain/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)

Citations:
- [c1] RAID 10. https://en.wikipedia.org/wiki/Nested_RAID_levels (accessed 2026-03-26)
- [mdadm-layout] mdadm md(4): RAID1 and RAID10 layout (revision e5a1d3e). https://github.com/md-raid-utilities/mdadm/blob/e5a1d3ebaf95c29a7a5cf0d72fdc568138fd86dd/md.4 (accessed 2026-10-15)
- [hesela-mirror-topology] Hesela: RAID 10 mirror topology and exact failure-set counts. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#mirror-topology-heading (accessed 2026-10-15)

### RAID 5

URL: https://hesela.dev/terms/raid-5/
Also known as: RAID5
Status: shipping

Record updated: 2026-10-15

RAID 5 stripes data and distributed single parity across members so that one missing member can be reconstructed when the remaining required information is readable and consistent.

Note: For N equal-sized active members of capacity S, nominal data capacity is (N - 1) x S before metadata and filesystem overhead; a standby spare is not an active member in this count [md-layout]. One missing member consumes single-parity protection for each affected stripe. An additional unreadable fragment needed in that stripe can prevent reconstruction, without establishing loss of every file [hesela-parity]. Protection against one missing member does not itself make multi-member updates crash-atomic [md].

Advantages:
- Distributed parity avoids dedicating one member to all parity blocks. (sources: [snia5])

Limitations:
- An interrupted update can invalidate parity needed to recover a missing member; review the write-hole protection policy. (sources: [md])

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [partial-parity-log](https://hesela.dev/terms/partial-parity-log/)
- [write-intent-bitmap](https://hesela.dev/terms/write-intent-bitmap/)
- [latent-sector-error](https://hesela.dev/terms/latent-sector-error/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [raid-6](https://hesela.dev/terms/raid-6/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [md] Linux v6.12: RAID arrays, dirty/degraded assembly and bitmap metadata. https://github.com/torvalds/linux/blob/v6.12/Documentation/admin-guide/md.rst (accessed 2026-10-11)
- [ppl] Linux v6.12: Partial Parity Log. https://github.com/torvalds/linux/blob/v6.12/Documentation/driver-api/md/raid5-ppl.rst (accessed 2026-10-11)
- [hesela-raid] Hesela: RAID write hole, bitmap and PPL. https://hesela.com/analyses/raid-write-hole-bitmap-ppl/ (accessed 2026-10-11)
- [hesela-scrub] Hesela: Scrubbing, detection time and repair boundaries. https://hesela.com/analyses/scrubbing-detection-not-durability/ (accessed 2026-10-11)
- [snia5] SNIA Dictionary: RAID 5. https://www.snia.org/education/online-dictionary/term/raid-5 (accessed 2026-10-15)
- [md-layout] mdadm md(4): RAID4/5/6 layouts and capacity (revision e5a1d3e). https://github.com/md-raid-utilities/mdadm/blob/e5a1d3ebaf95c29a7a5cf0d72fdc568138fd86dd/md.4 (accessed 2026-10-15)
- [hesela-parity] Hesela: RAID 5/6 capacity and per-stripe recovery boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#parity-budget-heading (accessed 2026-10-15)

### RAID 6

URL: https://hesela.dev/terms/raid-6/
Also known as: RAID6
Status: shipping

Record updated: 2026-10-15

RAID 6 uses dual parity protection to retain data after any two member failures, provided the remaining required data and redundancy are readable and consistent.

Note: For N equal-sized active members of capacity S, nominal data capacity is (N - 2) x S before metadata and filesystem overhead, excluding standby spares [md-layout]. In the Linux coding scheme, P is XOR parity and Q is a distinct finite-field syndrome, not another copy of P [hpa-raid6]. Remaining protection is evaluated per affected stripe, not by counting errors anywhere in the array [hesela-parity].

Advantages:
- Any two missing members are within the configured device-failure tolerance under the reconstruction assumptions. (sources: [snia6])

Limitations:
- Two known erasures are not equivalent to two arbitrary silent corruptions; dual parity alone does not guarantee recovery of the latter. (sources: [hpa-raid6])
- Dirty and degraded parity can invalidate recovery assumptions; Linux MD normally refuses ordinary assembly in this state. (sources: [md])
- The level alone does not specify rebuild duration, availability policy or protection against deletion and shared failures. (sources: [hesela-parity])

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [latent-sector-error](https://hesela.dev/terms/latent-sector-error/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [snia6] SNIA Dictionary: RAID 6. https://www.snia.org/education/online-dictionary/term/raid-6 (accessed 2026-10-15)
- [md-layout] mdadm md(4): RAID4/5/6 layouts and capacity (revision e5a1d3e). https://github.com/md-raid-utilities/mdadm/blob/e5a1d3ebaf95c29a7a5cf0d72fdc568138fd86dd/md.4 (accessed 2026-10-15)
- [hpa-raid6] H. Peter Anvin: The mathematics of RAID-6, sections 2 and 4 (2011 revision). https://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf (accessed 2026-10-15)
- [md] Linux 6.12: RAID arrays, dirty/degraded assembly and corrected read errors. https://docs.kernel.org/6.12/admin-guide/md.html (accessed 2026-10-15)
- [hesela-parity] Hesela: RAID 5/6 capacity and per-stripe recovery boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#parity-budget-heading (accessed 2026-10-15)

### RAID rebuild

URL: https://hesela.dev/terms/raid-rebuild/
Also known as: RAID reconstruction, Array rebuild
Status: shipping

Record updated: 2026-10-15

A RAID rebuild reconstructs the required contents of a replacement or out-of-sync member from the array's surviving redundancy.

Note: Linux MD calls recovery the construction of a hot spare to replace a missing or failed member, and distinguishes it from resync after an unclean shutdown and check or repair scans [md]. Rebuilding redundancy is not restoration of an independent backup. An idle sync_action does not establish completion: inspect degraded and per-member in_sync state as well [md].

Limitations:
- A rebuild cannot reconstruct a region for which the surviving data and parity no longer provide enough information. (sources: [zconcepts])

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)
- [hot-spare](https://hesela.dev/terms/hot-spare/)
- [resilver](https://hesela.dev/terms/resilver/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [parity-declustering](https://hesela.dev/terms/parity-declustering/)
- [distributed-spare](https://hesela.dev/terms/distributed-spare/)

Citations:
- [md] Linux 6.12 documentation: RAID arrays, recovery, resync and degraded state. https://docs.kernel.org/6.12/admin-guide/md.html (accessed 2026-10-15)
- [zconcepts] OpenZFS 2.3: zpoolconcepts(7), device failure and hot spares. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpoolconcepts.7.html (accessed 2026-10-15)
- [hesela-rebuild] Hesela: RAID rebuild read-error models and resilver boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/#spare-policy-heading (accessed 2026-10-15)

### RAID write hole

URL: https://hesela.dev/terms/raid-write-hole/
Also known as: Parity write hole
Status: shipping

The RAID write hole is the risk that interrupted member updates leave inconsistent parity and corrupt reconstruction of missing data.

Note: One failed drive is recoverable only under the redundancy assumptions; inconsistent parity breaks that premise. Array parity consistency and application transaction atomicity are separate properties.

Limitations:
- Dirty, degraded Linux MD RAID5/6 arrays may contain undetectable corruption; bypassing an assembly refusal is not a repair. (sources: [md])

Related terms:
- [raid-5](https://hesela.dev/terms/raid-5/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [partial-parity-log](https://hesela.dev/terms/partial-parity-log/)
- [write-intent-bitmap](https://hesela.dev/terms/write-intent-bitmap/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)

Citations:
- [md] Linux v6.12: RAID arrays, dirty/degraded assembly and bitmap metadata. https://github.com/torvalds/linux/blob/v6.12/Documentation/admin-guide/md.rst (accessed 2026-10-11)
- [ppl] Linux v6.12: Partial Parity Log. https://github.com/torvalds/linux/blob/v6.12/Documentation/driver-api/md/raid5-ppl.rst (accessed 2026-10-11)
- [hesela-raid] Hesela: RAID write hole, bitmap and PPL. https://hesela.com/analyses/raid-write-hole-bitmap-ppl/ (accessed 2026-10-11)

### RAID

URL: https://hesela.dev/terms/raid/
Status: shipping

Record updated: 2026-10-12

Redundant Array of Independent Disks combines multiple drives for performance or fault tolerance.

Note: Patterson et al. introduced the RAID taxonomy; see SNIA dictionary for formal level definitions.

Related terms:
- [mirroring](https://hesela.dev/terms/mirroring/)
- [striping](https://hesela.dev/terms/striping/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)
- [hot-spare](https://hesela.dev/terms/hot-spare/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] SNIA Technology Dictionary. https://www.snia.org/education/dictionary (accessed 2026-10-06)
- [c2] RAID. https://en.wikipedia.org/wiki/RAID (accessed 2026-10-06)
- [c3] RAID: High-Performance, Reliable Secondary Storage (Patterson et al.). https://www2.eecs.berkeley.edu/Pubs/TechRpts/1987/CSD-87-391.pdf (accessed 2026-10-06)

### RAIDZ expansion

URL: https://hesela.dev/terms/raidz-expansion/
Also known as: RAID-Z expansion
Status: shipping

Record updated: 2026-10-16

RAIDZ expansion widens an existing RAIDZ virtual device by attaching another member and redistributing allocated space while retaining old blocks' data-to-parity ratios.

Note: OpenZFS 2.3 documents unchanged parity level and different ratios for pre-expansion and newly allocated blocks. [attach] This is capacity expansion, not replacement-device resilvering. The implementation records logical widths over transaction-group history to interpret blocks after reflow. [geometry] See the companion analysis for a bounded accounting model, not a pool-capacity estimator.

Limitations:
- The active raidz_expansion feature is not read-only compatible; recovery/import software must support it. (sources: [features])

Related terms:
- [raidz](https://hesela.dev/terms/raidz/)
- [resilver](https://hesela.dev/terms/resilver/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)

Citations:
- [attach] OpenZFS 2.3: zpool-attach(8), RAID-Z expansion and space reporting. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-attach.8.html (accessed 2026-10-16)
- [geometry] OpenZFS zfs-2.3.0: vdev_raidz.c, reflow and time-dependent geometry. https://github.com/openzfs/zfs/blob/zfs-2.3.0/module/zfs/vdev_raidz.c (accessed 2026-10-16)
- [features] OpenZFS 2.3: zpool-features(7), raidz_expansion compatibility. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpool-features.7.html (accessed 2026-10-16)
- [hesela] Hesela: RAIDZ expansion and retained parity cost. https://hesela.com/analyses/raidz-expansion-parity-capacity/ (accessed 2026-10-16)

### RAIDZ

URL: https://hesela.dev/terms/raidz/
Also known as: RAID-Z, RAIDZ1, RAIDZ2, RAIDZ3
Status: shipping

Record updated: 2026-10-16

RAIDZ is ZFS's distributed-parity virtual-device layout with one, two or three parity fragments and block-dependent stripe widths.

Note: RAIDZ1, RAIDZ2 and RAIDZ3 name parity levels within this layout, not separate storage media. Single, double and triple parity protect against corresponding member-device erasures within a group when the remaining required data and metadata are readable. [concepts] Do not infer a whole-pool failure probability or usable capacity from that count alone.

Related terms:
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [raid-6](https://hesela.dev/terms/raid-6/)
- [resilver](https://hesela.dev/terms/resilver/)
- [raidz-expansion](https://hesela.dev/terms/raidz-expansion/)

Citations:
- [concepts] OpenZFS zfs-2.3.0: zpoolconcepts(7), RAID-Z virtual devices. https://github.com/openzfs/zfs/blob/zfs-2.3.0/man/man7/zpoolconcepts.7 (accessed 2026-10-16)
- [hesela] Hesela: RAIDZ expansion and retained parity cost. https://hesela.com/analyses/raidz-expansion-parity-capacity/ (accessed 2026-10-16)

### IBM RAMAC

URL: https://hesela.dev/terms/ramac/
Also known as: 305 RAMAC, 350 disk storage
Status: eol

Recorded firstSeen: 1956 (sources: [c1])

The first commercial moving-head disk storage product, shipped with the IBM 305 RAMAC system.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)

Superseded by:
- [hdd](https://hesela.dev/terms/hdd/)

Citations:
- [c1] Computer History Museum — 1956: First commercial hard disk drive shipped (The Storage Engine, IBM Model 350 RAMAC). https://www.computerhistory.org/storageengine/first-commercial-hard-disk-drive-shipped/ (accessed 2026-10-16)

### Range tombstone

URL: https://hesela.dev/terms/range-tombstone/
Also known as: range deletion marker
Status: shipping

Record updated: 2026-10-12

A range tombstone is a versioned deletion marker that suppresses covered older keys across an ordered key interval.

Note: RocksDB DeleteRange uses a half-open interval [start, end). A later write can create a visible value inside that interval. The marker is not a synchronous erase of the covered SST bytes.

Related terms:
- [lsm-tombstone](https://hesela.dev/terms/lsm-tombstone/)
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [sstable](https://hesela.dev/terms/sstable/)

Citations:
- [delete-range] Abhishek Madan and Andrew Kryczka. DeleteRange: A New Native RocksDB Operation. RocksDB, 21 November 2018.. https://rocksdb.org/blog/2018/11/21/delete-range.html (accessed 2026-10-12)
- [hesela] LSM tombstones: deleted is not yet reclaimed. https://hesela.com/analyses/lsm-tombstones-delete-persistence/ (accessed 2026-10-12)

### Rate of occurrence of failures

URL: https://hesela.dev/terms/rate-of-occurrence-of-failures/
Also known as: ROCOF, Repair rate
Status: shipping

Record updated: 2026-10-16

The rate of occurrence of failures (ROCOF) is the derivative with respect to time of the expected cumulative failure count of a repairable system.

Note: With N(t) the recurring failure count, M(t) = E[N(t)] and ROCOF m(t) = dM(t)/dt. The clock runs from the system's starting point; it does not restart at every event. Despite the name repair rate, this measures event frequency, not repair speed or duration. Specify the system boundary and clock; device lifetime hazard conditions on survival and is a different quantity.

Related terms:
- [interarrival-time](https://hesela.dev/terms/interarrival-time/)
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)
- [mtbf](https://hesela.dev/terms/mtbf/)
- [failure-operation-ticket](https://hesela.dev/terms/failure-operation-ticket/)

Citations:
- [nist-rocof] NIST e-Handbook 8.1.2.5: Repair rate or ROCOF. https://www.itl.nist.gov/div898/handbook/apr/section1/apr125.htm (accessed 2026-10-12)
- [nist-hazard] NIST e-Handbook 8.1.2.3: Failure (or hazard) rate. https://www.itl.nist.gov/div898/handbook/apr/section1/apr123.htm (accessed 2026-10-12)
- [hesela-measurement-clocks] Hesela: Disk replacement rates are not disk lifetimes. https://hesela.com/analyses/mttf-vs-field-replacement-rates/ (accessed 2026-10-12)

### Rateless IBLT

URL: https://hesela.dev/terms/rateless-iblt/
Also known as: Rateless invertible Bloom lookup table
Status: research

Record updated: 2026-10-16

Rateless IBLT is a set-reconciliation scheme that streams additional coded symbols until the receiver can recover the set difference without first estimating its size.

Note: Yang, Gilad and Alizadeh's SIGCOMM 2024 construction extends a compatible symbol stream rather than resizing and rebuilding a fixed table. [rateless2024] It is a research protocol here, not a claim of deployment in Cassandra or a universal replacement for Merkle trees.

Limitations:
- Encoding cost still depends on the input-set size; difference-sensitive communication does not make reading or encoding the input free. (sources: [rateless2024])

Related terms:
- [invertible-bloom-lookup-table](https://hesela.dev/terms/invertible-bloom-lookup-table/)
- [set-reconciliation](https://hesela.dev/terms/set-reconciliation/)
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)

Citations:
- [rateless2024] Lei Yang, Yossi Gilad and Mohammad Alizadeh. Practical Rateless Set Reconciliation. SIGCOMM 2024, sections 3-4 and 7.2-7.3. DOI: 10.1145/3651890.3672219.. https://arxiv.org/html/2402.02668v3 (accessed 2026-10-16)
- [hesela-repair] Hesela: Replica repair, set reconciliation and record identity. https://hesela.com/analyses/replica-repair-coverage/#set-reconciliation (accessed 2026-10-16)

### Raw bit error rate

URL: https://hesela.dev/terms/raw-bit-error-rate/
Also known as: RBER, raw bit error ratio
Status: shipping

Record updated: 2026-10-12

Raw bit error rate is the number of erroneous bits divided by the total bits read at a specified measurement point before error correction.

Note: RBER includes errors that correction subsequently repairs. Report sensing conditions, the observation interval and the actual counters. The FAST 2016 first-generation devices recorded only the worst-chunk count among 16 chunks per page: the full error count lies between that count and 16 times it, so the multiplier is a bound, not a calibration. Across-drive percentiles do not reveal the within-codeword error distribution. [schroeder2016] BER comparisons require the same measurement boundary. [snia-ber]

Limitations:
- RBER alone is not a universal predictor of uncorrectable errors; the FAST 2016 Google fleet study found it was not predictive in that population. (sources: [schroeder2016])

Related terms:
- [bit-error-rate](https://hesela.dev/terms/bit-error-rate/)
- [uncorrectable-bit-error-rate](https://hesela.dev/terms/uncorrectable-bit-error-rate/)
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)
- [codeword](https://hesela.dev/terms/codeword/)
- [ldpc](https://hesela.dev/terms/ldpc/)
- [read-retry](https://hesela.dev/terms/read-retry/)

Citations:
- [schroeder2016] Schroeder, Lagisetty and Merchant. Flash Reliability in Production: The Expected and the Unexpected. USENIX FAST 2016, sections 4 and 5.2-5.3.. https://www.usenix.org/system/files/conference/fast16/fast16-papers-schroeder.pdf (accessed 2026-10-12)
- [snia-ber] SNIA Dictionary: bit error rate.. https://www.snia.org/education/online-dictionary/term/bit-error-rate (accessed 2026-10-12)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence.. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-12)
- [hesela-rber-aggregation] Hesela: BCH, LDPC and the RBER aggregation trap; synthetic counting example, not fleet measurements.. https://hesela.com/analyses/nand-ecc-bch-vs-ldpc/ (accessed 2026-10-12)

### RDMA storage networking

URL: https://hesela.dev/terms/rdma-storage/
Status: shipping

Remote direct memory access reduces CPU overhead for NVMe-oF and fast SAN traffic.

Related terms:
- [nvme-of](https://hesela.dev/terms/nvme-of/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)

Citations:
- [c1] RDMA storage networking. https://en.wikipedia.org/wiki/Remote_direct_memory_access (accessed 2026-03-26)

### Read amplification

URL: https://hesela.dev/terms/read-amplification/
Status: shipping

Record updated: 2026-10-14

Read amplification expresses storage-read work per logical read request or per useful byte returned, under an explicitly stated accounting convention.

Note: RocksDB's tuning guide uses physical disk reads per query. Candidate sorted runs, cache lookups, device I/O operations and bytes read are not interchangeable counters. [rocks-tuning] A Bloom-filter model's expected probes per absent lookup is not measured physical I/O: cache hits can eliminate device reads, while cold metadata can add reads. Separate successful lookups, absent lookups and scans, and separate foreground-query reads from compaction reads. A bytes-read/bytes-returned ratio is undefined for an absent query returning zero bytes; report reads per query instead. [hesela]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [leveled-compaction](https://hesela.dev/terms/leveled-compaction/)
- [tiered-compaction](https://hesela.dev/terms/tiered-compaction/)
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [database-write-amplification](https://hesela.dev/terms/database-write-amplification/)

Citations:
- [rocks-tuning] RocksDB project. Tuning Guide: amplification factors and their accounting boundaries.. https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide (accessed 2026-10-14)
- [hesela] Hesela. Bloom filters: optimize the lookup, not each filter; compaction and measurement boundaries.. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-14)

### Read disturb

URL: https://hesela.dev/terms/read-disturb/
Status: shipping

Record updated: 2026-10-14

Read disturb is an unintended change in NAND cell thresholds caused by reads to other wordlines in the same block.

Note: Pass-through voltage on unread cells can cause disturbance; Cai et al. studied planar MLC devices, not current fleet failure rates. Read disturb is distinct from retention loss and from the read-retry recovery mechanism. Read reclaim relocates data; read retry changes sensing. Disturbance need not be uniform across wordlines in 3D NAND.

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [ftl](https://hesela.dev/terms/ftl/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [data-retention](https://hesela.dev/terms/data-retention/)
- [program-interference](https://hesela.dev/terms/program-interference/)
- [read-reclaim](https://hesela.dev/terms/read-reclaim/)
- [nand-wordline](https://hesela.dev/terms/nand-wordline/)
- [read-pass-voltage](https://hesela.dev/terms/read-pass-voltage/)

Citations:
- [cai] Cai, Luo, Ghose, Haratsch, Mai and Mutlu. Read Disturb Errors in MLC NAND Flash Memory: Characterization, Mitigation, and Recovery. DSN 2015, sections 2 and 3. https://people.inf.ethz.ch/~omutlu/pub/flash-read-disturb-errors_dsn15.pdf (accessed 2026-10-11)
- [c1] Read disturb. https://en.wikipedia.org/wiki/Flash_memory (accessed 2026-03-26)
- [hesela] Hesela: NAND read-retry and evidence boundaries. https://hesela.com/analyses/nand-read-retry-latency/ (accessed 2026-10-11)
- [hesela-reclaim] Hesela: SSD read reclaim and read-only accounting. https://hesela.com/analyses/ssd-read-reclaim-hidden-writes/ (accessed 2026-10-12)
- [straw] Myoungjun Chun, Jaeyong Lee, Inhyuk Choi, Jisung Park, Myungsuk Kim and Jihong Kim. STRAW: A Stress-Aware WL-Based Read Reclaim Technique for High-Density NAND Flash-Based SSDs. Author manuscript arXiv:2501.02517v1, 5 January 2025, sections II-IV.. https://arxiv.org/html/2501.02517v1 (accessed 2026-10-12)

### Read-modify-write

URL: https://hesela.dev/terms/read-modify-write/
Status: shipping

Record updated: 2026-10-11

A storage update that reads existing data needed to preserve unchanged information, combines it with replacement data, and writes the modified data and any required redundancy.

Note: For a partial physical-sector update on a 512e drive, the merge is within a 4096-byte physical sector (Seagate). In parity RAID, RMW instead uses old changed-data blocks and old parity to update redundancy; it does not require reading or rewriting all unchanged data in the stripe. Reconstruct-write uses unchanged data from that same stripe plus the incoming data. Hesela's cold-cache model counts one-block RMW as two reads plus two writes for RAID5, or three plus three for P+Q RAID6. These are member-block operation counts, not fixed fractions of full-stripe throughput. The choice of update path depends on coverage, cache state and implementation; degraded operation is outside that model. CPU atomic read-modify-write instructions are a separate use of the name.

Advantages:
- Updates part of stored data while preserving the untouched information
- Can update parity without reading every unchanged data block

Limitations:
- Extra reads create dependencies, but counting operations alone does not determine elapsed time
- A full-stripe update can avoid parity prereads but still writes redundancy and needs crash-consistency protection
- Sector alignment, RAID stripe coverage and SSD-internal write amplification describe different layers

Related terms:
- [advanced-format](https://hesela.dev/terms/advanced-format/)
- [512e](https://hesela.dev/terms/512e/)
- [4kn-native](https://hesela.dev/terms/4kn-native/)
- [partition-alignment](https://hesela.dev/terms/partition-alignment/)
- [ssd](https://hesela.dev/terms/ssd/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [raid-6](https://hesela.dev/terms/raid-6/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [reconstruct-write](https://hesela.dev/terms/reconstruct-write/)
- [full-stripe-write](https://hesela.dev/terms/full-stripe-write/)

Citations:
- [c1] Advanced Format (Wikipedia; 512e and read-modify-write sections). https://en.wikipedia.org/wiki/Advanced_Format (accessed 2026-10-11)
- [c2] Standard RAID levels (Wikipedia; RAID 5 write amplification and performance sections). https://en.wikipedia.org/wiki/Standard_RAID_levels (accessed 2026-10-11)
- [chen1994] Peter M. Chen, Edward K. Lee, Garth A. Gibson, Randy H. Katz and David A. Patterson. RAID: High-Performance, Reliable Secondary Storage. ACM Computing Surveys 26(2), 145-185 (1994). Author manuscript: sections 3.2.5-3.3.2, Table 3 and 4.1.. https://pdl.cmu.edu/PDL-FTP/RAID/computin.pdf (accessed 2026-10-11)
- [linux-cache] Linux kernel documentation: RAID 4/5/6 cache, write-back mode and implementation. Rolling documentation; accessed 11 October 2026.. https://www.kernel.org/doc/html/latest/driver-api/md/raid5-cache.html (accessed 2026-10-11)
- [seagate-af] Seagate: Transition to Advanced Format 4K Sector Hard Drives, 512-byte emulation and alignment.. https://www.seagate.com/blog/advanced-format-4k-sector-hard-drives-master-ti/ (accessed 2026-10-11)
- [hesela-cost] Hesela: RAID write penalty is not a speed ratio; model and limitations. https://hesela.com/analyses/raid-write-penalty-io-not-speed/ (accessed 2026-10-11)

### Read-only mount

URL: https://hesela.dev/terms/read-only-mount/
Also known as: Linux read-only mount
Status: shipping

Record updated: 2026-10-15

A read-only mount restricts filesystem modification through Linux mount state, whose scope can be a VFS mount node, the filesystem superblock, or both.

Note: The util-linux v2.41.1 manual distinguishes both layers: a requested ro setting applies to both layers by default for standard mounts, but a read-only bind mount can leave another path writable. [mount-scope] Btrfs may still replay its recovery log during a read-only mount. [replay] Since util-linux 2.41, optional ro=vfs and ro=fs arguments can select a layer; the v2.41.1 manual marks them experimental and requires the file-descriptor-based mount API. The old mount(2) interface silently ignores the optional argument. [mount-scope]

Limitations:
- Read-only access through one path does not establish that the underlying device was unchanged. (sources: [mount-scope], [replay])
- The requested option spelling alone does not verify the effective layer; findmnt can report VFS-OPTIONS and FS-OPTIONS separately, but those flags are not an audit of device writes. (sources: [mount-scope])

Related terms:
- [btrfs-read-only-subvolume](https://hesela.dev/terms/btrfs-read-only-subvolume/)
- [block-device-read-only](https://hesela.dev/terms/block-device-read-only/)
- [btrfs-tree-log](https://hesela.dev/terms/btrfs-tree-log/)

Citations:
- [mount-scope] util-linux v2.41.1: mount(8), Read-only Setting Notes. https://kernel.googlesource.com/pub/scm/utils/util-linux/util-linux/+/refs/tags/v2.41.1/sys-utils/mount.8.adoc (accessed 2026-10-15)
- [replay] Btrfs documentation: tree-log replay and rescue options. https://btrfs.readthedocs.io/en/latest/btrfs-man5.html (accessed 2026-10-15)
- [hesela] Hesela: Btrfs tree logs and read-only scope boundaries. https://hesela.com/analyses/btrfs-tree-log-read-only-replay/#read-only-scopes (accessed 2026-10-15)

### Read-pass voltage

URL: https://hesela.dev/terms/read-pass-voltage/
Also known as: pass-through voltage, Vpass
Status: shipping

Record updated: 2026-10-14

Read-pass voltage is the bias applied to unselected NAND wordlines to make their cells conduct while another wordline is sensed.

Note: It differs from the sensing reference on the selected wordline. Lowering it trades reduced disturbance against possible conduction errors. [cai]

Limitations:
- Not a generic host-side SSD tuning control.

Related terms:
- [nand-wordline](https://hesela.dev/terms/nand-wordline/)
- [read-disturb](https://hesela.dev/terms/read-disturb/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [read-reclaim](https://hesela.dev/terms/read-reclaim/)
- [read-reference-voltage](https://hesela.dev/terms/read-reference-voltage/)

Citations:
- [cai] Cai et al. Read Disturb Errors in MLC NAND Flash Memory: Characterization, Mitigation, and Recovery. DSN 2015, sections 2.1 and 3.6-3.7. DOI 10.1109/DSN.2015.49.. https://people.inf.ethz.ch/~omutlu/pub/flash-read-disturb-errors_dsn15.pdf (accessed 2026-10-14)

### Read quorum

URL: https://hesela.dev/terms/read-quorum/
Also known as: Read response threshold
Status: shipping

Record updated: 2026-10-13

A read quorum is a protocol-approved set of replicas whose responses satisfy the requirement for completing a read.

Note: In an unweighted N-replica model, R is the response threshold, not necessarily a majority. Cassandra's named QUORUM level specifically requires a strict majority; local levels use a datacenter-specific scope. [cassandra]

Limitations:
- Meeting a response threshold does not by itself choose a real-time ordering of concurrent writes. (sources: [guarantees])

Related terms:
- [write-quorum](https://hesela.dev/terms/write-quorum/)
- [quorum-intersection](https://hesela.dev/terms/quorum-intersection/)
- [read-repair](https://hesela.dev/terms/read-repair/)

Citations:
- [cassandra] Apache Cassandra 5.0.0: Dynamo architecture, tunable consistency and data versioning.. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/architecture/dynamo.adoc (accessed 2026-10-13)
- [guarantees] Apache Cassandra 5.0.0: Guarantees, including lightweight transactions.. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/architecture/guarantees.adoc (accessed 2026-10-13)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### Read reclaim

URL: https://hesela.dev/terms/read-reclaim/
Also known as: NAND read reclaim, read-disturb reclaim
Status: shipping

Record updated: 2026-10-14

Read reclaim relocates valid NAND data to fresh pages to limit accumulated read-disturb errors.

Note: It differs from read retry, which adjusts sensing, and from space-driven garbage collection. Relocation can add internal programming during host read-only intervals. Thresholds and migration granularity depend on the design; a universal host-read limit cannot be inferred.

Limitations:
- Wordline-selective reclaim in STRAW is a research design evaluated using simulation, not a guarantee about commercial firmware. (sources: [straw])

Related terms:
- [read-disturb](https://hesela.dev/terms/read-disturb/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [ftl](https://hesela.dev/terms/ftl/)
- [nand-wordline](https://hesela.dev/terms/nand-wordline/)

Citations:
- [straw] Myoungjun Chun, Jaeyong Lee, Inhyuk Choi, Jisung Park, Myungsuk Kim and Jihong Kim. STRAW: A Stress-Aware WL-Based Read Reclaim Technique for High-Density NAND Flash-Based SSDs. Author manuscript arXiv:2501.02517v1, 5 January 2025, sections II-IV.. https://arxiv.org/html/2501.02517v1 (accessed 2026-10-12)
- [park] Yonggon Park, Hyunuk Cho, Onur Mutlu, Sungjin Lee and Jisung Park. Experimental Study on System-Level Performance Impact of Read Disturbance in Modern SSDs. POMACS 2026, DOI 10.1145/3788092; author manuscript arXiv:2608.14073v1, sections 2.3, 4 and 5.. https://arxiv.org/html/2608.14073v1 (accessed 2026-10-12)
- [hesela-reclaim] Hesela: SSD read reclaim and read-only accounting. https://hesela.com/analyses/ssd-read-reclaim-hidden-writes/ (accessed 2026-10-12)

### NAND read-reference voltage

URL: https://hesela.dev/terms/read-reference-voltage/
Status: shipping

Record updated: 2026-10-14

A NAND read-reference voltage is a sensing voltage used to distinguish stored cell states during a read operation.

Note: It is a decision boundary rather than the cell's threshold voltage. Error counts depend on how this boundary intersects state distributions [chen2021]. Temperature compensation may adjust read references, while cell-dependent responses limit a single correction [an2023]; choosing a different boundary is not the same operation as rewriting data.

Limitations:
- A lower raw error count after adjusting the reference is not evidence that stored charge was restored.

Related terms:
- [read-retry](https://hesela.dev/terms/read-retry/)
- [data-retention](https://hesela.dev/terms/data-retention/)
- [cross-temperature-effect](https://hesela.dev/terms/cross-temperature-effect/)
- [soft-decision-decoding](https://hesela.dev/terms/soft-decision-decoding/)
- [read-pass-voltage](https://hesela.dev/terms/read-pass-voltage/)
- [nand-wordline](https://hesela.dev/terms/nand-wordline/)

Citations:
- [chen2021] Chen, Chen, Lin, Kong, Liu, Zhan and Chen. Temperature Impacts on Endurance and Read Disturbs in Charge-Trap 3D NAND Flash Memories. Micromachines 12(10), 1152 (2021), sections 3-5. DOI: 10.3390/mi12101152.. https://doi.org/10.3390/mi12101152 (accessed 2026-10-13)
- [an2023] An, Yoon, Go, Park, Kim, Kim and Lee. Effects of Poly-Si Grain Boundary on Retention Characteristics under Cross-Temperature Conditions in 3-D NAND Flash Memory. Micromachines 14(12), 2199 (2023), sections 2.1-2.2. DOI: 10.3390/mi14122199.. https://doi.org/10.3390/mi14122199 (accessed 2026-10-13)
- [hesela] 3D NAND retention: layer count is not a reliability rating. https://hesela.com/analyses/3d-nand-retention-evidence/#cross-temperature (accessed 2026-10-13)

### Read repair

URL: https://hesela.dev/terms/read-repair/
Status: shipping

Record updated: 2026-10-13

Read repair reconciles divergent replicas as part of processing a read request.

Note: When triggered, Cassandra 5.0.0 BLOCKING repairs queried data and waits for sufficient acknowledgements; NONE reconciles responses without repair writes. BLOCKING supports monotonic quorum reads, but a narrower read than write can expose partial partition updates. [read]

Limitations:
- A read does not establish agreement for unqueried data or every replica. (sources: [read])

Related terms:
- [anti-entropy-repair](https://hesela.dev/terms/anti-entropy-repair/)
- [hinted-handoff](https://hesela.dev/terms/hinted-handoff/)
- [monotonic-reads](https://hesela.dev/terms/monotonic-reads/)
- [read-quorum](https://hesela.dev/terms/read-quorum/)

Citations:
- [read] Apache Cassandra 5.0.0: Read repair. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/managing/operating/read_repair.adoc (accessed 2026-10-13)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### NAND read-retry

URL: https://hesela.dev/terms/read-retry/
Status: shipping

Record updated: 2026-10-14

NAND read-retry rereads a flash page with adjusted sensing settings after an unsuccessful error-correction attempt.

Note: This internal recovery step differs from resubmitting a host I/O request; supported retry modes are not a count of observed retries. [linux] Read reclaim is a separate relocation step; successful retry does not by itself prove that data was rewritten. [hesela-reclaim]

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [ldpc](https://hesela.dev/terms/ldpc/)
- [data-retention](https://hesela.dev/terms/data-retention/)
- [read-disturb](https://hesela.dev/terms/read-disturb/)
- [early-retention-loss](https://hesela.dev/terms/early-retention-loss/)
- [soft-decision-decoding](https://hesela.dev/terms/soft-decision-decoding/)
- [read-reclaim](https://hesela.dev/terms/read-reclaim/)
- [read-reference-voltage](https://hesela.dev/terms/read-reference-voltage/)
- [cross-temperature-effect](https://hesela.dev/terms/cross-temperature-effect/)
- [pipelined-read-retry](https://hesela.dev/terms/pipelined-read-retry/)
- [adaptive-read-retry](https://hesela.dev/terms/adaptive-read-retry/)

Citations:
- [linux] Linux MTD NAND driver API: nand_setup_read_retry, ECC callbacks and read_retries. https://docs.kernel.org/driver-api/mtdnand.html (accessed 2026-10-11)
- [park] Park, Kim, Chun, Orosa, Kim and Mutlu. Reducing Solid-State Drive Read Latency by Optimizing Read-Retry. ASPLOS 2021, sections 4 and 7.1. DOI: 10.1145/3445814.3446719. https://people.inf.ethz.ch/~omutlu/pub/Reducing-SSD-Read-Latency-by-Optimizing-Read-Retry_asplos21.pdf (accessed 2026-10-11)
- [hesela] Hesela: NAND read-retry and evidence boundaries. https://hesela.com/analyses/nand-read-retry-latency/ (accessed 2026-10-11)
- [hesela-reclaim] Hesela: SSD read reclaim and read-only accounting. https://hesela.com/analyses/ssd-read-reclaim-hidden-writes/ (accessed 2026-10-12)

### Read-your-writes

URL: https://hesela.dev/terms/read-your-writes/
Also known as: Read-your-writes consistency, RYW
Status: shipping

Record updated: 2026-10-13

Read-your-writes is a session guarantee requiring subsequent reads to use a state that incorporates the session's prior successful writes.

Note: The guarantee is scoped to a session, not every client. Another write may supersede an earlier value, so the session need not read back those exact bytes. A stale replica must catch up, be avoided, or decline the read when it cannot satisfy the session's dependency. This is different from monotonic reads, which protects previously observed state rather than only the session's own writes.

Related terms:
- [linearizability](https://hesela.dev/terms/linearizability/)
- [monotonic-reads](https://hesela.dev/terms/monotonic-reads/)
- [session-guarantees](https://hesela.dev/terms/session-guarantees/)

Citations:
- [session-guarantees] Douglas B. Terry et al. Session Guarantees for Weakly Consistent Replicated Data. PDIS 1994, sections 3.1 and 3.2.. https://classes.cs.uchicago.edu/archive/2026/spring/23380-1/papers/terry_sessionguarantees.pdf (accessed 2026-10-12)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-12)

### Recall

URL: https://hesela.dev/terms/recall/
Also known as: sensitivity, true positive rate, TPR
Status: shipping

Record updated: 2026-10-14

Recall is the fraction of observed positive outcomes identified by a classifier at a specified decision threshold.

Note: For binary failure prediction, recall = TP / (TP + FN), where FN counts observed positives missed by the classifier. It answers how many labeled failures were detected, not how many alerts were useful. If the evaluation sample has no positive outcomes, recall is undefined; report the software convention. [sklearn-recall]

Limitations:
- High recall alone does not bound false alarms: a classifier that labels every observation positive has recall one whenever positives exist. (sources: [sklearn-recall], [sklearn-pr-curve])

Related terms:
- [precision](https://hesela.dev/terms/precision/)
- [false-positive-rate](https://hesela.dev/terms/false-positive-rate/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [average-precision](https://hesela.dev/terms/average-precision/)
- [smart](https://hesela.dev/terms/smart/)
- [f1-score](https://hesela.dev/terms/f1-score/)
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)

Citations:
- [sklearn-recall] scikit-learn: recall_score; binary recall and zero-division behavior.. https://scikit-learn.org/stable/modules/generated/sklearn.metrics.recall_score.html (accessed 2026-10-12)
- [sklearn-pr-curve] scikit-learn: precision_recall_curve; the all-positive endpoint.. https://scikit-learn.org/stable/modules/generated/sklearn.metrics.precision_recall_curve.html (accessed 2026-10-12)
- [hesela-prediction] Hesela: disk failure prediction, metric denominators and a synthetic alert-count example.. https://hesela.com/analyses/ml-disk-failure-prediction/ (accessed 2026-10-12)

### Reconstruct-write

URL: https://hesela.dev/terms/reconstruct-write/
Also known as: reconstruction write
Status: shipping

Record updated: 2026-10-11

A parity-array update method that computes new parity from incoming replacement data and unchanged data from the same stripe instead of updating old parity from old overwritten data.

Note: In the healthy-array accounting model, replacing u complete equal-size data blocks among k data blocks with p parity blocks requires k-u old-data reads and u+p writes. The name describes parity regeneration during an update, not a failed-drive rebuild. Cached data, partial blocks, missing members and implementation policy change the required device work.

Advantages:
- Avoids reading the overwritten data and old parity
- Can require fewer prereads as more of a stripe is replaced

Limitations:
- Reading the unchanged data can cost more than RMW for small updates in wider stripes
- Fewer block transfers do not necessarily mean lower latency
- This definition does not specify a degraded-array update algorithm

Related terms:
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [full-stripe-write](https://hesela.dev/terms/full-stripe-write/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [raid-6](https://hesela.dev/terms/raid-6/)

Citations:
- [williams2006] Dan J. Williams. MD RAID Acceleration: Support for Asynchronous DMA/XOR Engines. Linux Symposium 2006, Volume Two, printed pp. 409-414; sections 3-5. The PDF filename uses different pagination.. https://www.kernel.org/doc/ols/2006/ols2006v2-pages-417-422.pdf (accessed 2026-10-11)
- [chen1994] Peter M. Chen, Edward K. Lee, Garth A. Gibson, Randy H. Katz and David A. Patterson. RAID: High-Performance, Reliable Secondary Storage. ACM Computing Surveys 26(2), 145-185 (1994). Author manuscript: sections 3.2.5-3.3.2, Table 3 and 4.1.. https://pdl.cmu.edu/PDL-FTP/RAID/computin.pdf (accessed 2026-10-11)
- [hesela-cost] Hesela: RAID write penalty is not a speed ratio; model and limitations. https://hesela.com/analyses/raid-write-penalty-io-not-speed/ (accessed 2026-10-11)

### Recovery point objective

URL: https://hesela.dev/terms/recovery-point-objective/
Also known as: RPO
Status: shipping

Record updated: 2026-10-14

The recovery point objective specifies the point in time to which data must be recoverable after a disruption, commonly expressed as the maximum tolerable data-loss interval.

Note: It is a requirement, not an observed backup age. A schedule alone does not prove that a usable recovery point exists.

Limitations:
- Evaluate the recoverable point against the objective, rather than equating the objective with job frequency. (sources: [nist-recovery])

Related terms:
- [backup](https://hesela.dev/terms/backup/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [recovery-time-objective](https://hesela.dev/terms/recovery-time-objective/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)
- [recovery-target](https://hesela.dev/terms/recovery-target/)

Citations:
- [nist-recovery] NIST SP 800-34 Rev. 1 (2010), sections 3.2.1 and 3.5.1: recovery objectives and testing. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf (accessed 2026-10-13)
- [hesela-recovery] Hesela: Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-13)

### Recovery target

URL: https://hesela.dev/terms/recovery-target/
Also known as: PITR stopping point
Status: shipping

Record updated: 2026-10-14

A recovery target is the configured condition at which database log replay should stop.

Note: PostgreSQL 18 accepts one target type: time, transaction ID, LSN, named restore point or the earliest consistent state. The inclusive setting governs time, transaction-ID and LSN boundaries; timeline selection identifies the history branch. [pg-target]

Advantages:
- An explicit target makes the intended replay endpoint inspectable. (sources: [pg-target])

Limitations:
- PostgreSQL raises a fatal error if archive recovery ends before a configured target is reached. (sources: [pg-target])
- A target is a recovery setting, not the recovery point objective that specifies acceptable data loss. (sources: [pg-target], [nist-recovery])

Related terms:
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)
- [wal-archiving](https://hesela.dev/terms/wal-archiving/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [recovery-point-objective](https://hesela.dev/terms/recovery-point-objective/)

Citations:
- [pg-target] PostgreSQL 18: Recovery Target. https://www.postgresql.org/docs/18/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY-TARGET (accessed 2026-10-14)
- [nist-recovery] NIST SP 800-34 Rev. 1: Recovery objectives. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf (accessed 2026-10-14)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-14)

### Recovery time objective

URL: https://hesela.dev/terms/recovery-time-objective/
Also known as: RTO
Status: shipping

Record updated: 2026-10-13

The recovery time objective sets the tolerable duration of resource unavailability before its effect on supported processes becomes unacceptable.

Note: It is a target, not a measured restore duration. Specify the resource and success criterion before comparing a recovery exercise with that target.

Limitations:
- A data-copy duration alone does not establish that a service has recovered. (sources: [nist-recovery])

Related terms:
- [backup](https://hesela.dev/terms/backup/)
- [recovery-point-objective](https://hesela.dev/terms/recovery-point-objective/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [restore-test](https://hesela.dev/terms/restore-test/)

Citations:
- [nist-recovery] NIST SP 800-34 Rev. 1 (2010), sections 3.2.1 and 3.5.1: recovery objectives and testing. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf (accessed 2026-10-13)
- [hesela-recovery] Hesela: Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-13)

### Reed–Solomon codes (storage)

URL: https://hesela.dev/terms/reed-solomon-code/
Status: shipping

Record updated: 2026-10-15

Reed–Solomon codes are maximum-distance-separable error-correcting codes over finite-field symbols that add n − k check symbols to k data symbols and can rebuild missing (erased) symbols, which is why storage systems use them for RAID 6 parity and erasure-coded object storage.

Note: Reed–Solomon codes were introduced by Irving S. Reed and Gustave Solomon in 1960. An RS(n, k) code treats data as symbols in a finite field and adds t = n − k check symbols. With a suitable errors-and-erasures decoder, it can locate and correct up to floor(t/2) erroneous symbols at unknown positions, or up to t erasures at known positions, and any mix of E errors and S erasures as long as 2E + S ≤ n − k. The code is maximum distance separable, meaning it reaches the Singleton bound: any k distinct, intact symbols from the same codeword are enough to reconstruct the data. Burst errors suit it because it counts damaged symbols, not damaged bits, so a long run of bad bits inside a few symbols costs only a few corrections; for random single-bit errors a binary code is usually a better choice. A common byte-oriented choice is RS(255, 223) with 32 parity symbols, correcting 16 symbol errors per block. In storage, Reed–Solomon coding protects compact discs (cross-interleaved Reed–Solomon coding), DVDs and Blu-ray discs, and it underlies RAID 6. In distributed storage, Ceph describes an erasure-coded pool as k data chunks plus m coding chunks placed on different OSDs, where an MDS profile can tolerate m unavailable fragments if the remaining fragments are intact and correctly identified; the Reed–Solomon technique reed_sol_van (Vandermonde) is the flexible default in its Jerasure plugin and one of two Reed–Solomon forms (Vandermonde or Cauchy) in its ISA plugin, which is the default plugin for new erasure-coded pools. Ceph's documentation gives k=10, m=4 as an example with 40% raw space overhead that survives the loss of four OSDs. An erasure-only decoder does not automatically locate silent corruption. A systematic identity block is not by itself proof of MDS: the 2005 Plank-Ding correction flags an incorrect earlier information-dispersal matrix, and the pinned ISA-L header documents parameter restrictions for gf_gen_rs_matrix. Its m parameter counts total rows, not parity rows. [plank-ding] [isal] The executable error/erasure supplement distinguishes known missing positions from unknown wrong values and demonstrates ambiguous recovery and a unique wrong result after false identification. [hesela-errors]

Advantages:
- Maximum distance separable: n − k redundancy symbols tolerate n − k known erasures, the best possible for that redundancy
- Symbol-oriented correction handles burst errors and whole-device losses well
- Configurable k and m let designers trade raw-space overhead against the number of tolerated failures

Limitations:
- Encoding and decoding use finite-field arithmetic, so the codes cost more compute than simple XOR parity
- Recovering a lost symbol requires the surviving symbols of the same codeword, so repair involves reading from many devices
- Repair must validate helper integrity and fragment identity; solving an invertible system is not a corruption detector.
- The actual matrix construction and supported parameter range must justify any-k recovery.

Related terms:
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [raid-6](https://hesela.dev/terms/raid-6/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [ldpc](https://hesela.dev/terms/ldpc/)
- [bit-error-rate](https://hesela.dev/terms/bit-error-rate/)
- [object-storage](https://hesela.dev/terms/object-storage/)
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [blu-ray-archive](https://hesela.dev/terms/blu-ray-archive/)
- [locally-repairable-code](https://hesela.dev/terms/locally-repairable-code/)
- [maximum-distance-separable-code](https://hesela.dev/terms/maximum-distance-separable-code/)
- [systematic-code](https://hesela.dev/terms/systematic-code/)
- [symbol-erasure](https://hesela.dev/terms/symbol-erasure/)
- [error-and-erasure-decoding](https://hesela.dev/terms/error-and-erasure-decoding/)

Citations:
- [c1] Reed–Solomon error correction (Wikipedia). https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction (accessed 2026-10-10)
- [c2] Erasure code profiles (Ceph documentation, Reef). https://docs.ceph.com/en/reef/rados/operations/erasure-code-profile/ (accessed 2026-10-10)
- [c3] ISA erasure code plugin (Ceph documentation). https://docs.ceph.com/en/latest/rados/operations/erasure-code-isa/ (accessed 2026-10-10)
- [c4] Jerasure erasure code plugin (Ceph documentation). https://docs.ceph.com/en/latest/rados/operations/erasure-code-jerasure/ (accessed 2026-10-10)
- [plank-ding] Plank and Ding. Note: Correction to the 1997 Tutorial on Reed-Solomon Coding. Software: Practice and Experience 35(2), 189-194 (2005). DOI 10.1002/spe.631. Author bibliography and abstract reviewed; full correction text unavailable in this run.. https://web.eecs.utk.edu/~jplank/plank/papers/SPE-04.html (accessed 2026-10-13)
- [isal] Intel ISA-L erasure_code.h, gf_gen_rs_matrix and gf_gen_cauchy1_matrix documentation; commit 8fa1e72fee7338fcfbf829b00f2f407631bd2dba.. https://github.com/intel/isa-l/blob/8fa1e72fee7338fcfbf829b00f2f407631bd2dba/include/erasure_code.h (accessed 2026-10-13)
- [rfc5510] Lacan, Roca, Peltotalo and Peltotalo. RFC 5510 (2009), sections 3.1, 8.2-8.4: systematic encoding and the erasure-channel assumption.. https://www.rfc-editor.org/rfc/rfc5510.html (accessed 2026-10-13)
- [forney] G. David Forney. Principles of Digital Communication II, MIT 6.451 (2005), section 6.5.3: bounded-distance erasure-and-error correction.. https://ocw.mit.edu/courses/6-451-principles-of-digital-communication-ii-spring-2005/bb895c1dee9ce0b39d6846e0aa984981_MIT6_451S05_FullLecNotes.pdf (accessed 2026-10-15)
- [hesela-errors] Hesela: exact GF(7) errors-and-erasures examples, including an ambiguous observation and false-identification negative control.. https://hesela.com/analyses/reed-solomon-matrix-recovery-guarantees/#errors-erasures (accessed 2026-10-15)

### Reflink

URL: https://hesela.dev/terms/reflink/
Status: shipping

Record updated: 2026-10-15

Filesystem support for sharing physical extents between files until one copy is modified.

Note: Linux FICLONE isolates later writes and requires the same filesystem; its concurrent-write atomicity applies to the clone operation, not an entire recursive directory copy. [ficlone] GNU cp may use reflinks by default, and errors in shared blocks can affect both files. [gnu-cp]

Limitations:
- Shared allocation neither reserves capacity for future copy-on-write nor establishes an independent backup. (sources: [ficlone], [gnu-cp])

Related terms:
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [snapshot](https://hesela.dev/terms/snapshot/)
- [file-extent](https://hesela.dev/terms/file-extent/)
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [copy-file-range](https://hesela.dev/terms/copy-file-range/)
- [copy-on-abundant-write](https://hesela.dev/terms/copy-on-abundant-write/)

Citations:
- [ficlone] Linux man-pages: FICLONE and FICLONERANGE sharing semantics. https://man7.org/linux/man-pages/man2/FICLONE.2const.html (accessed 2026-10-15)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)
- [gnu-cp] GNU coreutils: cp invocation, reflink modes and shared-block caveat. https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html (accessed 2026-10-15)
- [hesela-clones] Hesela: Fast file clones and deferred copying costs. https://hesela.com/analyses/file-clones-deferred-copy-cost/ (accessed 2026-10-15)

### Repair locality

URL: https://hesela.dev/terms/repair-locality/
Also known as: erasure-code locality
Status: shipping

Record updated: 2026-10-11

Repair locality is the number of helper fragments needed to recover a missing fragment under a specified erasure-code repair procedure.

Note: State whether the bound covers data fragments only or every fragment, including parity. Counted helpers are not necessarily distinct physical devices, and a helper count alone does not specify bytes transferred or repair latency.

Related terms:
- [locally-repairable-code](https://hesela.dev/terms/locally-repairable-code/)
- [repair-read-amplification](https://hesela.dev/terms/repair-read-amplification/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)

Citations:
- [ceph-lrc] Ceph: Locally Repairable Erasure Code Plugin (development documentation; parameter names are implementation-specific).. https://docs.ceph.com/en/latest/rados/operations/erasure-code-lrc/ (accessed 2026-10-11)
- [hesela-lrc] Local repair is not whole-node repair. https://hesela.com/analyses/lrc-repair-costs-locality/ (accessed 2026-10-11)

### Repair-read amplification

URL: https://hesela.dev/terms/repair-read-amplification/
Status: shipping

Record updated: 2026-10-11

Repair-read amplification is the ratio of bytes read during recovery to the explicitly stated quantity of lost data or lost encoded fragments being restored.

Note: Report the denominator and include parity repair when measuring an entire failed node. Bytes read, network bytes and elapsed time are separate metrics. Equal-size whole-fragment examples reduce byte ratios to fragment counts; partial-fragment schemes require byte accounting.

Related terms:
- [repair-locality](https://hesela.dev/terms/repair-locality/)
- [locally-repairable-code](https://hesela.dev/terms/locally-repairable-code/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)

Citations:
- [kolosov2018] Oleg Kolosov, Gala Yadgar, Matan Liram, Itzhak Tamo and Alexander Barg. On Fault Tolerance, Locality, and Optimality in Locally Repairable Codes. USENIX ATC 2018, pp. 865-877; sections 3, 5-6.. https://www.usenix.org/system/files/conference/atc18/atc18-kolosov.pdf (accessed 2026-10-11)
- [hesela-lrc] Local repair is not whole-node repair. https://hesela.com/analyses/lrc-repair-costs-locality/ (accessed 2026-10-11)

### Replay attack

URL: https://hesela.dev/terms/replay-attack/
Status: shipping

Record updated: 2026-10-15

A replay attack reuses previously valid data to induce acceptance in an unauthorized context.

Note: RFC 4949 describes replay for valid transmissions; the storage counterpart can restore an older authenticated block without forging its tag. Broz and colleagues explicitly exclude this threat from their 2018 sector-encryption design. [rfc4949] [broz2018] Legitimate journal replay during crash recovery is not, by itself, an attack. [hesela-freshness]

Related terms:
- [rollback-protection](https://hesela.dev/terms/rollback-protection/)
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)
- [cryptographic-nonce](https://hesela.dev/terms/cryptographic-nonce/)
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)

Citations:
- [rfc4949] RFC 4949: Internet Security Glossary, Version 2 (2007), replay attack; informational glossary, not an Internet Standard. https://www.rfc-editor.org/rfc/rfc4949.html (accessed 2026-10-15)
- [broz2018] Broz, Patocka and Matyas: Practical cryptographic data integrity protection with full disk encryption (extended version), 2018, section 2.4. https://arxiv.org/pdf/1807.00309v1 (accessed 2026-10-15)
- [hesela-freshness] Hesela: A trusted root still needs a version policy. https://hesela.com/analyses/checksums-identity-and-lost-writes/#verity-freshness (accessed 2026-10-15)

### Replication lag

URL: https://hesela.dev/terms/replication-lag/
Status: shipping

Record updated: 2026-10-16

Replication lag is a difference in replication progress between a source and a replica, measured at a named processing stage in a stated unit.

Note: Separate byte backlog from measured delay and identify receipt, write, flush or replay. PostgreSQL 18 pg_stat_replication lag intervals describe recent processing and notification delays, not a catch-up-time estimate. An idle caught-up standby can report NULL; NULL can also indicate missing tracking information, so it must not be replaced unconditionally with zero. Slot restart_lsn is a retention horizon, not replay progress; confirmed_flush_lsn describes logical-consumer receipt and is NULL for physical slots. [pg-slot-view]

Related terms:
- [synchronous-replication](https://hesela.dev/terms/synchronous-replication/)
- [asynchronous-replication](https://hesela.dev/terms/asynchronous-replication/)
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [replication-slot](https://hesela.dev/terms/replication-slot/)

Citations:
- [pg-stats] PostgreSQL 18: pg_stat_replication and lag semantics. https://www.postgresql.org/docs/18/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-VIEW (accessed 2026-10-12)
- [pg-functions] PostgreSQL 18: WAL and recovery information functions. https://www.postgresql.org/docs/18/functions-admin.html (accessed 2026-10-12)
- [hesela-replication] Replication acknowledgements: received, durable, applied. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-12)
- [pg-slot-view] PostgreSQL 18: pg_replication_slots state and progress fields. https://www.postgresql.org/docs/18/view-pg-replication-slots.html (accessed 2026-10-16)

### Replication slot

URL: https://hesela.dev/terms/replication-slot/
Also known as: PostgreSQL replication slot
Status: shipping

Record updated: 2026-10-16

In PostgreSQL, a replication slot tracks a consumer's progress and retains WAL and other resources needed for that consumer to continue.

Note: Physical and logical slots serve different replication streams. Retention can outlive a disconnected consumer and exhaust WAL storage; the slot is not a synchronous-commit policy. [pg-slots] PostgreSQL 18 applies max_slot_wal_keep_size at checkpoints; -1 permits unlimited slot retention, while a finite limit can sacrifice required history. [pg-slot-limits] The xmin and catalog_xmin horizons can hold back row-version cleanup independently of WAL byte headroom. [pg-slot-view]

Limitations:
- A slot is not an independently stored backup and does not establish that a replica has applied a transaction; this is a distinction between retention and acknowledgement contracts. (sources: [pg-slots], [hesela-replication])
- Old slot horizons can contribute to transaction-ID exhaustion; PostgreSQL may refuse new XID-assigning work, and removing a still-needed slot can require rebuilding the replica. (sources: [pg-vacuum])

Related terms:
- [asynchronous-replication](https://hesela.dev/terms/asynchronous-replication/)
- [synchronous-replication](https://hesela.dev/terms/synchronous-replication/)
- [replication-lag](https://hesela.dev/terms/replication-lag/)
- [logical-decoding](https://hesela.dev/terms/logical-decoding/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [wal-archiving](https://hesela.dev/terms/wal-archiving/)
- [failover-slot](https://hesela.dev/terms/failover-slot/)
- [hot-standby-feedback](https://hesela.dev/terms/hot-standby-feedback/)

Citations:
- [pg-slots] PostgreSQL 18: replication slots and WAL retention. https://www.postgresql.org/docs/18/warm-standby.html#STREAMING-REPLICATION-SLOTS (accessed 2026-10-16)
- [pg-slot-limits] PostgreSQL 18: WAL retention limits and idle slot timeout. https://www.postgresql.org/docs/18/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE (accessed 2026-10-16)
- [hesela-replication] Hesela: Replication acknowledgements, retention and decoding. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-16)
- [pg-slot-view] PostgreSQL 18: pg_replication_slots retention horizons. https://www.postgresql.org/docs/18/view-pg-replication-slots.html (accessed 2026-10-16)
- [pg-vacuum] PostgreSQL 18: routine vacuuming and transaction-ID wraparound prevention. https://www.postgresql.org/docs/18/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND (accessed 2026-10-16)

### Resilver

URL: https://hesela.dev/terms/resilver/
Also known as: ZFS resilver, Resilvering
Status: shipping

Record updated: 2026-10-13

A resilver is ZFS's process of bringing a newly attached, replacement or out-of-date device into agreement with the data it must hold.

Note: A resilver targets data requiring synchronization; a normal full scrub checks stored data for otherwise unnoticed checksum errors [zscrub]. In OpenZFS 2.3, replacement with -s uses sequential reconstruction and starts a scrub afterward because that reconstruction does not verify checksums; this replacement mode does not support RAID-Z [zreplace].

Limitations:
- Attaching a mirror member does not immediately add its full redundancy: the resilver must complete. (sources: [zattach])

Related terms:
- [raid-rebuild](https://hesela.dev/terms/raid-rebuild/)
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [degraded-array](https://hesela.dev/terms/degraded-array/)
- [hot-spare](https://hesela.dev/terms/hot-spare/)
- [checksum](https://hesela.dev/terms/checksum/)
- [mirroring](https://hesela.dev/terms/mirroring/)
- [raidz-expansion](https://hesela.dev/terms/raidz-expansion/)

Citations:
- [zscrub] OpenZFS 2.3: zpool-scrub(8), scrub versus resilver. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html (accessed 2026-10-13)
- [zreplace] OpenZFS 2.3: zpool-replace(8), replacement and sequential reconstruction. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-replace.8.html (accessed 2026-10-13)
- [zattach] OpenZFS 2.3: zpool-attach(8), when a mirror gains redundancy. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-attach.8.html (accessed 2026-10-13)
- [hesela-rebuild] Hesela: RAID rebuild read-error models and resilver boundaries. https://hesela.com/analyses/raid-rebuild-ure-math-and-resilver/ (accessed 2026-10-13)

### Restore test

URL: https://hesela.dev/terms/restore-test/
Also known as: test restore, test restoration
Status: shipping

Record updated: 2026-10-14

A restore test exercises recovery from backup material and checks whether the recovered data or selected system functions meet defined acceptance criteria.

Note: NIST CP-9(2) describes sampled restoration of selected functions. [nist] State the backup and functions actually tested, acceptance checks and environment differences; do not present one successful sample as proof about every retained backup. Hesela recommends recording the PITR endpoint and checking recovered contents against the intended state. [pg-archive] A passing file check does not establish successful recovery. [verify]

Advantages:
- Exercises selected system functions using recovered backup information. (sources: [nist])

Limitations:
- Evidence is limited to the tested scope and chosen sample. (sources: [nist])
- File verification alone does not establish successful database operation and correct contents. (sources: [verify])

Related terms:
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [backup-manifest](https://hesela.dev/terms/backup-manifest/)
- [incremental-backup](https://hesela.dev/terms/incremental-backup/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [backup](https://hesela.dev/terms/backup/)
- [recovery-point-objective](https://hesela.dev/terms/recovery-point-objective/)
- [recovery-time-objective](https://hesela.dev/terms/recovery-time-objective/)
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)
- [recovery-target](https://hesela.dev/terms/recovery-target/)

Citations:
- [verify] PostgreSQL 18: pg_verifybackup, checks and exclusions. https://www.postgresql.org/docs/18/app-pgverifybackup.html (accessed 2026-10-13)
- [nist] NIST SP 800-53 Rev. 5: CP-9(1), CP-9(2) and CP-10. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf (accessed 2026-10-13)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-13)
- [pg-archive] PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery. https://www.postgresql.org/docs/18/continuous-archiving.html (accessed 2026-10-14)

### Retention interference

URL: https://hesela.dev/terms/retention-interference/
Status: shipping

Retention interference is dependence of a flash cell's charge-retention behavior on the state of a neighboring cell.

Note: Reported in 3D charge-trap NAND sharing a trapping layer; do not equate it with program interference or assume every NAND generation has the same behavior.

Limitations:
- The cited single-vendor characterization is not a modern SSD fleet failure-rate estimate. (sources: [luo])

Related terms:
- [charge-trap-flash](https://hesela.dev/terms/charge-trap-flash/)
- [early-retention-loss](https://hesela.dev/terms/early-retention-loss/)
- [data-retention](https://hesela.dev/terms/data-retention/)
- [3d-nand](https://hesela.dev/terms/3d-nand/)

Citations:
- [luo] Luo, Ghose, Cai, Haratsch and Mutlu. Improving 3D NAND Flash Memory Lifetime by Tolerating Early Retention Loss and Process Variation. POMACS author manuscript, 2018, sections 4.1-4.4. https://ghose.cs.illinois.edu/papers/18sigmetrics_3dflash.pdf (accessed 2026-10-11)
- [hesela3d] Hesela: 3D NAND retention, cell architecture and evidence limits. https://hesela.com/analyses/3d-nand-retention-evidence/ (accessed 2026-10-11)

### Retry deduplication

URL: https://hesela.dev/terms/retry-deduplication/
Also known as: Duplicate request suppression
Status: shipping

Record updated: 2026-10-15

Retry deduplication recognizes repeated submissions of one logical request so that an already completed mutation is not executed again.

Note: RIFL couples request identity with durable completion records and defines migration and reclamation rules. This is distinct from data deduplication. A new request identity or lost recovery state can defeat a duplicate check. RIFL rejects expired leases and returns STALE for acknowledged requests arriving late, rather than treating missing results as new work; after lease expiry, an earlier outcome may remain uncertain.

Related terms:
- [io-timeout](https://hesela.dev/terms/io-timeout/)
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [fencing-token](https://hesela.dev/terms/fencing-token/)
- [idempotency](https://hesela.dev/terms/idempotency/)
- [idempotency-key](https://hesela.dev/terms/idempotency-key/)

Citations:
- [rifl] Collin Lee, Seo Jin Park, Ankita Kejriwal, Satoshi Matsushita and John Ousterhout. Implementing Linearizability at Large Scale and Low Latency. SOSP 2015; DOI 10.1145/2815400.2815416; sections 2-4, 7 and 9.. https://web.stanford.edu/~ouster/cgi-bin/papers/rifl.pdf (accessed 2026-10-15)
- [hesela-timeouts] Storage timeouts: an expired timer is not a cancelled write. https://hesela.com/analyses/storage-timeouts-uncertain-completion/ (accessed 2026-10-11)

### Ribbon filter

URL: https://hesela.dev/terms/ribbon-filter/
Also known as: Ribbon approximate-membership filter
Status: shipping

Record updated: 2026-10-13

A static approximate-membership filter built using banded Boolean linear systems, offering a space and construction-cost tradeoff relative to Bloom filters.

Note: The constructed filter is not a mutable set or a data-integrity checksum. Standard, homogeneous and bumped Ribbon variants have different tradeoffs. RocksDB's bloom_equivalent_bits_per_key targets Bloom-equivalent filtering, not the actual Ribbon bit count; assess temporary construction memory separately from resident size. [ribbon-paper] [ribbon-api]

Related terms:
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [sstable](https://hesela.dev/terms/sstable/)
- [partitioned-filter](https://hesela.dev/terms/partitioned-filter/)

Citations:
- [ribbon-paper] Peter C. Dillinger, Lorenz Huebschle-Schneider, Peter Sanders and Stefan Walzer. Fast Succinct Retrieval and Approximate Membership using Ribbon. arXiv:2109.01892v2 (2022), sections 2-4 and 12.. https://arxiv.org/abs/2109.01892v2 (accessed 2026-10-13)
- [ribbon-api] RocksDB v9.7.3. include/rocksdb/filter_policy.h: NewRibbonFilterPolicy and bloom_before_level.. https://github.com/facebook/rocksdb/blob/v9.7.3/include/rocksdb/filter_policy.h (accessed 2026-10-13)

### Right-censoring

URL: https://hesela.dev/terms/right-censoring/
Status: shipping

Record updated: 2026-10-13

Right-censoring records that a time-to-event exceeds the last observed event-free time without observing the event time itself.

Note: A disk still running when observation ends contributes known survival time, not a zero lifetime and not a confirmed failure. Retirement without a recorded failure may also censor a record. [nist-censoring] Health-dependent retirement can violate independent-censoring assumptions. A Kaplan-Meier curve does not justify extrapolation beyond its observed support. [kaplan-meier-1958] A missing SMART measurement is instead a missing covariate and can coexist with a recorded failure.

Related terms:
- [left-truncation](https://hesela.dev/terms/left-truncation/)
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)
- [drive-day](https://hesela.dev/terms/drive-day/)
- [survival-function](https://hesela.dev/terms/survival-function/)
- [kaplan-meier-estimator](https://hesela.dev/terms/kaplan-meier-estimator/)
- [informative-censoring](https://hesela.dev/terms/informative-censoring/)

Citations:
- [nist-censoring] NIST e-Handbook 8.1.3.1: Censoring. https://www.itl.nist.gov/div898/handbook/apr/section1/apr131.htm (accessed 2026-10-10)
- [hesela-age-audit] Hesela: Missing SMART ages and the limits of drive-age comparisons. https://hesela.com/analyses/backblaze-age-missing-data-audit/ (accessed 2026-10-11)
- [kaplan-meier-1958] Kaplan and Meier (1958): Nonparametric Estimation from Incomplete Observations, sections 1.1 and 2.1. https://web.stanford.edu/~lutian/coursepdf/KMpaper.pdf (accessed 2026-10-13)

### Robotic tape loader

URL: https://hesela.dev/terms/robotic-tape/
Status: shipping

Mechanisms that move tape cartridges between slots and drives in a library.

Related terms:
- [tape-library](https://hesela.dev/terms/tape-library/)
- [lto](https://hesela.dev/terms/lto/)

Citations:
- [c1] Robotic tape loader. https://en.wikipedia.org/wiki/Tape_library (accessed 2026-03-26)

### RocksDB atomic flush

URL: https://hesela.dev/terms/rocksdb-atomic-flush/
Also known as: atomic_flush
Status: shipping

Record updated: 2026-10-14

RocksDB atomic flush installs the results of flushing selected column families into the database as one logical all-or-nothing MANIFEST group.

Note: Automatic atomic flush covers all column families; a manual call must identify the participating families. [atomic] It does not make every earlier acknowledgment durable or include later writes automatically; the pinned options header warns that subsequent WAL-enabled writes can replay independently. [options]

Related terms:
- [rocksdb-column-family](https://hesela.dev/terms/rocksdb-column-family/)
- [rocksdb-manifest](https://hesela.dev/terms/rocksdb-manifest/)
- [memtable](https://hesela.dev/terms/memtable/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)

Citations:
- [options] RocksDB v10.10.1. options.h: manual_wal_flush, atomic_flush and FlushOptions.. https://github.com/facebook/rocksdb/blob/v10.10.1/include/rocksdb/options.h (accessed 2026-10-14)
- [atomic] RocksDB project. Atomic flush: grouped persistence and explicit column-family selection.. https://github.com/facebook/rocksdb/wiki/Atomic-flush (accessed 2026-10-14)
- [hesela] RocksDB: a WAL sync is not a memtable flush. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/ (accessed 2026-10-14)

### RocksDB column family

URL: https://hesela.dev/terms/rocksdb-column-family/
Also known as: column family (RocksDB)
Status: shipping

Record updated: 2026-10-15

A RocksDB column family is a separately configurable logical key space within one database, with its own memtables and SST files but a shared write-ahead log.

Note: A WriteBatch can atomically update multiple families; they are not independent database instances. Separate table files do not remove their shared recovery dependencies. [families] Column-family configuration is not a write-latency isolation boundary: one family's backpressure can delay or stop writes across the database. [stalls]

Related terms:
- [memtable](https://hesela.dev/terms/memtable/)
- [sstable](https://hesela.dev/terms/sstable/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [rocksdb-atomic-flush](https://hesela.dev/terms/rocksdb-atomic-flush/)
- [rocksdb-write-stall](https://hesela.dev/terms/rocksdb-write-stall/)

Citations:
- [families] RocksDB project. Column Families: atomic writes and shared WAL.. https://github.com/facebook/rocksdb/wiki/Column-Families (accessed 2026-10-14)
- [hesela] RocksDB: a WAL sync is not a memtable flush. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/ (accessed 2026-10-14)
- [stalls] RocksDB project. Write Stalls: causes, scope and admission behavior.. https://github.com/facebook/rocksdb/wiki/Write-Stalls (accessed 2026-10-15)

### RocksDB MANIFEST

URL: https://hesela.dev/terms/rocksdb-manifest/
Also known as: MANIFEST (RocksDB)
Status: shipping

Record updated: 2026-10-14

RocksDB MANIFEST is the version-edit log mechanism used to recover the database's recorded state, with CURRENT identifying the active manifest log.

Note: It tracks state such as table-file membership rather than duplicating the user-write WAL. Recovery applies an atomic group of version edits only when that group is complete. A file's presence alone does not prove its membership in the recovered database. [manifest]

Related terms:
- [rocksdb-atomic-flush](https://hesela.dev/terms/rocksdb-atomic-flush/)
- [rocksdb-column-family](https://hesela.dev/terms/rocksdb-column-family/)
- [sstable](https://hesela.dev/terms/sstable/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)

Citations:
- [manifest] RocksDB project. MANIFEST: CURRENT, VersionEdits and atomic groups.. https://github.com/facebook/rocksdb/wiki/MANIFEST (accessed 2026-10-14)
- [hesela] RocksDB: a WAL sync is not a memtable flush. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/ (accessed 2026-10-14)

### RocksDB WriteBufferManager

URL: https://hesela.dev/terms/rocksdb-write-buffer-manager/
Also known as: WriteBufferManager, RocksDB shared memtable budget
Status: shipping

Record updated: 2026-10-15

RocksDB WriteBufferManager is a shared controller that accounts for memtable memory across participating column families or database instances and can trigger flushing, optional write stalls and block-cache charges.

Note: The scope is participating DB objects in one process, not every process on a host. [dong2021] In v10.10.1, allow_stall defaults to false; with it enabled and a positive budget, the stall threshold includes equality. A zero constructor budget disables the manager's size-based flush and stall decisions, not all database flush triggers, and can still permit cache charging. [wbm-api] Cache reservations account for memtable allocations rather than duplicating their contents; delayed reservation release means the cache charge and live memtable bytes need not match. The allocation path absorbs cache-reservation errors, so the budget is not a hard process-memory cap. [wbm-code]

Related terms:
- [memtable](https://hesela.dev/terms/memtable/)
- [rocksdb-column-family](https://hesela.dev/terms/rocksdb-column-family/)
- [rocksdb-write-stall](https://hesela.dev/terms/rocksdb-write-stall/)
- [rocksdb-write-slowdown](https://hesela.dev/terms/rocksdb-write-slowdown/)

Citations:
- [wbm-api] RocksDB v10.10.1. WriteBufferManager: budget, optional stalls and cache charging.. https://github.com/facebook/rocksdb/blob/v10.10.1/include/rocksdb/write_buffer_manager.h (accessed 2026-10-15)
- [wbm-code] RocksDB v10.10.1. WriteBufferManager implementation: reservations and stall release.. https://github.com/facebook/rocksdb/blob/v10.10.1/memtable/write_buffer_manager.cc (accessed 2026-10-15)
- [dong2021] Dong et al. The RocksDB Experience. FAST 2021, section 4: local and shared resource management.. https://www.usenix.org/system/files/fast21-dong.pdf (accessed 2026-10-15)
- [hesela] RocksDB: shared memory budgets and write-stall domains.. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/#shared-memory (accessed 2026-10-15)

### RocksDB write slowdown

URL: https://hesela.dev/terms/rocksdb-write-slowdown/
Also known as: write slowdown (RocksDB)
Status: shipping

Record updated: 2026-10-15

A RocksDB write slowdown is the rate-reduction state of write backpressure, distinct from a full write stop.

Note: The delayed_write_rate setting uses bytes per second of user requests before compression, not device throughput; RocksDB can reduce the actual rate further. [write-options] For level-based compaction, memtable pressure, L0 file count and estimated compaction work are distinct trigger classes. [stall-code] Refusing to wait for backpressure does not select a stronger WAL or synchronization policy. [write-options]

Related terms:
- [rocksdb-write-stall](https://hesela.dev/terms/rocksdb-write-stall/)
- [pending-compaction-bytes](https://hesela.dev/terms/pending-compaction-bytes/)
- [memtable](https://hesela.dev/terms/memtable/)
- [compaction](https://hesela.dev/terms/compaction/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)

Citations:
- [write-options] RocksDB v10.10.1. Delayed write rate and WriteOptions contracts.. https://github.com/facebook/rocksdb/blob/v10.10.1/include/rocksdb/options.h#L1160 (accessed 2026-10-15)
- [stall-code] RocksDB v10.10.1. ColumnFamilyData::GetWriteStallConditionAndCause.. https://github.com/facebook/rocksdb/blob/v10.10.1/db/column_family.cc#L986 (accessed 2026-10-15)
- [hesela] RocksDB: a WAL sync is not a memtable flush; write backpressure boundaries.. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/#write-backpressure (accessed 2026-10-15)

### RocksDB write stall

URL: https://hesela.dev/terms/rocksdb-write-stall/
Also known as: write stall (RocksDB)
Status: shipping

Record updated: 2026-10-15

A RocksDB write stall is backpressure that delays or stops foreground writes when configured resource or background-work limits are reached.

Note: The project uses stall for both slowdown and full stop; it does not mean a device has failed. A trigger in one column family can affect writes across that database. [stalls] The v10.10.1 decision code evaluates stop conditions before slowdown conditions, and disabling automatic compactions bypasses its L0 and pending-compaction triggers but not its memtable triggers. [stall-code] WriteOptions::no_slowdown can return Incomplete for a recognized stall; it does not make the entire write path nonblocking. [write-path]

Related terms:
- [rocksdb-write-slowdown](https://hesela.dev/terms/rocksdb-write-slowdown/)
- [pending-compaction-bytes](https://hesela.dev/terms/pending-compaction-bytes/)
- [rocksdb-column-family](https://hesela.dev/terms/rocksdb-column-family/)
- [memtable](https://hesela.dev/terms/memtable/)
- [compaction](https://hesela.dev/terms/compaction/)
- [rocksdb-write-buffer-manager](https://hesela.dev/terms/rocksdb-write-buffer-manager/)

Citations:
- [stalls] RocksDB project. Write Stalls: causes, scope and admission behavior.. https://github.com/facebook/rocksdb/wiki/Write-Stalls (accessed 2026-10-15)
- [stall-code] RocksDB v10.10.1. ColumnFamilyData::GetWriteStallConditionAndCause.. https://github.com/facebook/rocksdb/blob/v10.10.1/db/column_family.cc#L986 (accessed 2026-10-15)
- [write-path] RocksDB v10.10.1. DelayWrite and write preprocessing.. https://github.com/facebook/rocksdb/blob/v10.10.1/db/db_impl/db_impl_write.cc#L2203 (accessed 2026-10-15)
- [hesela] RocksDB: a WAL sync is not a memtable flush; write backpressure boundaries.. https://hesela.com/analyses/rocksdb-wal-flush-manifest-boundaries/#write-backpressure (accessed 2026-10-15)

### Rollback journal

URL: https://hesela.dev/terms/rollback-journal/
Also known as: SQLite rollback journal, Rollback-mode journal
Status: shipping

Record updated: 2026-10-15

A rollback journal is an undo log that preserves original database content so an incomplete transaction can be reversed.

Note: SQLite records original page content and the database's starting size before overwriting stored pages. Recovery restores those pages and, when necessary, the original file length. [sqlite-atomiccommit] This differs from SQLite WAL mode, which appends changed pages and a commit record to a separate log. [sqlite-wal] Keeping a journal in memory does not provide crash recovery, and disabling journaling removes the ability to undo incomplete transactions. [sqlite-tempfiles] Journal presence alone does not identify an incomplete transaction; SQLite checks whether the journal is hot. [sqlite-locking] See the comparison of recovery boundaries. [hesela-wal] A disposable process-exit observation demonstrates journal retention after commit and rollback of unfinished writes; it is not a power-loss test. [hesela-journal-observation]

Advantages:
- Preserves before-images needed to undo changes from an interrupted transaction. (sources: [sqlite-atomiccommit])

Limitations:
- Recovery depends on the journal remaining available and on working filesystem locks and synchronization. (sources: [sqlite-locking])
- Rollback-mode synchronous=FULL does not guarantee power-loss durability on every filesystem; EXTRA adds protection for DELETE-mode commits. (sources: [sqlite-synchronous])

Related terms:
- [hot-journal](https://hesela.dev/terms/hot-journal/)
- [sqlite-super-journal](https://hesela.dev/terms/sqlite-super-journal/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [fsync](https://hesela.dev/terms/fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [sqlite-atomiccommit] SQLite: Atomic Commit In SQLite. https://sqlite.org/atomiccommit.html (accessed 2026-10-14)
- [sqlite-locking] SQLite: File Locking And Concurrency In SQLite Version 3. https://sqlite.org/lockingv3.html (accessed 2026-10-14)
- [sqlite-tempfiles] SQLite: Temporary Files Used By SQLite. https://sqlite.org/tempfiles.html (accessed 2026-10-14)
- [sqlite-wal] SQLite: Write-Ahead Logging. https://sqlite.org/wal.html (accessed 2026-10-14)
- [sqlite-synchronous] SQLite: PRAGMA synchronous. https://sqlite.org/pragma.html#pragma_synchronous (accessed 2026-10-14)
- [hesela-wal] Hesela: WAL, checkpoints and torn pages, SQLite commit scope. https://hesela.com/analyses/wal-checkpoints-torn-pages/#sqlite-commit-scope (accessed 2026-10-14)
- [hesela-journal-observation] Hesela: SQLite journal-lifecycle observations, measured synthetic workload and explicit limits. https://hesela.dev/research/sqlite-journal-observation.json (accessed 2026-10-14)

### Rollback protection

URL: https://hesela.dev/terms/rollback-protection/
Also known as: Anti-rollback protection
Status: shipping

Record updated: 2026-10-15

Rollback protection rejects protected state older than an enforced version or freshness boundary using trusted state that cannot be rolled back with the protected object.

Note: Android Verified Boot's locked-state policy compares image rollback indexes with protected stored minimums and accepts equality; index checking is not required in the unlocked state. This boot policy does not establish freshness for arbitrary mutable user data. [android-rollback] [avb-policy] Hesela's architectural inference: an older image sharing an accepted index is not rejected by that comparison alone, and an expected version inside the same restorable snapshot is not an independent freshness reference. Authorized restore needs an explicit policy. [hesela-freshness] Each relevant index location must pass separately; a higher index elsewhere does not compensate for a lower one. For Android-style A/B fallback, the documented update policy advances stored indexes only from a slot marked successful. [avb-policy]

Related terms:
- [replay-attack](https://hesela.dev/terms/replay-attack/)
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)
- [dm-verity](https://hesela.dev/terms/dm-verity/)
- [dm-integrity](https://hesela.dev/terms/dm-integrity/)

Citations:
- [android-rollback] Android Open Source Project: Use Verified Boot, Rollback protection. https://source.android.com/docs/security/features/verifiedboot/verified-boot#rollback-protection (accessed 2026-10-15)
- [hesela-freshness] Hesela: A trusted root still needs a version policy. https://hesela.com/analyses/checksums-identity-and-lost-writes/#verity-freshness (accessed 2026-10-15)
- [avb-policy] Android Verified Boot README at 5ac0c3a: Rollback Protection and Recommended Bootflow. https://android.googlesource.com/platform/external/avb/+/5ac0c3a071d811846a62412383dd6e259f341e6e/README.md (accessed 2026-10-15)

### Rolling hash

URL: https://hesela.dev/terms/rolling-hash/
Also known as: rolling fingerprint
Status: shipping

Record updated: 2026-10-12

A rolling hash updates a fingerprint incrementally as the input window or stream advances, instead of recomputing it over the entire input each time.

Note: Restic's chunker uses Rabin fingerprints for boundary selection. Such a boundary fingerprint is not a cryptographic identifier of the complete chunk; content identity needs a separate check. [restic-chunker]

Related terms:
- [content-defined-chunking](https://hesela.dev/terms/content-defined-chunking/)
- [fastcdc](https://hesela.dev/terms/fastcdc/)
- [deduplication](https://hesela.dev/terms/deduplication/)

Citations:
- [restic-chunker] Restic project. Chunker: Rabin-based content-defined chunking implementation and explanation.. https://github.com/restic/chunker (accessed 2026-10-12)
- [hesela-cdc] Content-defined chunking: boundaries are not identity. https://hesela.com/analyses/content-defined-chunking-boundaries/ (accessed 2026-10-12)

### Rotational latency

URL: https://hesela.dev/terms/rotational-latency/
Status: shipping

Average time for the platter to rotate the requested sector under the head after a seek.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)

Citations:
- [c1] Rotational latency. https://en.wikipedia.org/wiki/Hard_disk_drive (accessed 2026-03-26)

### Rotational media

URL: https://hesela.dev/terms/rotational-media/
Status: shipping

Collective term for HDDs, optical disks, and tape that depend on moving surfaces.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [tape](https://hesela.dev/terms/tape/)
- [optical-archival](https://hesela.dev/terms/optical-archival/)

Citations:
- [c1] Rotational media. https://en.wikipedia.org/wiki/Hard_disk_drive (accessed 2026-03-26)

### Rotational vibration (RV)

URL: https://hesela.dev/terms/rotational-vibration/
Also known as: RV
Status: shipping

Record updated: 2026-10-15

Rotational vibration is angular oscillatory motion that can disturb an HDD's ability to keep its heads aligned with recording tracks.

Note: RV is not restricted to spindle-generated motion: drive mechanics and their coupling through an enclosure matter [mechanics]. Seagate describes RV sensors feeding its servo control system to counter off-track motion [rv]. Angular acceleration uses units such as rad/s^2; linear shaker acceleration in g is a different quantity. Reduced throughput during vibration is not by itself proof of permanent damage [analysis].

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [jbod](https://hesela.dev/terms/jbod/)
- [head-disk-interface](https://hesela.dev/terms/head-disk-interface/)

Citations:
- [rv] Seagate ImagePerfect: RV Sensors Detect Vibration, PDF page 4. https://www.seagate.com/www-content/surveillance-center/files/ImagePerfect.pdf (accessed 2026-10-15)
- [mechanics] Seagate: Reliability, Understanding the Critical Factor Behind Disk Storage, Rattle and Hmmm sidebar. https://www.seagate.com/files/www-content/ti-dm/articles/_content/reliability-understanding-the-critical-factor-behind-disk-storage.pdf (accessed 2026-10-15)
- [analysis] Hesela: HDD mechanical faults, evidence and diagnostic limits. https://hesela.com/analyses/hdd-mechanical-failure-points/ (accessed 2026-10-15)

### Run-length limited (RLL) encoding

URL: https://hesela.dev/terms/run-length-limited/
Status: eol

A magnetic recording code limiting consecutive same-polarity bits to increase linear density.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [longitudinal-recording](https://hesela.dev/terms/longitudinal-recording/)

Citations:
- [c1] Run-length limited (RLL) encoding. https://en.wikipedia.org/wiki/Run-length_limited (accessed 2026-03-26)

### RWF_ATOMIC

URL: https://hesela.dev/terms/rwf-atomic/
Status: shipping

Record updated: 2026-10-12

RWF_ATOMIC is a Linux pwritev2 flag requesting torn-write protection for the data range of a supported direct-I/O write.

Note: Request geometry must obey the reported size and vector limits, with power-of-two total length and natural offset alignment. Synchronized I/O semantics are separate from this protection; O_DIRECT alone does not supply O_SYNC guarantees.

Related terms:
- [torn-write](https://hesela.dev/terms/torn-write/)
- [statx-write-atomic](https://hesela.dev/terms/statx-write-atomic/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [pwritev2] Linux man-pages, readv(2): pwritev2 and RWF_ATOMIC. https://man7.org/linux/man-pages/man2/readv.2.html (accessed 2026-10-12)
- [open] Linux man-pages, open(2): O_DIRECT, O_DSYNC and O_SYNC. https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-12)
- [hesela-atomic] Linux atomic writes: untorn does not mean durable. https://hesela.com/analyses/linux-atomic-writes-durability/ (accessed 2026-10-12)

### RWF_DONTCACHE

URL: https://hesela.dev/terms/rwf-dontcache/
Also known as: uncached buffered I/O, buffered I/O drop-behind
Status: shipping

Record updated: 2026-10-15

RWF_DONTCACHE is a Linux per-operation flag requesting best-effort removal of page-cache content newly instantiated by a buffered read or write.

Note: The flag is documented since Linux 6.14; previously cached ranges are not pruned by the hint, and unsupported targets report EOPNOTSUPP. Writes initiate writeback, which is not a durability guarantee. [rwf-api] The v6.14 filemap_read path still copies cached folios to the caller before attempting drop-behind; this is not O_DIRECT or proof of zero-copy transfer. [dropbehind-source]

Advantages:
- Can limit cache retention for one-pass buffered access while retaining already cached ranges.

Limitations:
- No hard guarantee of final cache state, durable completion or improved throughput.

Related terms:
- [buffered-io](https://hesela.dev/terms/buffered-io/)
- [page-cache](https://hesela.dev/terms/page-cache/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [posix-fadv-noreuse](https://hesela.dev/terms/posix-fadv-noreuse/)
- [posix-fadv-dontneed](https://hesela.dev/terms/posix-fadv-dontneed/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [rwf-api] Linux man-pages 6.19: readv(2), RWF_DONTCACHE and RWF_DSYNC/RWF_SYNC.. https://man7.org/linux/man-pages/man2/readv.2.html (accessed 2026-10-15)
- [dropbehind-source] Linux v6.14 mm/filemap.c: filemap_read and drop-behind read completion.. https://github.com/torvalds/linux/blob/v6.14/mm/filemap.c (accessed 2026-10-15)

### SAN

URL: https://hesela.dev/terms/san/
Status: shipping

Storage area network provides block access over Fibre Channel or iSCSI to multiple servers.

Related terms:
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [iscsi](https://hesela.dev/terms/iscsi/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [alua](https://hesela.dev/terms/alua/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)

Citations:
- [c1] SAN. https://en.wikipedia.org/wiki/Storage_area_network (accessed 2026-03-26)

### Sanitization validation

URL: https://hesela.dev/terms/sanitization-validation/
Also known as: Media sanitization validation
Status: shipping

Record updated: 2026-10-14

Sanitization validation decides whether to accept or reject a sanitization result after evaluating its evidence, suitability and remaining risk to data confidentiality.

Note: NIST SP 800-88 Rev. 2 section 4.5.2 considers verification results together with anomalies, inaccessible media areas and whether the chosen technique suits the medium and information sensitivity. A successful tool report is not sufficient when the technique is inappropriate. Rejection calls for another suitable technique or a stronger method, with media reusability checked again; it is not permission to repeat the same failed procedure indefinitely. [nist-r2]

Advantages:
- Makes release depend on the adequacy of the result, rather than merely completion of a workflow. (sources: [nist-r2])

Limitations:
- An acceptance record cannot turn an unsuitable technique or unresolved confidentiality risk into effective sanitization. (sources: [nist-r2])

Related terms:
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [sanitization-verification](https://hesela.dev/terms/sanitization-verification/)
- [clear-sanitization](https://hesela.dev/terms/clear-sanitization/)
- [purge-sanitization](https://hesela.dev/terms/purge-sanitization/)
- [destroy-sanitization](https://hesela.dev/terms/destroy-sanitization/)
- [cryptographic-erase](https://hesela.dev/terms/cryptographic-erase/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, 4.5.2 and 4.6, printed pages 24-26. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-14)

### Sanitization verification

URL: https://hesela.dev/terms/sanitization-verification/
Also known as: Media sanitization verification
Status: shipping

Record updated: 2026-10-14

Sanitization verification inspects the outcome of a sanitization operation to determine whether the selected technique completed successfully.

Note: For clear and logical purge, NIST SP 800-88 Rev. 2 section 4.5.1 describes checking completion status, errors, anomalies and media health. For physical purge, check the sanitizing equipment's completion; for destruction, inspect the remnants and identify the equipment. Elaborate post-clear or post-purge content sampling is not necessary unless organizational policy requires it. Verification supplies evidence for validation; it is not the acceptance decision itself. [nist-r2]

Advantages:
- Separates observed operation results from the later decision about acceptable confidentiality risk. (sources: [nist-r2])

Limitations:
- A submitted command or a full progress counter is not necessarily a final successful operation result; interpret the relevant status semantics. (sources: [nvme-2-0e])

Related terms:
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)
- [clear-sanitization](https://hesela.dev/terms/clear-sanitization/)
- [purge-sanitization](https://hesela.dev/terms/purge-sanitization/)
- [destroy-sanitization](https://hesela.dev/terms/destroy-sanitization/)
- [sanitize-nvme](https://hesela.dev/terms/sanitize-nvme/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, 4.5.1, printed page 24. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-14)
- [nvme-2-0e] NVM Express Base Specification 2.0e, sections 5.24 and 5.16.1.25. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0e-2024.07.29-Ratified.pdf (accessed 2026-10-10)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-14)

### NVMe sanitize

URL: https://hesela.dev/terms/sanitize-nvme/
Status: shipping

Record updated: 2026-10-14

NVMe Sanitize starts a controller-managed sanitization operation using a supported Block Erase, Overwrite or Crypto Erase action.

Note: The cited Base Specification 2.0e describes background processing: command completion is not operation completion. Inspect controller capabilities and the Sanitize Status log. Interpret the status field, not only progress: SPROG is FFFFh whenever the operation is not in progress, including states that do not establish success.

Advantages:
- Provides a dedicated status log for the sanitization operation. (sources: [nvme-2-0e])

Limitations:
- Supported actions vary; verify capability and completion before accepting the result. (sources: [nvme-2-0e])

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [secure-erase](https://hesela.dev/terms/secure-erase/)
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [cryptographic-erase](https://hesela.dev/terms/cryptographic-erase/)
- [sanitization-verification](https://hesela.dev/terms/sanitization-verification/)
- [sanitization-validation](https://hesela.dev/terms/sanitization-validation/)

Citations:
- [nvme-2-0e] NVM Express Base Specification 2.0e, sections 5.24 and 5.16.1.25. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0e-2024.07.29-Ratified.pdf (accessed 2026-10-10)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-10)

### SAS expander

URL: https://hesela.dev/terms/sas-expander/
Status: shipping

A switch-like component that fans out SAS ports so many drives share fewer host links.

Related terms:
- [sas](https://hesela.dev/terms/sas/)
- [jbod](https://hesela.dev/terms/jbod/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] SAS expander. https://en.wikipedia.org/wiki/Serial_Attached_SCSI (accessed 2026-03-26)

### SAS PHY event counters

URL: https://hesela.dev/terms/sas-phy-event-counters/
Also known as: SAS PHY error counters, SAS physical-layer event counters
Status: shipping

Record updated: 2026-10-15

SAS PHY event counters are per-physical-link-endpoint counts of specified link events, including invalid DWORDs, disparity errors, synchronization loss and PHY reset problems.

Note: smartmontools 7.5 decodes four 32-bit counters in each SAS PHY descriptor: invalid DWORDs, running disparity errors, loss of DWORD synchronization and PHY reset problems; additional event descriptors may be present [sas-decoder]. These observations are not media-error totals or root-cause labels, and reset problems are not a count of every reset. For supported SAS SSP devices, smartctl -l sasphy reads Protocol Specific log page 0x18 without requesting a counter reset; sasphy,reset reads first and then requests a reset [sasphy-manual]. Preserve initial output and the reset result. Interpretation guidance: compare the same device, port, PHY and reporting endpoint over a recorded interval. Reset, replacement or an unexplained decrease requires a new baseline; do not blindly assume wraparound. Events per hour are not a bit-error rate or drive-failure rate. Linux driver-exposed PHY statistics and target-device log counters are distinct observations and must not be silently combined [linux-sas]. Missing or unsupported telemetry is not a measured zero. Linux v6.12 may print a stored PHY value even when its acquisition callback is absent; successful reading alone does not establish freshness [linux-sas]. smartmontools uses positional JSON keys, not endpoint IDs, and separate read/reset commands, not an atomic read-and-clear [sas-decoder]. The companion analysis explains the evidence boundaries [hesela-link].

Limitations:
- A nonzero count does not identify the faulty cable, backplane, controller or drive.
- Comparisons require endpoint identity and continuous counter history; collection support depends on device, controller and driver.

Related terms:
- [sas](https://hesela.dev/terms/sas/)
- [scsi](https://hesela.dev/terms/scsi/)

Citations:
- [sas-decoder] smartmontools 7.5: SAS port/PHY decoding and optional log reset. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/scsiprint.cpp (accessed 2026-10-15)
- [sasphy-manual] smartmontools 7.5: smartctl sasphy and sasphy,reset. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/smartctl.8.in (accessed 2026-10-15)
- [linux-sas] Linux v6.12: SAS PHY identity and link-error attributes. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/drivers/scsi/scsi_transport_sas.c (accessed 2026-10-15)
- [hesela-link] SATA and SAS link errors: what counters can and cannot diagnose. https://hesela.com/analyses/sata-sas-link-failure-signatures/ (accessed 2026-10-15)

### Serial Attached SCSI (SAS)

URL: https://hesela.dev/terms/sas/
Also known as: SAS
Status: shipping

Record updated: 2026-10-15

An enterprise storage interface that extends SCSI semantics over a serial point-to-point or expander topology.

Note: Serial Attached SCSI is a point-to-point serial interconnect and protocol family that carries SCSI command sets for enterprise disks and SSDs. Hosts and expanders form SAS domains; dual-port drives support multipath high availability. Link rates have scaled through generations commonly marketed as 3, 6, and 12 Gbit/s (and faster in later specs). Nearline HDD fleets and many enterprise SSDs still use SAS for dual-port and expander topologies that SATA does not match. SCSI zoning for host-managed SMR uses ZBC on SAS paths. SAS is about domain topology and SCSI semantics—not a recording technology. SAS succeeds parallel SCSI transport, not SCSI command semantics. [t10-architecture] For link diagnostics, SAS PHY event counters describe a particular endpoint rather than proving a media fault or identifying a defective component [sas-decoder]. Compare reset-aware observations for the same device, port and PHY; device-log and driver-exposed counters are not interchangeable [linux-sas]. See the companion diagnostic analysis [hesela-link].

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [hdd](https://hesela.dev/terms/hdd/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)
- [sas-phy-event-counters](https://hesela.dev/terms/sas-phy-event-counters/)

Citations:
- [c1] Serial Attached SCSI. https://en.wikipedia.org/wiki/Serial_Attached_SCSI (accessed 2026-03-26)
- [n2] SCSI Trade Association — Serial Attached SCSI overview. https://www.scsi.org/sas/ (accessed 2026-10-07)
- [n3] Zoned Storage — SMR / ZBC on SCSI (SAS path). https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-07)
- [t10-architecture] T10 working drafts: SCSI architecture, command sets and transports. https://www.t10.org/drafts.htm (accessed 2026-10-13)
- [sas-decoder] smartmontools 7.5: SAS port/PHY decoding and optional log reset. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/scsiprint.cpp (accessed 2026-10-15)
- [linux-sas] Linux v6.12: SAS PHY identity and link-error attributes. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/drivers/scsi/scsi_transport_sas.c (accessed 2026-10-15)
- [hesela-link] SATA and SAS link errors: what counters can and cannot diagnose. https://hesela.com/analyses/sata-sas-link-failure-signatures/ (accessed 2026-10-15)

### SATA Express

URL: https://hesela.dev/terms/sata-express/
Status: eol

A connector standard that multiplexed SATA and PCIe lanes for faster client storage before M.2 NVMe.

Related terms:
- [sata](https://hesela.dev/terms/sata/)
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [m2](https://hesela.dev/terms/m2/)
- [ahci](https://hesela.dev/terms/ahci/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] SATA Express. https://en.wikipedia.org/wiki/SATA_Express (accessed 2026-03-26)

### SATA PHY event counters

URL: https://hesela.dev/terms/sata-phy-event-counters/
Also known as: SATA Phy Event Counters, SATA log 0x11
Status: shipping

Record updated: 2026-10-15

SATA PHY event counters record distinct interface events in General Purpose Log 0x11 rather than measuring a disk failure rate.

Note: smartctl -l sataphy reads this log; adding ,reset clears its counters after reading. In smartmontools 7.5, event 0x000a describes register responses following COMRESET, whereas 0x000b concerns host-to-device CRC errors. Saturated counters are marked with +. Preserve device identity, timestamps and reset history when comparing observations; a counter is not a component diagnosis.

Related terms:
- [sata](https://hesela.dev/terms/sata/)
- [native-command-queuing](https://hesela.dev/terms/native-command-queuing/)
- [smart](https://hesela.dev/terms/smart/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [smartctl] smartmontools 7.5: smartctl manual, attributes and PHY log options. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/smartctl.8.in (accessed 2026-10-15)
- [smart-print] smartmontools 7.5: PrintSataPhyEventCounters decoder. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/ataprint.cpp (accessed 2026-10-15)
- [hesela-link] SATA link errors: what CRC flags, NCQ recovery and PHY counters prove. https://hesela.com/analyses/sata-sas-link-failure-signatures/ (accessed 2026-10-15)

### Serial ATA (SATA)

URL: https://hesela.dev/terms/sata/
Also known as: SATA III, AHCI attachment
Status: shipping

Record updated: 2026-10-15

Recorded firstSeen: 2003 (sources: [c1])

A serial bus interface and protocol family for attaching HDDs and SSDs, widely used in PCs and servers.

Note: Serial ATA replaces parallel ATA’s wide ribbon with a point-to-point serial link between host and device, carrying ATA command sets over thinner cables with hot-plug-capable connectors in common consumer and entry-server use. Generations progressed through 1.5, 3.0, and 6.0 Gbit/s signaling; 6 Gbit/s remains the practical ceiling for most SATA HDDs and SATA SSDs. Topology is one device per host port (port multipliers exist but are uncommon in modern PCs). AHCI is the usual host controller interface for SATA in software. SATA still ships widely on 3.5-inch HDDs and 2.5-inch/M.2 SATA SSDs, while high-performance flash has largely moved to NVMe/PCIe.

Limitations:
- Throughput ceiling below modern PCIe/NVMe for high-performance SSDs. (sources: [c1])

Related terms:
- [pata](https://hesela.dev/terms/pata/)
- [ssd](https://hesela.dev/terms/ssd/)
- [hdd](https://hesela.dev/terms/hdd/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [trim](https://hesela.dev/terms/trim/)
- [ahci](https://hesela.dev/terms/ahci/)
- [native-command-queuing](https://hesela.dev/terms/native-command-queuing/)
- [sata-phy-event-counters](https://hesela.dev/terms/sata-phy-event-counters/)

Supersedes:
- [pata](https://hesela.dev/terms/pata/)

Citations:
- [c1] Serial ATA. https://en.wikipedia.org/wiki/Serial_ATA (accessed 2026-03-26)
- [n2] SATA-IO — Serial ATA Revision 3.5a specification PDF. https://sata-io.org/system/files/specifications/Serial%20ATA%20Revision%203.5a.pdf (accessed 2026-10-07)
- [n3] SATA-IO — Archived / purchase specifications. https://sata-io.org/developers/purchase-specification (accessed 2026-10-07)
- [n4] SNIA — NVMe, SAS, and SATA SSD endurance white paper (interface context). https://www.snia.org/sites/default/files/SSSI/NVMe_SAS_SATA_Endurance_White_Paper.pdf (accessed 2026-10-07)

### SCSI CHECK CONDITION

URL: https://hesela.dev/terms/scsi-check-condition/
Also known as: CHECK CONDITION
Status: shipping

Record updated: 2026-10-13

CHECK CONDITION is a SCSI command status used to report a condition described by sense information.

Note: The status is 02h, distinct from the sense key. It does not by itself identify a defective drive: an unsupported request, changed device state or access restriction can also cause a report. [seagate-sense] iSCSI carries sense data with this status using Autosense; do not assume that every transport requires a separate REQUEST SENSE command. [rfc7143]

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [scsi-sense-key](https://hesela.dev/terms/scsi-sense-key/)
- [additional-sense-code](https://hesela.dev/terms/additional-sense-code/)
- [additional-sense-code-qualifier](https://hesela.dev/terms/additional-sense-code-qualifier/)

Citations:
- [seagate-sense] Seagate SCSI Commands Reference, Rev. H, sections 2.4.1.3-2.4.1.5. https://www.seagate.com/files/staticfiles/support/docs/manual/Interface%20manuals/100293068h.pdf (accessed 2026-10-13)
- [rfc7143] RFC 7143: SCSI concepts and iSCSI transport; sections 4.1, 4.2 and 11.4.7. https://www.rfc-editor.org/rfc/rfc7143.html (accessed 2026-10-13)
- [t10-keys] T10: SCSI sense-key assignments. https://www.t10.org/lists/2sensekey.htm (accessed 2026-10-13)
- [hesela-sense] Media error or link error? SCSI sense codes and Linux ATA logs. https://hesela.com/analyses/scsi-sense-kernel-log-signatures/ (accessed 2026-10-13)

### SCSI persistent reservations

URL: https://hesela.dev/terms/scsi-persistent-reservations/
Also known as: SCSI PR, SCSI-3 PR
Status: shipping

Record updated: 2026-10-11

SCSI persistent reservations control initiator access to a logical unit using registered keys and a selected reservation type.

Note: Registration and reservation are separate operations. Write Exclusive permits only the holder to write, while Write Exclusive, Registrants Only permits all registered initiators to write. The scope is the LUN, not its partitions. Persistence through power loss depends on applicable support and configuration, including APTPL; do not infer it from the word persistent. Linux's simplified PR interface has stronger persistence and multipath expectations than the optional SPC behaviors.

Related terms:
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [scsi](https://hesela.dev/terms/scsi/)
- [multipath-io](https://hesela.dev/terms/multipath-io/)
- [logical-unit-number](https://hesela.dev/terms/logical-unit-number/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)

Citations:
- [sg-persist] Douglas Gilbert, sg3_utils: sg_persist(8), registration, reservation and APTPL semantics.. https://github.com/doug-gilbert/sg3_utils/blob/main/doc/sg_persist.8 (accessed 2026-10-11)
- [linux-pr] Linux kernel documentation: Block layer support for Persistent Reservations.. https://docs.kernel.org/block/pr.html (accessed 2026-10-11)
- [rhel-scsi] Red Hat Enterprise Linux 6, Fence Configuration Guide 4.28: SCSI Persistent Reservations (historical guide, LUN scope).. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/fence_configuration_guide/s1-software-fence-scsi-ca (accessed 2026-10-11)
- [hesela-fencing] Storage fencing: why a lost heartbeat does not stop writes. https://hesela.com/analyses/storage-fencing-stale-writes/ (accessed 2026-10-11)

### SCSI sense key

URL: https://hesela.dev/terms/scsi-sense-key/
Also known as: sense key
Status: shipping

Record updated: 2026-10-13

A SCSI sense key is a four-bit field identifying the broad category of a condition reported in sense data.

Note: Interpret the category with the ASC/ASCQ pair and command context; the key alone is not a physical root-cause diagnosis. [t10-keys] Field locations differ between fixed and descriptor formats, so decode the response code before reading the key. [linux-sense]

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [scsi-check-condition](https://hesela.dev/terms/scsi-check-condition/)
- [additional-sense-code](https://hesela.dev/terms/additional-sense-code/)
- [additional-sense-code-qualifier](https://hesela.dev/terms/additional-sense-code-qualifier/)

Citations:
- [t10-keys] T10: SCSI sense-key assignments. https://www.t10.org/lists/2sensekey.htm (accessed 2026-10-13)
- [linux-sense] Linux v6.12: scsi_normalize_sense, fixed and descriptor field extraction. https://github.com/torvalds/linux/blob/v6.12/drivers/scsi/scsi_common.c (accessed 2026-10-13)
- [hesela-sense] Media error or link error? SCSI sense codes and Linux ATA logs. https://hesela.com/analyses/scsi-sense-kernel-log-signatures/ (accessed 2026-10-13)

### SCSI UNMAP

URL: https://hesela.dev/terms/scsi-unmap/
Status: shipping

A SCSI command that requests deallocation of specified logical block ranges.

Note: UNMAP belongs to SCSI logical block provisioning. ATA TRIM is a related capability, not a SCSI command name. SCSI WRITE SAME can also request unmapping, so deallocation is not limited to the UNMAP opcode. Consult the target's provisioning capabilities and command documentation before interpreting readback.

Limitations:
- Issuing UNMAP is destructive and must not be treated as a harmless capability probe. (sources: [sg-unmap])

Related terms:
- [discard](https://hesela.dev/terms/discard/)
- [trim](https://hesela.dev/terms/trim/)
- [sas](https://hesela.dev/terms/sas/)
- [unmap](https://hesela.dev/terms/unmap/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [deallocated-read-behavior](https://hesela.dev/terms/deallocated-read-behavior/)

Citations:
- [sg-unmap] sg3_utils: sg_unmap manual, description. https://raw.githubusercontent.com/hreinecke/sg3_utils/master/doc/sg_unmap.8 (accessed 2026-10-11)
- [hesela-discard] Hesela: Discard is not zeroing. https://hesela.com/analyses/discard-is-not-zeroing/ (accessed 2026-10-11)

### SCSI

URL: https://hesela.dev/terms/scsi/
Also known as: Small Computer System Interface
Status: shipping

Record updated: 2026-10-13

Recorded firstSeen: 1986 (sources: [c1])

Small Computer System Interface (SCSI) is a family of standards for device commands, logical units, status reporting and the transports that carry them.

Note: Parallel SCSI is a historical transport, not the whole SCSI architecture; SAS carries SCSI commands and iSCSI maps the command model onto TCP. [t10-architecture] [rfc7143] The retained 1986 first-seen entry refers to the original standard, not the end of the later standards family.

Related terms:
- [sas](https://hesela.dev/terms/sas/)
- [tape](https://hesela.dev/terms/tape/)
- [hdd](https://hesela.dev/terms/hdd/)
- [alua](https://hesela.dev/terms/alua/)
- [st-412](https://hesela.dev/terms/st-412/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)
- [iscsi](https://hesela.dev/terms/iscsi/)
- [t10-scsi](https://hesela.dev/terms/t10-scsi/)
- [scsi-check-condition](https://hesela.dev/terms/scsi-check-condition/)
- [scsi-sense-key](https://hesela.dev/terms/scsi-sense-key/)
- [additional-sense-code](https://hesela.dev/terms/additional-sense-code/)
- [additional-sense-code-qualifier](https://hesela.dev/terms/additional-sense-code-qualifier/)

Citations:
- [c1] SCSI. https://en.wikipedia.org/wiki/SCSI (accessed 2026-03-26)
- [t10-architecture] T10 working drafts: SCSI architecture, command sets and transports. https://www.t10.org/drafts.htm (accessed 2026-10-13)
- [rfc7143] RFC 7143: SCSI concepts and iSCSI transport; sections 4.1, 4.2 and 11.4.7. https://www.rfc-editor.org/rfc/rfc7143.html (accessed 2026-10-13)
- [hesela-sense] Media error or link error? SCSI sense codes and Linux ATA logs. https://hesela.com/analyses/scsi-sense-kernel-log-signatures/ (accessed 2026-10-13)

### SD Express

URL: https://hesela.dev/terms/sd-express/
Status: shipping

Recorded firstSeen: 2018-06 (sources: [c1])

Secure Digital cards with a second row of pins for PCIe/NVMe attachment alongside legacy SD modes.

Note: SD Express adds a PCI Express lane and the NVMe protocol to the SD card, alongside the legacy SD interface. It was introduced in SD specification 7.0 (June 2018) with one PCIe 3.x lane, for up to 985 MB/s; SD 8.0 (May 2020) added PCIe 4.0 and dual-lane full-size cards with a third row of contacts, for a theoretical 3938 MB/s, while microSD Express stays single-lane. A full-size SD Express card uses the same pad layout as UHS-II: the PCIe differential pairs take the second row, and the reference clock and the CLKREQ# and PERST# sideband signals are muxed with the first-row SD data lines. Because PCIe reuses that row, SD Express cards do not support UHS-II and fall back to UHS-I speeds in older hosts. The card introduces itself as a standard NVMe device, so existing PCIe/NVMe drivers work; per the SD Association host guideline, only the SD driver needs updating to switch between SD mode and PCIe mode, and the association recommends an SD-first initialization. In PCIe mode the card needs the 3.3 V supply (VDD1) first and then the 1.8 V supply (VDD2), may draw at most 1.80 W, and supports three NVMe power states (1.8 W default, 1.44 W, 0.72 W) that a host can use for thermal management. SD 9.10 (2023) added the E150, E300, E450 and E600 speed classes, which guarantee minimum sustained write speeds of 150 to 600 MB/s. Wikipedia notes that as of June 2025 only single-lane PCIe 3.1 cards were on sale commercially, and that SD Express cards support DMA, which security researchers have warned can enlarge the attack surface if a card is malicious.

Advantages:
- Standard PCIe/NVMe interface lets hosts reuse existing PCIe and NVMe drivers and test equipment
- Up to 985 MB/s on a single PCIe 3.x lane, against up to 104 MB/s for UHS-I and 312 MB/s for UHS-II
- Cards stay backward compatible with legacy SD hosts, which see them as UHS-I cards

Limitations:
- No UHS-II support, because PCIe takes over the second pin row, so older hosts run the card at UHS-I speeds
- Hosts need a PCIe interface, a mux for the shared pins, and the two supplies (VDD1 then VDD2) in addition to a normal SD controller
- Power is capped at 1.80 W per card, so sustained use needs host thermal management
- Adoption has been slow; as of June 2025 only single-lane PCIe 3.1 cards were commercially available per Wikipedia

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)
- [pcie-gen4](https://hesela.dev/terms/pcie-gen4/)
- [nvme-base-spec](https://hesela.dev/terms/nvme-base-spec/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [thermal-throttling-ssd](https://hesela.dev/terms/thermal-throttling-ssd/)
- [cfexpress](https://hesela.dev/terms/cfexpress/)
- [m2](https://hesela.dev/terms/m2/)
- [usb-mass-storage](https://hesela.dev/terms/usb-mass-storage/)

Citations:
- [c1] SD card (Wikipedia; the SD Express page redirects here). https://en.wikipedia.org/wiki/SD_Express (accessed 2026-10-10)
- [c2] SD Express (SD7.x) Host Implementation Guideline, SD Association, May 2020. https://www.sdcard.org/pdf/SD_Express_Design_Guide.pdf (accessed 2026-10-10)

### Secure erase

URL: https://hesela.dev/terms/secure-erase/
Status: shipping

Secure erase is a context-dependent label for a storage erasure procedure whose command, scope and assurance must be specified.

Note: Do not treat a utility's label as a protocol guarantee. Distinguish an ATA SECURITY ERASE operation, NVMe Format NVM and NVMe Sanitize, and check the selected device's documentation. NIST separates sanitization methods from particular techniques; a method's suitability depends on the medium and confidentiality requirement.

Limitations:
- File deletion, ordinary discard and a user-addressable overwrite are not interchangeable with an approved purge technique. (sources: [nist-r2], [discard])

Related terms:
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [sanitize-nvme](https://hesela.dev/terms/sanitize-nvme/)
- [self-encrypting-drive](https://hesela.dev/terms/self-encrypting-drive/)
- [cryptographic-erase](https://hesela.dev/terms/cryptographic-erase/)
- [trim](https://hesela.dev/terms/trim/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, sections 3 and 4.5. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-10)
- [nvme-2-0e] NVM Express Base Specification 2.0e, sections 5.24 and 5.16.1.25. https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0e-2024.07.29-Ratified.pdf (accessed 2026-10-10)
- [discard] util-linux: blkdiscard documentation. https://github.com/util-linux/util-linux/blob/master/sys-utils/blkdiscard.8.adoc (accessed 2026-10-10)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-10)

### Seek time

URL: https://hesela.dev/terms/seek-time/
Status: shipping

Time for the actuator to move the head stack to the correct track on a hard disk.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [dual-actuator](https://hesela.dev/terms/dual-actuator/)
- [st-412](https://hesela.dev/terms/st-412/)

Citations:
- [c1] Seek time. https://en.wikipedia.org/wiki/Hard_disk_drive (accessed 2026-03-26)

### Self-encrypting drive (SED)

URL: https://hesela.dev/terms/self-encrypting-drive/
Status: shipping

A self-encrypting drive encrypts stored data internally using integrated cryptographic and key-management capabilities.

Note: Self-encryption does not by itself establish an acceptable cryptographic erase. The encryption must have covered the target sensitive data, and the applicable keys must be sanitizable. NIST also calls for scrutiny of backed-up or escrowed keys and the required lifetime of confidentiality.

Limitations:
- An encryption feature label is not evidence that every relevant key copy has been sanitized. (sources: [nist-r2])

Related terms:
- [tcg-opal](https://hesela.dev/terms/tcg-opal/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [cryptographic-erase](https://hesela.dev/terms/cryptographic-erase/)
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)

Citations:
- [nist-r2] NIST SP 800-88 Rev. 2 (2025), Guidelines for Media Sanitization, sections 3 and 4.5. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf (accessed 2026-10-10)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-10)

### Serializability

URL: https://hesela.dev/terms/serializability/
Also known as: Serializable isolation
Status: shipping

Record updated: 2026-10-12

Serializability is a transaction-isolation property under which the read results and writes of committed concurrent transactions are equivalent to some serial execution of those transactions.

Note: The equivalent order need not preserve real-time precedence; strict serializability adds that constraint. This does not require executing transactions physically one at a time. PostgreSQL's Serializable mode can abort a transaction to prevent a serialization anomaly, so applications must handle retries. Neither the term nor a read option named serializable independently specifies durability. Matching final values alone is not enough to establish equivalence. Snapshot isolation can allow write skew across different rows.

Related terms:
- [linearizability](https://hesela.dev/terms/linearizability/)
- [compare-and-swap](https://hesela.dev/terms/compare-and-swap/)
- [snapshot-isolation](https://hesela.dev/terms/snapshot-isolation/)
- [write-skew](https://hesela.dev/terms/write-skew/)

Citations:
- [herlihy-wing] Maurice P. Herlihy and Jeannette M. Wing. Linearizability: A Correctness Condition for Concurrent Objects. ACM TOPLAS 12(3), 1990, sections 2.2 and 3.3.. https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf (accessed 2026-10-12)
- [postgres-isolation] PostgreSQL 18 documentation, section 13.2: Transaction Isolation.. https://www.postgresql.org/docs/18/transaction-iso.html (accessed 2026-10-12)
- [etcd-guarantees] etcd v3.6 API guarantees: durability, strict serializability and operation completion.. https://etcd.io/docs/v3.6/learning/api_guarantees/ (accessed 2026-10-12)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-12)
- [berenson-isolation] Hal Berenson et al. A Critique of ANSI SQL Isolation Levels. ACM SIGMOD 1995; MSR-TR-95-51, section 4.2.. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf (accessed 2026-10-12)

### Session guarantees

URL: https://hesela.dev/terms/session-guarantees/
Also known as: Session consistency guarantees
Status: shipping

Record updated: 2026-10-13

Session guarantees are consistency contracts for a session's operations, including read-your-writes, monotonic reads, monotonic writes and writes-follow-reads.

Note: Specify the requested guarantees and how session context is retained. Implementations differ: Azure Cosmos DB uses partition-bound tokens; recreating a client loses its token cache. A session is not an atomic transaction, and its label alone does not specify a durability contract.

Related terms:
- [read-your-writes](https://hesela.dev/terms/read-your-writes/)
- [monotonic-reads](https://hesela.dev/terms/monotonic-reads/)
- [monotonic-writes](https://hesela.dev/terms/monotonic-writes/)
- [writes-follow-reads](https://hesela.dev/terms/writes-follow-reads/)

Citations:
- [session-guarantees] Douglas B. Terry et al. Session Guarantees for Weakly Consistent Replicated Data. PDIS 1994, sections 3.1-3.4, pp. 142-144.. https://classes.cs.uchicago.edu/archive/2026/spring/23380-1/papers/terry_sessionguarantees.pdf (accessed 2026-10-13)
- [mongodb-sessions] MongoDB Manual: Read Isolation, Consistency, and Recency; client sessions, causal guarantees and isolation.. https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency/ (accessed 2026-10-13)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-13)
- [cosmos-sessions] Microsoft Learn: Consistency levels in Azure Cosmos DB; session consistency and partition-bound tokens.. https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels (accessed 2026-10-13)
- [mongodb-concerns] MongoDB Manual: Causal Consistency and Read and Write Concerns; durability and rollback distinctions.. https://www.mongodb.com/docs/manual/core/causal-consistency-read-write-concerns/ (accessed 2026-10-13)

### Set reconciliation

URL: https://hesela.dev/terms/set-reconciliation/
Also known as: Set difference reconciliation
Status: research

Record updated: 2026-10-16

Set reconciliation is the task of identifying items present in one of two sets but not the other.

Note: Database reconciliation can encode record identifiers together with record checksums, rather than comparing identifiers alone. [iblt2011] Hesela's example shows why equal key sets can conceal unequal values; discovering a difference does not select the authoritative version. [hesela-repair]

Related terms:
- [anti-entropy-repair](https://hesela.dev/terms/anti-entropy-repair/)
- [merkle-tree](https://hesela.dev/terms/merkle-tree/)
- [invertible-bloom-lookup-table](https://hesela.dev/terms/invertible-bloom-lookup-table/)
- [rateless-iblt](https://hesela.dev/terms/rateless-iblt/)

Citations:
- [iblt2011] Michael T. Goodrich and Michael Mitzenmacher. Invertible Bloom Lookup Tables. arXiv:1101.2245v3 (2015 revision; first submitted 2011), sections 1.3 and 2.. https://arxiv.org/abs/1101.2245v3 (accessed 2026-10-16)
- [hesela-repair] Hesela: Replica repair, set reconciliation and record identity. https://hesela.com/analyses/replica-repair-coverage/#set-reconciliation (accessed 2026-10-16)

### Shingled band

URL: https://hesela.dev/terms/shingled-band/
Status: shipping

Record updated: 2026-10-15

A shingled band is a group of overlapping magnetic tracks separated from neighboring bands by guard regions that limit overwrite propagation.

Note: A band is a physical recording grouping, not automatically identical to a host-visible zone on every implementation [zoned]. Do not assume every update rewrites a whole band: partial read-modify-write is an implementation possibility, so the simplified full-band model is not a universal I/O cost [analysis].

Related terms:
- [smr](https://hesela.dev/terms/smr/)
- [device-managed-smr](https://hesela.dev/terms/device-managed-smr/)
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [smr-persistent-cache](https://hesela.dev/terms/smr-persistent-cache/)
- [garbage-collection-smr](https://hesela.dev/terms/garbage-collection-smr/)

Citations:
- [c1] Shingled band. https://en.wikipedia.org/wiki/Shingled_magnetic_recording (accessed 2026-03-26)
- [skylight] Aghayev and Desnoyers: Skylight, FAST 2015, sections 4.5-4.6. https://www.usenix.org/system/files/conference/fast15/fast15-paper-aghayev.pdf (accessed 2026-10-15)
- [zoned] Zoned Storage: Shingled Magnetic Recording Hard Disks. https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-15)
- [analysis] Hesela: SMR stalls, cache limits and the errors SMART can miss. https://hesela.com/analyses/smr-drive-failure-signatures/ (accessed 2026-10-15)

### SLC cache

URL: https://hesela.dev/terms/slc-cache/
Also known as: SLC-mode write cache, pseudo-SLC cache
Status: shipping

Record updated: 2026-10-16

A NAND region operated in one-bit mode as a write cache for denser NAND storage, with still-valid data eligible for later migration.

Note: The region can be fixed or variable. In Yoo and Shin's trace-driven simulation, repeated updates can invalidate old cached versions before migration, and some requests bypass the cache. Do not equate host cache traffic with bytes later migrated, or assume a larger region always improves throughput; this is not a retail-drive benchmark. [slc-yoo]

Advantages:
- Can absorb a write burst at a higher rate than the post-cache rate of the same drive. (sources: [slc-qvo-datasheet])

Limitations:
- A product's advertised sequential rate may describe only writes inside its cache; capacity and post-cache rates must be checked separately. (sources: [slc-qvo-datasheet], [slc-qvo-whitepaper])
- Cache size and migration policy depend on the implementation and storage utilization. (sources: [slc-yoo])
- Post-cache host-write throughput is not a specified cache-recovery rate; dividing cache bytes by that figure does not establish a recovery time. (sources: [slc-yoo], [slc-qvo-datasheet])

Related terms:
- [slc](https://hesela.dev/terms/slc/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [pseudo-slc](https://hesela.dev/terms/pseudo-slc/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [dram-cache-ssd](https://hesela.dev/terms/dram-cache-ssd/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)

Citations:
- [slc-yoo] Yoo and Shin - Reinforcement Learning-Based SLC Cache Technique for Enhancing SSD Write Performance, HotStorage 2020, sections 2 and 4. https://www.usenix.org/system/files/hotstorage20_paper_yoo.pdf (accessed 2026-10-16)
- [slc-qvo-datasheet] Samsung - 860 QVO datasheet, Revision 1.0 (October 2018), page 5, notes 2-3. https://download.semiconductor.samsung.com/resources/data-sheet/Samsung%20SSD%20860%20QVO%20Data%20Sheet_Rev1.pdf (accessed 2026-10-16)
- [slc-qvo-whitepaper] Samsung - 860 QVO whitepaper, June 2019, page 4, Table 2. https://download.semiconductor.samsung.com/resources/white-paper/Samsung_SSD_860_QVO_White_paper.pdf (accessed 2026-10-16)

### SLC SSD

URL: https://hesela.dev/terms/slc-ssd/
Status: limited

SSDs built with single-level cell NAND for high endurance industrial or cache use.

Related terms:
- [slc](https://hesela.dev/terms/slc/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)

Citations:
- [c1] SLC SSD. https://en.wikipedia.org/wiki/Single-level_cell (accessed 2026-03-26)

### Single-level cell (SLC)

URL: https://hesela.dev/terms/slc/
Also known as: 1 bit per cell NAND
Status: shipping

Record updated: 2026-10-16

NAND storage of one bit per cell using two distinguishable threshold-voltage states.

Note: SLC describes one-bit storage, not a required charge-storage structure. Native SLC media must be distinguished from pseudo-SLC operation of multi-bit-capable NAND. An SLC cache in a TLC or QLC SSD does not make the whole drive native SLC. Compare the specified component or drive, not an assumed universal endurance rating. [slc-kioxia] [slc-swissbit]

Advantages:
- Fewer states allow wider sensing margins on comparable cells. (sources: [slc-kioxia])

Limitations:
- Lower capacity per cell than multi-bit operation. (sources: [slc-kioxia])

Related terms:
- [mlc](https://hesela.dev/terms/mlc/)
- [tlc](https://hesela.dev/terms/tlc/)
- [qlc](https://hesela.dev/terms/qlc/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)
- [pseudo-slc](https://hesela.dev/terms/pseudo-slc/)
- [slc-cache](https://hesela.dev/terms/slc-cache/)

Citations:
- [slc-kioxia] KIOXIA - Multi-level cell technology: threshold states and capacity. https://www.kioxia.com/en-jp/rd/technology/multi-level-cell.html (accessed 2026-10-16)
- [slc-swissbit] Swissbit - Storage technology, pSLC Mode and Powersafe sections. https://www.swissbit.com/en/technology/storage-technology/ (accessed 2026-10-16)
- [slc-micron] Micron - SLC NAND portfolio and embedded applications. https://www.micron.com/products/storage/nand-flash/slc-nand (accessed 2026-10-16)

### Sloppy quorum

URL: https://hesela.dev/terms/sloppy-quorum/
Status: shipping

Record updated: 2026-10-14

A sloppy quorum allows reachable fallback nodes outside a key's normal replica set to participate when intended replicas are unavailable.

Note: Historical Dynamo selects the first N healthy nodes in its preference list and uses hinted handoff for temporary copies. Different operations can use different replica sets, so R + W > N alone cannot prove their overlap. [dynamo]

Limitations:
- This describes the 2007 Dynamo design, not a guarantee about today's DynamoDB. (sources: [dynamo])

Related terms:
- [quorum-intersection](https://hesela.dev/terms/quorum-intersection/)
- [hinted-handoff](https://hesela.dev/terms/hinted-handoff/)
- [partial-quorum](https://hesela.dev/terms/partial-quorum/)

Citations:
- [dynamo] DeCandia et al. Dynamo: Amazon's Highly Available Key-value Store, SOSP 2007, sections 4.5-4.6.. https://cdn.amazon.science/ac/1d/eb50c4064c538c8ac440ce6a1d91/dynamo-amazons-highly-available-key-value-store.pdf (accessed 2026-10-13)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### Slowdown ratio

URL: https://hesela.dev/terms/slowdown-ratio/
Also known as: Perseus slowdown ratio
Status: research

Record updated: 2026-10-15

In Perseus, the slowdown ratio is observed drive latency divided by the workload-dependent upper prediction bound for that latency.

Note: Use the same units for numerator and denominator: a ratio above one exceeds the bound. Section 4.4 and its example establish this direction despite the reversed Figure 9 caption. This is a sample-level quantity, not a calibrated failure probability or a drive diagnosis. [perseus] Unlike this workload-bound denominator, The Tail at Store uses a RAID-group median for hourly observations; the two ratios are not interchangeable. [hesela-tail]

Related terms:
- [fail-slow](https://hesela.dev/terms/fail-slow/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [open-channel-ssd](https://hesela.dev/terms/open-channel-ssd/)
- [tail-hour](https://hesela.dev/terms/tail-hour/)

Citations:
- [perseus] Lu et al. Perseus: A Fail-Slow Detection Framework for Cloud Storage Systems. FAST 2023, sections 4.4-4.5, pp. 55-56.. https://www.usenix.org/system/files/fast23-lu.pdf (accessed 2026-10-14)
- [hesela-examples] Hesela: synthetic slowdown-ratio arithmetic, source and tests. https://hesela.dev/data/slowdown-ratio-examples.json (accessed 2026-10-14)
- [hesela-tail] Hesela: Slow RAID hours are not request tail latency; source audit and reproducible counterexamples. https://hesela.com/analyses/storage-tail-slowdowns-raid-fanout/ (accessed 2026-10-15)

### SMART normalized value

URL: https://hesela.dev/terms/smart-normalized-value/
Status: shipping

A SMART normalized value is an ATA drive firmware's vendor-specific score for an attribute, interpreted against that attribute's threshold.

Note: It is not a fleet percentile or a universal percentage of remaining health. smartctl reports the score and threshold supplied by the drive; it does not calculate the firmware's conversion.

Related terms:
- [ata-smart](https://hesela.dev/terms/ata-smart/)
- [smart](https://hesela.dev/terms/smart/)
- [smart-raw-value](https://hesela.dev/terms/smart-raw-value/)

Citations:
- [smartctl] smartmontools 7.5 smartctl manual: -A attributes and -v raw-value formats. https://github.com/smartmontools/smartmontools/blob/RELEASE_7_5/smartmontools/smartctl.8.in (accessed 2026-10-11)
- [hesela] Hesela: SMART zeros, missing attributes and failure-day selection. https://hesela.com/analyses/smart-missing-values-not-zero/ (accessed 2026-10-11)

### SMART raw value

URL: https://hesela.dev/terms/smart-raw-value/
Status: shipping

A SMART raw value is the vendor-defined attribute payload reported by an ATA drive, distinct from its normalized score.

Note: A payload can encode multiple fields: smartmontools 7.5 selects a three-word raw16 display for attribute 188 on specified Barracuda 7200.14 models. Do not interpret every large decimal payload as one event count.

Related terms:
- [ata-smart](https://hesela.dev/terms/ata-smart/)
- [smart](https://hesela.dev/terms/smart/)
- [smart-normalized-value](https://hesela.dev/terms/smart-normalized-value/)

Citations:
- [smartctl] smartmontools 7.5 smartctl manual: -A attributes and -v raw-value formats. https://github.com/smartmontools/smartmontools/blob/RELEASE_7_5/smartmontools/smartctl.8.in (accessed 2026-10-11)
- [drivedb] smartmontools 7.5 drive database: Barracuda 7200.14 presets for attribute 188. https://github.com/smartmontools/smartmontools/blob/RELEASE_7_5/smartmontools/drivedb.h (accessed 2026-10-11)
- [hesela] Hesela: SMART zeros, missing attributes and failure-day selection. https://hesela.com/analyses/smart-missing-values-not-zero/ (accessed 2026-10-11)

### S.M.A.R.T.

URL: https://hesela.dev/terms/smart/
Status: shipping

Record updated: 2026-10-16

Self-Monitoring, Analysis and Reporting Technology exposes drive health metrics to the host.

Note: A missing field is not a zero measurement, and a failure-day association is not an advance prediction. Availability and interpretation of attributes vary across models; ATA attributes and the NVMe health log use different structures.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [ssd](https://hesela.dev/terms/ssd/)
- [ata-smart](https://hesela.dev/terms/ata-smart/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [smart-raw-value](https://hesela.dev/terms/smart-raw-value/)
- [smart-normalized-value](https://hesela.dev/terms/smart-normalized-value/)
- [nvme-smart-log](https://hesela.dev/terms/nvme-smart-log/)
- [precision](https://hesela.dev/terms/precision/)
- [recall](https://hesela.dev/terms/recall/)
- [false-positive-rate](https://hesela.dev/terms/false-positive-rate/)
- [temporal-validation](https://hesela.dev/terms/temporal-validation/)
- [smartctl-exit-status](https://hesela.dev/terms/smartctl-exit-status/)
- [power-on-hours](https://hesela.dev/terms/power-on-hours/)
- [drive-firmware-revision](https://hesela.dev/terms/drive-firmware-revision/)

Citations:
- [c1] S.M.A.R.T.. https://en.wikipedia.org/wiki/S.M.A.R.T. (accessed 2026-03-26)
- [smartctl] smartmontools 7.5 smartctl manual: -A attributes and -v raw-value formats. https://github.com/smartmontools/smartmontools/blob/RELEASE_7_5/smartmontools/smartctl.8.in (accessed 2026-10-11)
- [bb] Backblaze: What SMART Stats Indicate Hard Drive Failures? (failure flags and retirement). https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ (accessed 2026-10-11)
- [hesela] Hesela: SMART zeros, missing attributes and failure-day selection. https://hesela.com/analyses/smart-missing-values-not-zero/ (accessed 2026-10-11)

### smartctl exit status

URL: https://hesela.dev/terms/smartctl-exit-status/
Also known as: smartctl return code
Status: shipping

Record updated: 2026-10-15

The smartctl exit status is a process result whose normal ATA interpretation combines independent command, health-threshold and log-history flags in an eight-bit mask.

Note: It is not a binary diagnosis of drive health. The -n option can assign custom return values, including zero when a low-power check is skipped. Decode bits only under a known normal-exit policy, retain warnings and preserve missing health as unknown. A reported passed boolean can come from attribute fallback rather than a successful SMART RETURN STATUS command.

Related terms:
- [ata-smart](https://hesela.dev/terms/ata-smart/)
- [smart](https://hesela.dev/terms/smart/)
- [smart-normalized-value](https://hesela.dev/terms/smart-normalized-value/)
- [smart-raw-value](https://hesela.dev/terms/smart-raw-value/)

Citations:
- [manual] smartmontools 7.5: smartctl exit status and -n policy. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/smartctl.8.in (accessed 2026-10-15)
- [ata] smartmontools 7.5: ATA health-result fallback. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/ataprint.cpp (accessed 2026-10-15)
- [hesela] Hesela: smartctl monitoring and tested collector examples. https://hesela.com/analyses/smartctl-monitoring/#collector-heading (accessed 2026-10-15)

### SMB byte-range lock

URL: https://hesela.dev/terms/smb-byte-range-lock/
Also known as: SMB range lock
Status: shipping

Record updated: 2026-10-14

An SMB byte-range lock coordinates access to a specified region of a file through shared or exclusive locking associated with a file open.

Note: SMB2 ties the lock to its FileId; the client must resolve conflicts between processes on the same client. [lock] Shared locks allow reading and compatible shared locks, but no open may write in the range; exclusive locks exclude other opens from reading, writing or locking it. Unlock must match the original range, not a subrange. [lockflags] This is distinct from cache coordination, although a WRITE-caching lease can also cache byte-range locks. [client] Lock success alone is not a stable-write acknowledgement.

Related terms:
- [smb-protocol](https://hesela.dev/terms/smb-protocol/)
- [smb-lease](https://hesela.dev/terms/smb-lease/)
- [smb-oplock](https://hesela.dev/terms/smb-oplock/)

Citations:
- [lock] Microsoft MS-SMB2 section 2.2.26: SMB2 LOCK Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/6178b960-48b6-4999-b589-669f88e9017d (accessed 2026-10-14)
- [lockflags] Microsoft MS-SMB2 section 2.2.26.1: SMB2_LOCK_ELEMENT Structure. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/73e941c7-9b07-42f6-8b0f-31c1a2cbf0b2 (accessed 2026-10-14)
- [client] Microsoft MS-SMB2 section 3.2.1.5: Per Open File. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/3538a6c5-25a1-41e3-ba35-de0e0633034b (accessed 2026-10-14)

### SMB durable handle

URL: https://hesela.dev/terms/smb-durable-handle/
Also known as: SMB durable open
Status: shipping

Record updated: 2026-10-13

An SMB durable handle allows a client to attempt to recover an existing file open after a network disconnect.

Note: The server retains reconnectable open state subject to a timeout and original-opener authorization. It does not keep the old transport connection alive indefinitely. [open] Re-establishment uses a CREATE request with a reconnect context; the SMB 3.x form also carries the create identifier and, for a persistent open, the persistent flag. [reconnect] Recovering this state is not by itself proof that every application write is on stable storage: the protocol defines write-through separately. [write]

Related terms:
- [smb-protocol](https://hesela.dev/terms/smb-protocol/)
- [smb-persistent-handle](https://hesela.dev/terms/smb-persistent-handle/)
- [smb-lease](https://hesela.dev/terms/smb-lease/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [glossary] Microsoft MS-SMB2 section 1.1: Glossary. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/b1b7cc8a-4d24-4701-bc3f-220b543ceef8 (accessed 2026-10-13)
- [open] Microsoft MS-SMB2 section 3.3.1.10: Per Open. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/eb446d90-a173-4797-9e83-d09490b203f4 (accessed 2026-10-13)
- [reconnect] Microsoft MS-SMB2 section 3.2.4.4: Re-establishing a Durable Open. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/3309c3d1-3daf-4448-9faa-81d2d6aa3315 (accessed 2026-10-13)
- [write] Microsoft MS-SMB2 section 2.2.21: SMB2 WRITE Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8 (accessed 2026-10-13)

### SMB FLUSH

URL: https://hesela.dev/terms/smb-flush/
Also known as: SMB2 FLUSH
Status: shipping

Record updated: 2026-10-14

SMB FLUSH is an SMB2/SMB3 request to propagate cached information for an open file to its backing persistent store, or to wait for a named-pipe reader to consume previously written data.

Note: File and named-pipe opens have different completion contracts. [flushwire] After session, tree, open and access validation, a persistent open returns success without another object-store flush; other opens request that flush and wait for completion. [flush] Separately, SMB 3.x CREATE requires write-through for a continuously available disk share when the server advertises persistent-handle support; this rule does not require a persistent handle to be requested or granted. [createprocessing] A successful response is a protocol result, not an independent hardware power-loss test.

Related terms:
- [smb-protocol](https://hesela.dev/terms/smb-protocol/)
- [smb-persistent-handle](https://hesela.dev/terms/smb-persistent-handle/)

Citations:
- [flushwire] Microsoft MS-SMB2 section 2.2.17: SMB2 FLUSH Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e494678b-b1fc-44a0-b86e-8195acf74ad7 (accessed 2026-10-14)
- [flush] Microsoft MS-SMB2 section 3.3.5.11: Receiving an SMB2 FLUSH Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/026984f6-38af-4408-8200-50557eb0a286 (accessed 2026-10-14)
- [createprocessing] Microsoft MS-SMB2 section 3.3.5.9: Receiving an SMB2 CREATE Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/8c61e928-9242-44ed-96a0-98d1032d0d39 (accessed 2026-10-14)

### SMB lease

URL: https://hesela.dev/terms/smb-lease/
Also known as: SMB caching lease
Status: shipping

Record updated: 2026-10-14

An SMB lease is a server-granted arrangement that permits selected client-side read, write, or handle caching while coordinating access to a shared object.

Note: Lease state can be shared by several opens using the same client lease identity. HANDLE caching permits delayed closes or deferred opens; it is not the durable-handle reconnect capability. Conflicting operations can trigger revocation of caching rights. [leasing] The lease-request LeaseDuration field is reserved, not an application-selectable expiry interval. [leasewire] Client caching rights describe buffering, not stable-write completion. [client] [write] Classic oplock levels have a different request form. [create] A lease can cache byte-range locks under WRITE caching, but a caching lease and a range lock serve different purposes. [client] Gray and Cheriton's historical time-bounded cache protocol is context, not the SMB wire contract or an expiry setting for this reserved field. [gray-cheriton] [leasewire]

Related terms:
- [smb-protocol](https://hesela.dev/terms/smb-protocol/)
- [smb-durable-handle](https://hesela.dev/terms/smb-durable-handle/)
- [smb-persistent-handle](https://hesela.dev/terms/smb-persistent-handle/)
- [smb-oplock](https://hesela.dev/terms/smb-oplock/)
- [smb-byte-range-lock](https://hesela.dev/terms/smb-byte-range-lock/)

Citations:
- [leasing] Microsoft MS-SMB2 section 3.3.1.4: Algorithm for Leasing in an Object Store. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/d8df943d-6ad7-4b30-9f58-96ae90fc6204 (accessed 2026-10-13)
- [leasewire] Microsoft MS-SMB2 section 2.2.13.2.8: Lease request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/250a5100-f8b0-4b32-a202-f592ce4c05e7 (accessed 2026-10-13)
- [client] Microsoft MS-SMB2 section 3.2.1.5: Per Open File. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/3538a6c5-25a1-41e3-ba35-de0e0633034b (accessed 2026-10-13)
- [write] Microsoft MS-SMB2 section 2.2.21: SMB2 WRITE Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8 (accessed 2026-10-13)
- [create] Microsoft MS-SMB2 section 2.2.13: SMB2 CREATE Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e8fb45c1-a03d-44ca-b7ae-47385cfd7997 (accessed 2026-10-14)
- [gray-cheriton] Cary G. Gray and David R. Cheriton: Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency (SOSP 1989), sections 2, 3.2 and 5. https://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15712-s12/www/papers/gray89.pdf (accessed 2026-10-14)

### SMB opportunistic lock

URL: https://hesela.dev/terms/smb-oplock/
Also known as: SMB oplock, SMB opportunistic locking
Status: shipping

Record updated: 2026-10-14

An SMB opportunistic lock is a revocable server-granted caching arrangement that lets a client reduce network operations while coordinating access to a file.

Note: Oplocks coordinate cache use; they are not application byte-range locks. [oplocks] Classic SMB2 oplock levels and leases have distinct request encodings: a lease requires its create context, and its request level is invalid for SMB 2.0.2. [create] Do not assume every break needs an acknowledgement: the level-II-to-none transition does not. [break] These caching arrangements do not by themselves acknowledge durable data storage.

Related terms:
- [smb-protocol](https://hesela.dev/terms/smb-protocol/)
- [smb-lease](https://hesela.dev/terms/smb-lease/)
- [smb-byte-range-lock](https://hesela.dev/terms/smb-byte-range-lock/)

Citations:
- [oplocks] Microsoft Win32: Opportunistic Locks. https://learn.microsoft.com/en-us/windows/win32/fileio/opportunistic-locks (accessed 2026-10-14)
- [create] Microsoft MS-SMB2 section 2.2.13: SMB2 CREATE Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e8fb45c1-a03d-44ca-b7ae-47385cfd7997 (accessed 2026-10-14)
- [break] Microsoft MS-SMB2 section 2.2.24.1: Oplock Break Acknowledgment. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/8b2f9f49-93de-479c-81c2-795b1059deea (accessed 2026-10-14)

### SMB persistent handle

URL: https://hesela.dev/terms/smb-persistent-handle/
Also known as: SMB persistent open
Status: shipping

Record updated: 2026-10-14

An SMB persistent handle extends durable-open recovery to server failover on a supporting continuously available share.

Note: For a non-directory open whose underlying store grants durability, SMB 3.x processing requires the requested persistent flag, a continuously available share, and advertised server support before marking the open persistent. Check the granted response, not merely the request. [persistent] Microsoft's 2012 clustered-file-server design combines persisted handle state with write-through and describes an I/O pause during recovery. This implementation account is not a guarantee against arbitrary storage failure or a latency bound. [failover] The protocol also specifies write-through for supporting SMB 3.x continuously available disk shares before the open is marked persistent. [createprocessing]

Related terms:
- [smb-protocol](https://hesela.dev/terms/smb-protocol/)
- [smb-durable-handle](https://hesela.dev/terms/smb-durable-handle/)
- [smb-lease](https://hesela.dev/terms/smb-lease/)
- [smb-flush](https://hesela.dev/terms/smb-flush/)

Citations:
- [persistent] Microsoft MS-SMB2 section 3.3.5.9.10: Durable Handle Request V2 processing. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/33e6800a-adf5-4221-af27-7e089b9e81d1 (accessed 2026-10-13)
- [failover] Microsoft Windows Server engineering team: Taking Server Application Storage to Windows File Shares (2012). https://www.microsoft.com/en-us/windows-server/blog/2012/03/15/windows-server-8-taking-server-application-storage-to-windows-file-shares/ (accessed 2026-10-13)
- [createprocessing] Microsoft MS-SMB2 section 3.3.5.9: Receiving an SMB2 CREATE Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/8c61e928-9242-44ed-96a0-98d1032d0d39 (accessed 2026-10-14)

### SMB file sharing

URL: https://hesela.dev/terms/smb-protocol/
Also known as: SMB, Server Message Block
Status: shipping

Record updated: 2026-10-14

Server Message Block is a network protocol family used to access shared files and other server resources.

Note: For file shares, distinguish recoverable file-open state, client caching rights, and write completion semantics. A durable handle permits reconnect attempts; a lease controls caching; persistent handles support recovery through a continuously available service. These capabilities depend on the negotiated dialect and server support. [glossary] [persistent] WRITE has distinct write-through and unbuffered flags, with different dialect restrictions; bypassing buffering is not the same request as write-through. [write] Cache coordination through oplocks or leases is distinct from byte-range access locking. [oplocks]

Related terms:
- [nas](https://hesela.dev/terms/nas/)
- [file-storage](https://hesela.dev/terms/file-storage/)
- [smb-durable-handle](https://hesela.dev/terms/smb-durable-handle/)
- [smb-persistent-handle](https://hesela.dev/terms/smb-persistent-handle/)
- [smb-lease](https://hesela.dev/terms/smb-lease/)
- [smb-oplock](https://hesela.dev/terms/smb-oplock/)
- [smb-byte-range-lock](https://hesela.dev/terms/smb-byte-range-lock/)
- [smb-flush](https://hesela.dev/terms/smb-flush/)

Citations:
- [glossary] Microsoft MS-SMB2 section 1.1: Glossary. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/b1b7cc8a-4d24-4701-bc3f-220b543ceef8 (accessed 2026-10-13)
- [persistent] Microsoft MS-SMB2 section 3.3.5.9.10: Durable Handle Request V2 processing. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/33e6800a-adf5-4221-af27-7e089b9e81d1 (accessed 2026-10-13)
- [write] Microsoft MS-SMB2 section 2.2.21: SMB2 WRITE Request. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8 (accessed 2026-10-13)
- [oplocks] Microsoft Win32: Opportunistic Locks. https://learn.microsoft.com/en-us/windows/win32/fileio/opportunistic-locks (accessed 2026-10-14)

### SMOTE

URL: https://hesela.dev/terms/smote/
Also known as: Synthetic Minority Over-sampling Technique, synthetic minority oversampling
Status: shipping

Record updated: 2026-10-13

SMOTE is an oversampling method that creates synthetic minority-class feature vectors by interpolating between a minority example and selected minority-class nearest neighbors.

Note: For numeric features, the original construction uses x_new = x + u * (x_neighbor - x), with u drawn between 0 and 1; it creates feature-space samples, not new observed drive failures. [chawla2002] Fit resampling inside each training fold, leaving validation and test observations unresampled; resampling before splitting can leak information and distort evaluation prevalence. [imblearn-pitfalls] A sampler pipeline does not itself establish an appropriate chronological or device-group split for storage telemetry. [hesela-symptoms]

Limitations:
- Interpolation assumes a meaningful feature representation and neighborhood; a synthetic SMART vector is not evidence that a physical drive followed that trajectory. (sources: [chawla2002])
- Oversampling is a training choice, not a validation protocol or a guarantee of improved deployed precision. (sources: [imblearn-pitfalls], [hesela-symptoms])

Related terms:
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [precision](https://hesela.dev/terms/precision/)
- [recall](https://hesela.dev/terms/recall/)
- [smart](https://hesela.dev/terms/smart/)

Citations:
- [chawla2002] Chawla, Bowyer, Hall and Kegelmeyer. SMOTE: Synthetic Minority Over-sampling Technique. JAIR 16 (2002), 321-357, Section 4.2.. https://www.cs.cmu.edu/afs/cs/project/jair/pub/volume16/chawla02a-html/node6.html (accessed 2026-10-13)
- [imblearn-pitfalls] imbalanced-learn 0.14: Common pitfalls and recommended practices, Section 9.1, resampling leakage.. https://imbalanced-learn.org/0.14/common_pitfalls.html (accessed 2026-10-13)
- [hesela-symptoms] Hesela: SSD symptoms, classification and forward-time evaluation boundaries.. https://hesela.com/analyses/ssd-failures-datacenter-symptoms/#classification-boundary (accessed 2026-10-13)

### SMR persistent cache

URL: https://hesela.dev/terms/smr-persistent-cache/
Also known as: SMR media cache
Status: shipping

Record updated: 2026-10-15

An SMR persistent cache is a nonvolatile staging area that holds updates before they are incorporated into their target shingled regions.

Note: This is distinct from volatile write caching [zoned]. Skylight inferred separate limits for journal allocation, payload space and mapping entries on its tested drives; those inferred values are not specifications for other models [skylight]. The linked analysis provides synthetic resource arithmetic, not a device benchmark [analysis].

Limitations:
- A capacity bound does not predict stall time, firmware cleaning thresholds or the cause of a failed command. (sources: [analysis])

Related terms:
- [device-managed-smr](https://hesela.dev/terms/device-managed-smr/)
- [garbage-collection-smr](https://hesela.dev/terms/garbage-collection-smr/)
- [shingled-band](https://hesela.dev/terms/shingled-band/)

Citations:
- [skylight] Aghayev and Desnoyers: Skylight, FAST 2015, sections 4.5-4.6. https://www.usenix.org/system/files/conference/fast15/fast15-paper-aghayev.pdf (accessed 2026-10-15)
- [zoned] Zoned Storage: Shingled Magnetic Recording Hard Disks. https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-15)
- [analysis] Hesela: SMR stalls, cache limits and the errors SMART can miss. https://hesela.com/analyses/smr-drive-failure-signatures/ (accessed 2026-10-15)

### Shingled magnetic recording (SMR)

URL: https://hesela.dev/terms/smr/
Also known as: shingled recording
Status: shipping

Recorded firstSeen: 2013 (sources: [c1])

An HDD recording method that overlaps tracks like roof shingles to raise areal density at the cost of rewrite behavior.

Note: SMR raises areal density by overlapping successive write tracks like roof shingles: the write head is wider than the final readable track, so each pass trims the previous track to a narrow band the narrower reader can still sense. Tracks are grouped into zones with inter-zone gaps so the wide writer does not bleed across zone boundaries. Reads stay random-access; modifying a sector typically requires rewriting the affected shingled band. Hosts see one of three interface models—drive-managed (firmware hides constraints), host-aware (optional ZAC/ZBC optimization), or host-managed (mandatory sequential writes at the write pointer). INCITS T10 ZBC and T13 ZAC standardize the host-visible zone models; drive-managed has no separate command set because it presents as a conventional disk. SMR fits sequential/archive/object tiers; unmanaged random-write pools often prefer CMR.

Advantages:
- Higher areal density than conventional track layout on the same PMR platform. (sources: [c1])

Limitations:
- Random rewrite patterns may require host or drive-managed band relocation. (sources: [c1])

Related terms:
- [cmr](https://hesela.dev/terms/cmr/)
- [pmr](https://hesela.dev/terms/pmr/)
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [device-managed-smr](https://hesela.dev/terms/device-managed-smr/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)

Citations:
- [c1] Shingled magnetic recording. https://en.wikipedia.org/wiki/Shingled_magnetic_recording (accessed 2026-03-26)
- [n2] Zoned Storage — Shingled Magnetic Recording hard disks. https://zonedstorage.io/docs/introduction/smr (accessed 2026-10-07)
- [n3] Seagate — CMR and SMR hard drive list (workload guidance). https://www.seagate.com/products/cmr-smr-list/ (accessed 2026-10-07)
- [n4] Western Digital — SMR HDD technology white paper. https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/white-paper/white-paper-shingled-magnetic-recording-hdd-technology.pdf (accessed 2026-10-07)

### Snapshot-consistent flash translation layer

URL: https://hesela.dev/terms/snapshot-consistent-ftl/
Also known as: SCFTL
Status: research

Record updated: 2026-10-15

A research FTL that recovers a flush-defined disk snapshot instead of an arbitrary later write prefix.

Note: An interrupted flush may leave the previous snapshot or the complete new snapshot. The design has a write bound and proof assumptions, including error-free flash; this is not a generic SSD feature or a backup snapshot. [scftl]

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [prefix-preserving-crash-consistency](https://hesela.dev/terms/prefix-preserving-crash-consistency/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)

Citations:
- [scftl] Yun-Sheng Chang, Yao Hsiao, Tzu-Chi Lin, Che-Wei Tsao, Chun-Feng Wu, Yuan-Hao Chang, Hsiang-Shang Ko and Yu-Fang Chen. Determinizing Crash Behavior with a Verified Snapshot-Consistent Flash Translation Layer. OSDI 2020, pp. 81-97; sections 2-4 and 6-7.. https://www.usenix.org/system/files/osdi20-chang.pdf (accessed 2026-10-15)
- [hesela] Hesela: SSD mapping caches and recovery contracts. https://hesela.com/analyses/ssd-mapping-cache-hmb/#crash-contracts (accessed 2026-10-15)

### Snapshot isolation

URL: https://hesela.dev/terms/snapshot-isolation/
Also known as: SI
Status: shipping

Record updated: 2026-10-12

Snapshot isolation gives a transaction a stable committed snapshot plus its own writes and prevents concurrent transactions that write the same data from both committing.

Note: It can permit write skew across different rows. PostgreSQL 18 uses this model for Repeatable Read, not its stronger Serializable level. A transaction snapshot is an isolation mechanism, not a storage backup.

Related terms:
- [serializability](https://hesela.dev/terms/serializability/)
- [write-skew](https://hesela.dev/terms/write-skew/)

Citations:
- [berenson-isolation] Hal Berenson et al. A Critique of ANSI SQL Isolation Levels. ACM SIGMOD 1995; MSR-TR-95-51, section 4.2.. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf (accessed 2026-10-12)
- [postgres-isolation] PostgreSQL 18 documentation, section 13.2: Transaction Isolation.. https://www.postgresql.org/docs/18/transaction-iso.html (accessed 2026-10-12)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-12)

### Storage snapshot

URL: https://hesela.dev/terms/snapshot/
Status: shipping

Record updated: 2026-10-15

A storage snapshot is a point-in-time representation of a filesystem or volume, whose implementation may share blocks with its source.

Note: OpenZFS snapshots are read-only views that initially share data with the active dataset. A snapshot held only in the source pool remains dependent on that pool; this is a failure-boundary inference, not a claim that snapshots cannot be used for backup. Recursive OpenZFS snapshot creation coordinates descendant datasets, not arbitrary independent pools. Application buffers and multi-volume consistency require separate consideration. Btrfs snapshots differ: nested subvolume contents are not captured by a parent snapshot. [subvolume]

Advantages:
- Can retain an earlier view without immediately copying every data block. (sources: [zfs-concepts])
- Can provide the source for a full or incremental send stream. (sources: [zfs-send])

Limitations:
- Periodic snapshots can miss short-lived files and intermediate changes between capture points; retaining snapshots longer does not recreate those missing states. (sources: [s4])
- Space usage can grow as the active dataset diverges from retained snapshots. (sources: [zfs-concepts])
- For a running PostgreSQL server, filesystem snapshot backups require the complete cluster and WAL, captured simultaneously across the relevant filesystems. A documented alternative is to stop the server throughout capture. (sources: [postgresql-18])

Related terms:
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [backup](https://hesela.dev/terms/backup/)
- [application-consistent-snapshot](https://hesela.dev/terms/application-consistent-snapshot/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [recovery-point-objective](https://hesela.dev/terms/recovery-point-objective/)
- [recovery-time-objective](https://hesela.dev/terms/recovery-time-objective/)
- [distributed-snapshot](https://hesela.dev/terms/distributed-snapshot/)
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [restore-test](https://hesela.dev/terms/restore-test/)
- [btrfs-read-only-subvolume](https://hesela.dev/terms/btrfs-read-only-subvolume/)
- [filesystem-freeze](https://hesela.dev/terms/filesystem-freeze/)
- [application-quiescing](https://hesela.dev/terms/application-quiescing/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [s4] Strunk et al.: Self-Securing Storage: Protecting Data in Compromised Systems, OSDI 2000, section 6. https://static.usenix.org/events/osdi2000/full_papers/strunk/strunk_html/index.html (accessed 2026-10-15)
- [c1] Storage snapshot. https://en.wikipedia.org/wiki/Snapshot_(computer_storage) (accessed 2026-03-26)
- [zfs-concepts] OpenZFS v2.3: zfsconcepts(7), snapshots and storage pools. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zfsconcepts.7.html (accessed 2026-10-13)
- [zfs-snapshot] OpenZFS v2.3: zfs-snapshot(8), atomic and recursive snapshots. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-snapshot.8.html (accessed 2026-10-13)
- [zfs-send] OpenZFS v2.3: zfs-send(8), full and incremental streams. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zfs-send.8.html (accessed 2026-10-13)
- [postgresql-18] PostgreSQL 18: File System Level Backup, section 25.2. https://www.postgresql.org/docs/18/backup-file.html (accessed 2026-10-13)
- [hesela-recovery] Hesela: Snapshots and backups: which failures can you recover from?. https://hesela.com/analyses/snapshot-backup-recovery-boundaries/ (accessed 2026-10-13)
- [subvolume] Btrfs documentation: subvolume flags and non-recursive snapshots. https://btrfs.readthedocs.io/en/stable/btrfs-subvolume.html (accessed 2026-10-15)

### SNIA

URL: https://hesela.dev/terms/snia-storage/
Status: shipping

Storage Networking Industry Association publishes education and terminology for data infrastructure.

Related terms:
- [san](https://hesela.dev/terms/san/)
- [object-storage](https://hesela.dev/terms/object-storage/)

Citations:
- [c1] SNIA. https://en.wikipedia.org/wiki/Storage_Networking_Industry_Association (accessed 2026-03-26)

### Soft-decision decoding

URL: https://hesela.dev/terms/soft-decision-decoding/
Also known as: soft decoding
Status: shipping

Soft-decision decoding uses reliability information about observed symbols rather than only their hard symbol decisions.

Note: For NAND, comparisons at several reference voltages can supply that information; simply repeating an identical decision does not define soft decoding.

Limitations:
- Additional sensing, transfers and decoding can add latency; the precise recovery sequence is implementation-dependent. (sources: [zhao2012])

Related terms:
- [ldpc](https://hesela.dev/terms/ldpc/)
- [log-likelihood-ratio](https://hesela.dev/terms/log-likelihood-ratio/)
- [read-retry](https://hesela.dev/terms/read-retry/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)

Citations:
- [wang2011] Wang, Courtade, Shankar and Wesel. Soft Information for LDPC Decoding in Flash: Mutual-Information Optimized Quantization. IEEE GLOBECOM 2011, sections II-IV.. https://www.seas.ucla.edu/csl/files/publications/Jiadong_GC2011.pdf (accessed 2026-10-11)
- [zhao2012] Zhao, Dong, Sun, Zheng and Zhang. Reducing latency overhead caused by using LDPC codes in NAND flash memory. EURASIP JASP 2012:203. DOI: 10.1186/1687-6180-2012-203.. https://link.springer.com/article/10.1186/1687-6180-2012-203 (accessed 2026-10-11)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-11)

### Soft updates

URL: https://hesela.dev/terms/soft-updates/
Also known as: softdep
Status: shipping

Record updated: 2026-10-15

Soft updates is a filesystem metadata-consistency mechanism that delays unsafe on-disk changes until their update dependencies are satisfied.

Note: The original BSD implementation uses per-change tracking and temporary buffer rollback rather than a full metadata journal. [soft1999] FreeBSD also offers soft updates journaling as a separate setting. [tunefs143]

Limitations:
- It does not make every recent application write durable, and unused allocations can require later reclamation. (sources: [soft1999])

Related terms:
- [metadata-update-dependency](https://hesela.dev/terms/metadata-update-dependency/)
- [background-fsck](https://hesela.dev/terms/background-fsck/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)

Citations:
- [soft1999] McKusick and Ganger. Soft Updates: A Technique for Eliminating Most Synchronous Writes in the Fast Filesystem. FREENIX 1999, pp. 1-17, sections 2-4.. https://www.usenix.org/legacy/publications/library/proceedings/usenix99/full_papers/mckusick/mckusick.pdf (accessed 2026-10-15)
- [hesela-soft] Hesela: Soft updates and metadata ordering. https://hesela.com/analyses/soft-updates-metadata-ordering/ (accessed 2026-10-15)
- [tunefs143] FreeBSD 14.3-RELEASE tunefs(8): distinct soft updates and soft updates journaling settings.. https://man.freebsd.org/cgi/man.cgi?query=tunefs&sektion=8&manpath=FreeBSD+14.3-RELEASE (accessed 2026-10-15)

### Solid-state media

URL: https://hesela.dev/terms/solid-state-media/
Status: shipping

Storage without macroscopic moving parts, including NAND, 3D XPoint, and NVRAM.

Related terms:
- [ssd](https://hesela.dev/terms/ssd/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)

Citations:
- [c1] Solid-state media. https://en.wikipedia.org/wiki/Solid-state_drive (accessed 2026-03-26)

### Space amplification

URL: https://hesela.dev/terms/space-amplification/
Status: shipping

Record updated: 2026-10-14

Database space amplification quantifies storage overhead relative to logical data size under an explicitly stated total-space or excess-space convention.

Note: For total-space accounting, divide stored database bytes by represented logical data bytes. State whether stored bytes include SST files, WAL, metadata, retained versions and temporary compaction output, and whether the denominator is uncompressed live keys and values. Report steady-state footprint separately from peak space during a merge. [rocks-tuning] Compression and compaction affect different parts of this accounting. [rocks-space] RocksDB Universal's max_size_amplification_percent estimates additional space relative to its oldest run; it is not the total-space ratio or a guaranteed disk-space cap. An insert-only workload can violate the heuristic's overwrite assumption. [rocks-universal] Sarkar et al. instead define excess-space amplification using invalidated-entry bytes over unique-entry bytes; those conventions are not interchangeable. [compaction-design]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [leveled-compaction](https://hesela.dev/terms/leveled-compaction/)
- [tiered-compaction](https://hesela.dev/terms/tiered-compaction/)
- [database-write-amplification](https://hesela.dev/terms/database-write-amplification/)

Citations:
- [rocks-tuning] RocksDB project. Tuning Guide: amplification factors and their accounting boundaries.. https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide (accessed 2026-10-14)
- [rocks-space] RocksDB project. Space Tuning: compression, compaction and space usage.. https://github.com/facebook/rocksdb/wiki/Space-Tuning (accessed 2026-10-14)
- [rocks-universal] RocksDB project. Universal Compaction: run selection, temporary space and amplification heuristic.. https://github.com/facebook/rocksdb/wiki/Universal-Compaction (accessed 2026-10-14)
- [compaction-design] Sarkar, Staratzis, Zhu and Athanassoulis. Constructing and Analyzing the LSM Compaction Design Space. PVLDB 14(11), 2216-2229 (2021), DOI: 10.14778/3476249.3476274; updated arXiv:2202.04522v2 (2022), sections 2-5.. https://arxiv.org/abs/2202.04522v2 (accessed 2026-10-14)
- [hesela] Hesela. Bloom filters: optimize the lookup, not each filter; compaction and measurement boundaries.. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-14)

### Sparse file

URL: https://hesela.dev/terms/sparse-file/
Status: shipping

Record updated: 2026-10-16

A file with unallocated ranges that read as zeros, allowing its logical size to exceed its allocated storage.

Note: On Linux, seeking past EOF alone does not extend a file; writing there leaves a zero-reading gap. SEEK_DATA and SEEK_HOLE are not exact physical allocation maps because filesystems may conservatively report every offset as data. Linux st_blocks counts 512-byte units; st_blksize is a preferred I/O size, not that count's unit. A three-file Hesela observation on ext4 found identical zero readback before and after allocation changes; this is a scoped example, not a universal physical-space measurement.

Advantages:
- Unwritten gaps can be represented without allocating data blocks for the entire logical range. (sources: [lseek], [inode])

Limitations:
- Zeros returned by a read do not prove that the corresponding range is a hole. (sources: [lseek])
- Filesystem allocation is not a direct measurement of underlying thin-pool capacity. (sources: [inode], [lvmthin])

Related terms:
- [file-storage](https://hesela.dev/terms/file-storage/)
- [hole-punching](https://hesela.dev/terms/hole-punching/)
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [file-extent](https://hesela.dev/terms/file-extent/)
- [unwritten-extent](https://hesela.dev/terms/unwritten-extent/)

Citations:
- [lseek] Linux man-pages: lseek(2), holes and SEEK_DATA/SEEK_HOLE. https://www.man7.org/linux/man-pages/man2/lseek.2.html (accessed 2026-10-12)
- [inode] Linux man-pages: inode(7), file size and allocated blocks. https://man7.org/linux/man-pages/man7/inode.7.html (accessed 2026-10-12)
- [lvmthin] LVM2: lvmthin(7), physical allocation, discards and pool exhaustion. https://man7.org/linux/man-pages/man7/lvmthin.7.html (accessed 2026-10-12)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)
- [hesela-observation] Hesela: three-run ext4 allocation observation, source hashes and environment. https://hesela.dev/research/allocation-observation.json (accessed 2026-10-16)

### SQLITE_BUSY_SNAPSHOT

URL: https://hesela.dev/terms/sqlite-busy-snapshot/
Also known as: SQLite stale snapshot upgrade
Status: shipping

Record updated: 2026-10-16

SQLITE_BUSY_SNAPSHOT is SQLite's extended result code for a WAL read transaction that cannot become a writer because its snapshot is obsolete.

Note: Code 517 belongs to the SQLITE_BUSY (5) primary family; retain the extended result when diagnosing an upgrade failure. [sqlite-result-codes] In Hesela's constructed schedules, repeating the UPDATE failed even after the other writer had committed, including when it changed a different row; ending the transaction and rereading succeeded. [hesela-upgrade] BEGIN IMMEDIATE moves writer acquisition before the reads but may itself fail to acquire the writer position. [sqlite-transactions] A new transaction does not invalidate values cached by the application: Hesela's separate retry experiment committed an obsolete bound value successfully after rollback, overwriting the other increment. Rereading and recomputing preserved both increments; a revision predicate rejected the stale write with zero affected rows. [hesela-retry-values]

Limitations:
- A configured busy timeout is not a mechanism for refreshing the retained snapshot. (sources: [sqlite-isolation])
- The six-case observation is not a failure-rate or latency study. (sources: [hesela-upgrade])
- Successful commit and integrity_check do not prove that application intent survived a retry; the four-strategy experiment is a constructed counterexample, not an observed production rate. (sources: [hesela-retry-values])

Related terms:
- [sqlite-wal-end-mark](https://hesela.dev/terms/sqlite-wal-end-mark/)
- [checkpoint-starvation](https://hesela.dev/terms/checkpoint-starvation/)
- [serializability](https://hesela.dev/terms/serializability/)

Citations:
- [sqlite-result-codes] SQLite: result and error codes, SQLITE_BUSY_SNAPSHOT (517) and SQLITE_BUSY (5). https://www.sqlite.org/rescode.html#busy_snapshot (accessed 2026-10-16)
- [sqlite-transactions] SQLite: DEFERRED, IMMEDIATE and EXCLUSIVE transactions. https://www.sqlite.org/lang_transaction.html (accessed 2026-10-16)
- [sqlite-isolation] SQLite: isolation and stale read-to-write upgrades. https://www.sqlite.org/isolation.html (accessed 2026-10-16)
- [hesela-upgrade] Hesela: measured six-case SQLite snapshot-upgrade experiment. https://hesela.dev/research/sqlite-snapshot-upgrade.json (accessed 2026-10-16)
- [hesela-readers] SQLite WAL checkpoint starvation: success is not completion. https://hesela.com/analyses/sqlite-wal-checkpoint-starvation/#snapshot-upgrade (accessed 2026-10-16)
- [hesela-retry-values] Hesela: measured retry-value boundaries, cached binding versus recomputation. https://hesela.dev/research/sqlite-retry-values.json (accessed 2026-10-16)

### SQLite super-journal

URL: https://hesela.dev/terms/sqlite-super-journal/
Also known as: Super-journal, SQLite super journal
Status: shipping

Record updated: 2026-10-14

A SQLite super-journal is a coordination file that links recovery outcomes for a qualifying rollback-mode transaction modifying multiple attached databases on one connection.

Note: The super-journal lists participating rollback-journal paths, not database page contents. After journal and database synchronization, deleting it marks the multi-file commit; remaining individual journals can then be cleaned up. [sqlite-atomiccommit] Creation requires at least two modified databases with synchronous not OFF and journal_mode outside OFF, MEMORY and WAL. [sqlite-tempfiles] The documented cross-file guarantee also excludes an in-memory main database. [sqlite-attach] This mechanism belongs to SQLite's attached-database transaction, not an arbitrary set of database servers. See the commit-scope comparison. [hesela-wal]

Advantages:
- Provides a shared recovery decision for participating databases under the documented rollback-mode conditions. (sources: [sqlite-atomiccommit])

Limitations:
- WAL transactions remain atomic per database, not across the attached database set. (sources: [sqlite-wal])
- Missing volumes or changed mount paths after a crash can break the links between journals and compromise cross-file atomicity. (sources: [sqlite-locking])

Related terms:
- [rollback-journal](https://hesela.dev/terms/rollback-journal/)
- [hot-journal](https://hesela.dev/terms/hot-journal/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [fsync](https://hesela.dev/terms/fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)

Citations:
- [sqlite-atomiccommit] SQLite: Atomic Commit In SQLite. https://sqlite.org/atomiccommit.html (accessed 2026-10-14)
- [sqlite-tempfiles] SQLite: Temporary Files Used By SQLite. https://sqlite.org/tempfiles.html (accessed 2026-10-14)
- [sqlite-attach] SQLite: ATTACH DATABASE. https://sqlite.org/lang_attach.html (accessed 2026-10-14)
- [sqlite-wal] SQLite: Write-Ahead Logging. https://sqlite.org/wal.html (accessed 2026-10-14)
- [sqlite-locking] SQLite: File Locking And Concurrency In SQLite Version 3. https://sqlite.org/lockingv3.html (accessed 2026-10-14)
- [hesela-wal] Hesela: WAL, checkpoints and torn pages, SQLite commit scope. https://hesela.com/analyses/wal-checkpoints-torn-pages/#sqlite-commit-scope (accessed 2026-10-14)

### SQLite WAL end mark

URL: https://hesela.dev/terms/sqlite-wal-end-mark/
Also known as: WAL reader end mark
Status: shipping

Record updated: 2026-10-16

A SQLite WAL end mark is the committed WAL boundary that determines which page versions a read transaction may observe.

Note: The transaction's snapshot does not advance when another connection commits. Ending the transaction and starting another permits a newer view. [sqlite-isolation] Distinguish this logical snapshot boundary from the shared WAL-index read-mark slots and locks used by checkpoint coordination. They are related mechanisms, not interchangeable counters. [sqlite-wal-format] Our complete row oracle checks the retained generation and the newer state after release. [hesela-observation]

Limitations:
- An open connection does not itself identify the lifetime or contents of an active read snapshot. (sources: [sqlite-isolation])

Related terms:
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [checkpoint-starvation](https://hesela.dev/terms/checkpoint-starvation/)
- [sqlite-busy-snapshot](https://hesela.dev/terms/sqlite-busy-snapshot/)

Citations:
- [sqlite-isolation] SQLite: Isolation, WAL snapshots and transaction lifetime. https://www.sqlite.org/isolation.html (accessed 2026-10-14)
- [sqlite-wal-format] SQLite: WAL-mode File Format, WAL-index header and read marks. https://www.sqlite.org/walformat.html (accessed 2026-10-14)
- [hesela-readers] SQLite WAL checkpoint starvation: success is not completion. https://hesela.com/analyses/sqlite-wal-checkpoint-starvation/ (accessed 2026-10-14)
- [hesela-observation] Hesela: measured SQLite WAL-reader observations and limits. https://hesela.dev/research/sqlite-wal-readers.json (accessed 2026-10-14)

### SSD preconditioning

URL: https://hesela.dev/terms/ssd-preconditioning/
Also known as: SSD pre-conditioning
Status: shipping

Record updated: 2026-10-14

Preparatory writing used to establish a specified SSD state before performance measurement.

Note: Device history affects garbage collection, cache contents and physical placement. MQSim models these states rather than treating occupied capacity alone as sufficient preparation. Document what was written, where and how the subsequent measurement window was accepted.

Limitations:
- Preparation writes can destroy data and consume endurance
- A synthetic state model is not evidence that a physical drive was conditioned

Related terms:
- [filesystem-aging](https://hesela.dev/terms/filesystem-aging/)
- [ssd-steady-state](https://hesela.dev/terms/ssd-steady-state/)
- [active-lba-range](https://hesela.dev/terms/active-lba-range/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)

Citations:
- [mqsim] Arash Tavakkol, Juan Gomez-Luna, Mohammad Sadrosadati, Saugata Ghose and Onur Mutlu. MQSim: A Framework for Enabling Realistic Studies of Modern Multi-Queue SSD Devices. FAST 2018, pp. 49-66; sections 3.2, 4.4, 5 and Appendix A.. https://www.usenix.org/system/files/conference/fast18/fast18-tavakkol.pdf (accessed 2026-10-11)
- [snia] SNIA. Solid State Storage Performance Test Specification, version 2.0.2 (1 October 2020), definitions 2.1.1, 2.1.3, 2.1.6, 2.1.13, 2.1.18 and 2.1.24.. https://www.snia.org/sites/default/files/2025-02/SNIA-SSS-PTS-2.0.2.pdf (accessed 2026-10-11)
- [hesela-windows] Hesela: SSD steady state is not a timer; original numerical examples and limits. https://hesela.com/analyses/ssd-steady-state-is-not-a-timer/ (accessed 2026-10-11)

### SSD steady state

URL: https://hesela.dev/terms/ssd-steady-state/
Also known as: steady-state SSD performance
Status: shipping

Record updated: 2026-10-14

A workload-specific SSD performance condition in which a named metric satisfies stated stability criteria over a defined measurement window.

Note: A passing window is conditional on workload and preparation, not a permanent property of the drive. Hesela's counterexamples separate low drift from low variation and show why a stable early plateau cannot guarantee later performance.

Limitations:
- Does not establish durability, minimum speed or tail latency
- A fixed warm-up time alone is not a convergence test

Related terms:
- [filesystem-aging](https://hesela.dev/terms/filesystem-aging/)
- [ssd-preconditioning](https://hesela.dev/terms/ssd-preconditioning/)
- [active-lba-range](https://hesela.dev/terms/active-lba-range/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [slc-cache](https://hesela.dev/terms/slc-cache/)

Citations:
- [snia] SNIA. Solid State Storage Performance Test Specification, version 2.0.2 (1 October 2020), definitions 2.1.1, 2.1.3, 2.1.6, 2.1.13, 2.1.18 and 2.1.24.. https://www.snia.org/sites/default/files/2025-02/SNIA-SSS-PTS-2.0.2.pdf (accessed 2026-10-11)
- [mqsim] Arash Tavakkol, Juan Gomez-Luna, Mohammad Sadrosadati, Saugata Ghose and Onur Mutlu. MQSim: A Framework for Enabling Realistic Studies of Modern Multi-Queue SSD Devices. FAST 2018, pp. 49-66; sections 3.2, 4.4, 5 and Appendix A.. https://www.usenix.org/system/files/conference/fast18/fast18-tavakkol.pdf (accessed 2026-10-11)
- [hesela-windows] Hesela: SSD steady state is not a timer; original numerical examples and limits. https://hesela.com/analyses/ssd-steady-state-is-not-a-timer/ (accessed 2026-10-11)

### Solid-state drive (SSD)

URL: https://hesela.dev/terms/ssd/
Also known as: solid-state storage, SSD
Status: shipping

Record updated: 2026-10-15

A solid-state drive is a storage device that retains data in nonvolatile semiconductor memory without moving recording media.

Note: Most SSDs use NAND, but the device category does not specify media, protocol or packaging [snia-overview]. In conventional NAND SSDs, an FTL maps logical addresses to physical locations; out-of-place updates and reclamation are controller work [agrawal]. SSD, NVMe and M.2 are not synonyms [nvme-form]. The former firstSeen=2007 value is unsupported as a category-wide origin: Samsung lists its own 2006 SSD, not an industry first [samsung-history]. Historical RAM-based products and flash-based products need separate milestones.

Advantages:
- No mechanical seek or rotational delay is required to access the recording medium. (sources: [snia-overview])

Limitations:
- NAND endurance and workload performance require model-specific conditions; a generic SSD label is not a lifetime guarantee. (sources: [snia-endurance])
- Nonvolatile media does not by itself protect volatile cached writes or mapping metadata during power loss. (sources: [kingston-plp])

Related terms:
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [nvme](https://hesela.dev/terms/nvme/)
- [sata](https://hesela.dev/terms/sata/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [ftl](https://hesela.dev/terms/ftl/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [sas](https://hesela.dev/terms/sas/)
- [m2](https://hesela.dev/terms/m2/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)
- [ssd-steady-state](https://hesela.dev/terms/ssd-steady-state/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [wear-leveling](https://hesela.dev/terms/wear-leveling/)

Citations:
- [snia-overview] SNIA: What is an SSD? Media, interfaces and form factors.. https://www.snia.org/education/what-is-ssd (accessed 2026-10-15)
- [agrawal] Agrawal et al. Design Tradeoffs for SSD Performance. USENIX ATC 2008, sections 2.1 and 3.1-3.4.. https://www.usenix.org/legacy/events/usenix08/tech/full_papers/agrawal/agrawal.pdf (accessed 2026-10-15)
- [nvme-form] NVM Express: NVMe Form Factors, Part III: The Importance of Form. M.2 interface distinction.. https://nvmexpress.org/nvm-express-blog-series-nvme-form-factors-part-iii-the-importance-of-form/ (accessed 2026-10-15)
- [snia-endurance] SNIA: Endurance of NVMe, SAS, and SATA SSDs. Endurance, workload and deallocation.. https://www.snia.org/sites/default/files/SSSI/NVMe_SAS_SATA_Endurance_White_Paper.pdf (accessed 2026-10-15)
- [kingston-plp] Kingston: SSD Power Loss Protection. Hardware and firmware protection scope.. https://www.kingston.com/unitedkingdom/en/blog/servers-and-data-centers/ssd-power-loss-protection (accessed 2026-10-15)
- [samsung-history] Samsung: Industry's First 4-bit Consumer SSD. Vendor production-history table lists its 2006 SLC SSD; not a first-ever SSD claim.. https://semiconductor.samsung.com/news-events/news/industrys-first-4-bit-consumer-ssd/ (accessed 2026-10-15)
- [hesela-ssd] Hesela: Solid-State Drive, architecture and qualification boundaries. https://hesela.com/tech/ssd/ (accessed 2026-10-15)

### SSHD (hybrid drive)

URL: https://hesela.dev/terms/sshd/
Status: eol

A hard drive with a small NAND cache to accelerate frequently read data while retaining rotating media.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [ssd](https://hesela.dev/terms/ssd/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)

Citations:
- [c1] SSHD (hybrid drive). https://en.wikipedia.org/wiki/Hybrid_drive (accessed 2026-03-26)

### Sorted string table

URL: https://hesela.dev/terms/sstable/
Also known as: SSTable, SST file
Status: shipping

Record updated: 2026-10-14

An immutable table of sorted key-value entries used as a persistent component in storage engines such as LevelDB and RocksDB.

Note: An SSTable is a file-level component, not an entire LSM-tree. In LevelDB, compaction merges tables and can discard overwritten values or obsolete deletion markers when safe.

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [lsm-tombstone](https://hesela.dev/terms/lsm-tombstone/)
- [ribbon-filter](https://hesela.dev/terms/ribbon-filter/)
- [partitioned-filter](https://hesela.dev/terms/partitioned-filter/)
- [compaction](https://hesela.dev/terms/compaction/)
- [memtable](https://hesela.dev/terms/memtable/)
- [rocksdb-manifest](https://hesela.dev/terms/rocksdb-manifest/)

Citations:
- [leveldb] LevelDB project. Implementation: log files, sorted tables and compaction. Documentation reviewed 12 October 2026.. https://github.com/google/leveldb/blob/main/doc/impl.md (accessed 2026-10-12)
- [rocks-levels] RocksDB project. Leveled Compaction: sorted levels, SST files and overlapping L0. Documentation reviewed 12 October 2026.. https://github.com/facebook/rocksdb/wiki/Leveled-Compaction (accessed 2026-10-12)
- [hesela] Hesela: Bloom filters and the cost of an absent LSM lookup. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-12)

### ST-412

URL: https://hesela.dev/terms/st-412/
Status: eol

Recorded firstSeen: 1981-11 (sources: [c1])

Seagate's follow-on full-height 5.25-inch HDD interface companion to the ST-506 ecosystem.

Note: The ST-506 was Seagate's 1980 5.25-inch drive and the first of its size; the ST-412 followed in late 1981 as a 10 MB drive with 306 cylinders and buffered seek, and the two names later came to denote one disk interface, ST-506/ST-412, which numerous manufacturers adopted as a de facto standard well into the 1990s. The interface descends from the Shugart SA1000 interface, itself based on the floppy disk interface: a 34-pin control cable that can serve four drives, plus a 20-pin data cable per drive carrying separate Read and Write differential pairs, and a four-pin power connector. The controller card, not the drive, does the work: it translates host requests into head-positioning commands, sends STEP pulses, and handles MFM encoding, which gives one data bit per transition at 5 Mbit/s. The ST-412HP extension used RLL encoding, averaging 1.5 data bits per transition for 7.5 Mbit/s and about 50% more capacity. Limits of the interface are 5 million transitions per second on the data lines, 16 heads, 4 drive units and a 20-foot (6.1 m) cable. Buffered seek let the controller send STEP pulses as fast as the drive could accept them, cutting average seek from about 170 ms on the ST-506 to about 85 ms; by the late 1980s drives with this interface reached 15 to 30 ms. The interface was picked for the original IBM XT, and was gradually replaced by SCSI and ATA (IDE), which moved the controller into the drive. Wikipedia lists a few early SCSI and IDE drives that were simply an ST-412-interface drive with a controller board attached.

Advantages:
- Separate controller and drive meant a failed controller could be replaced without losing the data, and the raw analog read signals were available for specialist data recovery
- Derived from the floppy interface, so controller design was relatively easy and many vendors adopted it
- Widely supported: it served as the de facto PC hard disk interface until IDE/ATA spread in the early 1990s

Limitations:
- At most 4 drive units per control cable and 16 heads, with a cable limited to 20 feet (6.1 m)
- Data rate capped at 5 Mbit/s with MFM (7.5 Mbit/s with the ST-412HP RLL variant), since the interface allows at most 5 million transitions per second
- The unshielded cable could be susceptible to noise, and most controllers supported only two drives
- Head selection, stepping and encoding sat on the controller, so the host side was complex; this drove the move to SCSI and IDE, where the controller sits in the drive

Related terms:
- [st-506](https://hesela.dev/terms/st-506/)
- [hdd](https://hesela.dev/terms/hdd/)
- [ide](https://hesela.dev/terms/ide/)
- [pata](https://hesela.dev/terms/pata/)
- [scsi](https://hesela.dev/terms/scsi/)
- [esdi](https://hesela.dev/terms/esdi/)
- [floppy-disk](https://hesela.dev/terms/floppy-disk/)
- [seek-time](https://hesela.dev/terms/seek-time/)

Citations:
- [c1] ST-506/ST-412 (Wikipedia; the ST-412 page redirects here). https://en.wikipedia.org/wiki/ST-412 (accessed 2026-10-10)

### ST-506 interface

URL: https://hesela.dev/terms/st-506/
Also known as: ST506
Status: eol

Recorded firstSeen: 1980 (sources: [c1])

An early HDD interface where the drive exposed raw heads and the controller lived on a host adapter card.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [scsi](https://hesela.dev/terms/scsi/)
- [esdi](https://hesela.dev/terms/esdi/)
- [st-412](https://hesela.dev/terms/st-412/)

Citations:
- [c1] ST-506. https://en.wikipedia.org/wiki/ST-506 (accessed 2026-03-26)

### Staggered scrubbing

URL: https://hesela.dev/terms/staggered-scrubbing/
Status: research

Staggered scrubbing is a scan-order strategy that visits segments across multiple disk regions before returning to subsequent segments in each region.

Note: It aims to locate clustered damage earlier and then inspect the affected region; it is distinct from merely increasing scan frequency.

Limitations:
- Historical HDD scan-order results are not guarantees for SSDs or array data-loss rates. (sources: [oprea])

Related terms:
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [latent-sector-error](https://hesela.dev/terms/latent-sector-error/)

Citations:
- [oprea] Oprea and Juels. A Clean-Slate Look at Disk Scrubbing. FAST 2010, sections 2, 4.2 and 6.. https://www.usenix.org/legacy/events/fast10/tech/full_papers/oprea.pdf (accessed 2026-10-11)
- [schroeder] Schroeder, Damouras and Gill. Understanding latent sector errors and how to protect against them. FAST 2010, sections 2 and 5.. https://www.usenix.org/legacy/events/fast10/tech/full_papers/schroeder.pdf (accessed 2026-10-11)
- [hesela-scrub] Hesela: Scrubbing, detection time and repair boundaries. https://hesela.com/analyses/scrubbing-detection-not-durability/ (accessed 2026-10-11)

### STATX_WRITE_ATOMIC

URL: https://hesela.dev/terms/statx-write-atomic/
Status: shipping

Record updated: 2026-10-12

STATX_WRITE_ATOMIC is a Linux statx request for a file's reported atomic-write size limits and maximum vector count.

Note: Check returned masks before interpreting fields; a requested capability is not necessarily supported. Minimum and maximum sizes are in bytes. Direct-I/O buffer alignment is a separate query, and drive-level limits do not establish the capability of a file. The nonzero stx_atomic_write_unit_max_opt is an optimized size limit, not the validity ceiling; zero uses stx_atomic_write_unit_max.

Related terms:
- [rwf-atomic](https://hesela.dev/terms/rwf-atomic/)
- [torn-write](https://hesela.dev/terms/torn-write/)
- [direct-io](https://hesela.dev/terms/direct-io/)

Citations:
- [statx] Linux man-pages, statx(2): atomic-write fields and returned masks. https://man7.org/linux/man-pages/man2/statx.2.html (accessed 2026-10-12)
- [open] Linux man-pages, open(2): O_DIRECT, O_DSYNC and O_SYNC. https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-12)
- [hesela-atomic] Linux atomic writes: untorn does not mean durable. https://hesela.com/analyses/linux-atomic-writes-durability/ (accessed 2026-10-12)

### Storage-class memory (SCM)

URL: https://hesela.dev/terms/storage-class-memory/
Status: limited

Media with latency between DRAM and NAND, often byte-addressable, used for persistence tiers.

Related terms:
- [3d-xpoint](https://hesela.dev/terms/3d-xpoint/)
- [persistent-memory](https://hesela.dev/terms/persistent-memory/)
- [nvdimm-n](https://hesela.dev/terms/nvdimm-n/)
- [byte-addressable-storage](https://hesela.dev/terms/byte-addressable-storage/)

Citations:
- [c1] Storage-class memory (SCM). https://en.wikipedia.org/wiki/Storage-class_memory (accessed 2026-03-26)

### Storage virtualization

URL: https://hesela.dev/terms/storage-virtualization/
Status: shipping

A layer abstracts multiple backends into pooled logical volumes presented to hosts.

Related terms:
- [san](https://hesela.dev/terms/san/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Storage virtualization. https://en.wikipedia.org/wiki/Storage_virtualization (accessed 2026-03-26)

### Striping (storage)

URL: https://hesela.dev/terms/striping/
Status: shipping

Splitting sequential data across drives to aggregate bandwidth.

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [parity-raid](https://hesela.dev/terms/parity-raid/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Striping (storage). https://en.wikipedia.org/wiki/RAID (accessed 2026-03-26)

### Submission latency (fio)

URL: https://hesela.dev/terms/submission-latency/
Also known as: slat
Status: shipping

Record updated: 2026-10-13

Submission latency in fio is the elapsed time from initialization of an I/O unit to an engine-dependent submission boundary.

Note: For synchronous engines, slat ends just before the engine queue function is called; asynchronous timing differs [fio]. Preserve the engine and fio version. It is not an application-arrival clock, and its sample count need not be inferred from a different latency field.

Related terms:
- [completion-latency](https://hesela.dev/terms/completion-latency/)
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [iops](https://hesela.dev/terms/iops/)

Citations:
- [fio] fio documentation: interpreting slat, clat and lat; engine-dependent timing boundaries.. https://fio.readthedocs.io/en/master/fio_doc.html (accessed 2026-10-13)
- [hesela-populations] Hesela: fio summaries, latency sample populations and runtime denominators; synthetic examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#fio-populations (accessed 2026-10-13)

### Succinct range filter

URL: https://hesela.dev/terms/succinct-range-filter/
Also known as: SuRF
Status: research

Record updated: 2026-10-13

An approximate point-and-range membership structure based on a truncated order-preserving Fast Succinct Trie.

Note: The SIGMOD 2018 SuRF design is static. Real-key suffix bits assist range filtering, whereas hash suffix bits refine point tests without encoding order. A positive range answer still needs verification against stored keys. [surf]

Related terms:
- [bloom-filter](https://hesela.dev/terms/bloom-filter/)
- [prefix-bloom-filter](https://hesela.dev/terms/prefix-bloom-filter/)

Citations:
- [surf] Huanchen Zhang et al. SuRF: Practical Range Query Filtering with Fast Succinct Tries. SIGMOD 2018, 323-336, sections 3, 5 and 6. DOI: 10.1145/3183713.3196931.. https://www.cs.cmu.edu/~huanche1/publications/surf_paper.pdf (accessed 2026-10-13)
- [hesela] Hesela: filter predicates, prefix correctness and SuRF boundaries. https://hesela.com/analyses/bloom-filters-lsm-read-cost/#predicates (accessed 2026-10-13)

### Superparamagnetic limit

URL: https://hesela.dev/terms/superparamagnetic-limit/
Status: unknown

The grain-size floor where longitudinal bits become thermally unstable, motivating PMR and energy-assisted recording.

Related terms:
- [longitudinal-recording](https://hesela.dev/terms/longitudinal-recording/)
- [pmr](https://hesela.dev/terms/pmr/)
- [hamr](https://hesela.dev/terms/hamr/)

Citations:
- [c1] Superparamagnetic limit. https://en.wikipedia.org/wiki/Superparamagnetism (accessed 2026-03-26)

### Survival function

URL: https://hesela.dev/terms/survival-function/
Also known as: Reliability function, Survivor function
Status: shipping

Record updated: 2026-10-13

The survival function S(t) = P(T > t) is the probability that a time T to a defined event exceeds t, measured from a specified time origin.

Note: Specify the drive population, failure event, time origin and units. S(t) is dimensionless and equals 1 - F(t); it is not an annualized event rate. [nist-survival] For a drive surviving to age a, survival for another u units of time is S(a + u) / S(a), for u >= 0 and S(a) > 0, using the same population and time origin. This follows from conditional probability, not a constant-hazard assumption.

Related terms:
- [hazard-rate](https://hesela.dev/terms/hazard-rate/)
- [right-censoring](https://hesela.dev/terms/right-censoring/)
- [left-truncation](https://hesela.dev/terms/left-truncation/)
- [kaplan-meier-estimator](https://hesela.dev/terms/kaplan-meier-estimator/)
- [afr](https://hesela.dev/terms/afr/)

Citations:
- [nist-survival] NIST e-Handbook 8.1.2.2: Reliability or survival function. https://www.itl.nist.gov/div898/handbook/apr/section1/apr122.htm (accessed 2026-10-13)

### Symbol erasure

URL: https://hesela.dev/terms/symbol-erasure/
Also known as: Known erasure
Status: shipping

Record updated: 2026-10-15

A symbol erasure is a codeword position whose value is unavailable or deliberately discarded and whose location is known to the decoder.

Note: An erased value is not a zero, and an incorrect value at an unidentified position remains an error. The distinction is part of the decoder input contract, not a diagnosis of why storage failed. [forney] Hesela's six-symbol example shows that identifying the actual damaged coordinate enables recovery, whereas discarding a healthy coordinate can leave a unique wrong result. [hesela-errors]

Limitations:
- A checksum mismatch only helps locate an erasure when the check and the fragment identity are trustworthy.
- Erasing an entire shard affects its mapped symbol positions; counts must be interpreted per codeword.

Related terms:
- [error-and-erasure-decoding](https://hesela.dev/terms/error-and-erasure-decoding/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)
- [codeword](https://hesela.dev/terms/codeword/)
- [checksum](https://hesela.dev/terms/checksum/)

Citations:
- [forney] G. David Forney. Principles of Digital Communication II, MIT 6.451 (2005), section 6.5.3: bounded-distance erasure-and-error correction.. https://ocw.mit.edu/courses/6-451-principles-of-digital-communication-ii-spring-2005/bb895c1dee9ce0b39d6846e0aa984981_MIT6_451S05_FullLecNotes.pdf (accessed 2026-10-15)
- [hesela-errors] Hesela: exact GF(7) errors-and-erasures examples, including an ambiguous observation and false-identification negative control.. https://hesela.com/analyses/reed-solomon-matrix-recovery-guarantees/#errors-erasures (accessed 2026-10-15)

### sync_file_range

URL: https://hesela.dev/terms/sync-file-range/
Also known as: sync_file_range()
Status: shipping

Record updated: 2026-10-13

sync_file_range is a Linux-specific operation that initiates or waits for page-cache writeback over a file range without synchronizing file metadata or flushing volatile device write caches.

Note: Combining WAIT_BEFORE, WRITE and WAIT_AFTER does not remove those omissions. Preallocated space can still require allocation metadata updates, and copy-on-write overwrites cannot assume in-place blocks. Use it to control writeback, not as a general replacement for fdatasync or fsync.

Advantages:
- Allows applications to control writeback over selected file ranges.

Limitations:
- Linux-specific; not a portable persistence interface.
- WRITE alone may block under request-queue pressure.
- A successful return does not establish crash-safe availability of the data.

Related terms:
- [fsync](https://hesela.dev/terms/fsync/)
- [fdatasync](https://hesela.dev/terms/fdatasync/)
- [msync](https://hesela.dev/terms/msync/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)

Citations:
- [sync-range-api] Linux man-pages 6.19: sync_file_range(2), Warning and flag combinations. https://man7.org/linux/man-pages/man2/sync_file_range.2.html (accessed 2026-10-13)
- [hesela-fsync] Hesela: File and mapped-range synchronization boundaries. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-13)

### syncfs

URL: https://hesela.dev/terms/syncfs/
Also known as: syncfs()
Status: shipping

Record updated: 2026-10-16

syncfs is a Linux system call that synchronizes pending file data and metadata for the filesystem selected by an open file descriptor.

Note: Linux waits for I/O completion; the descriptor selects a filesystem, not just one file. Unlike the void sync() interface, syncfs returns an error indication. Since Linux 5.8 it also reports filesystem writeback failures, which can concern another file or filesystem metadata. [sync-api] In the pinned Linux v6.12 implementation, syncfs checks the superblock error sequence against the open file description's f_sb_err cursor, separate from its file-level f_wb_err cursor. The cursor check still runs when sync_filesystem() fails; that immediate failure takes precedence in the returned result. The sequence is not a queue of errors to drain by retrying. This is a source-code observation, not a portable API rule. [sync-source] Advancing an error cursor records observation, not repair; a later success alone cannot establish that previously lost data was reconstructed. [errseq-doc]

Advantages:
- Provides an error-reporting synchronization operation scoped to one filesystem.

Limitations:
- Does not enumerate failed files or identify damaged byte ranges.
- Does not turn a multi-file update into an atomic application transaction.
- Linux-specific; do not assume its error-reporting behavior on old kernels.

Related terms:
- [fsync](https://hesela.dev/terms/fsync/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [errseq-t](https://hesela.dev/terms/errseq-t/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)

Citations:
- [sync-api] Linux man-pages 6.19: sync(2), filesystem scope and Linux 5.8 error reporting. https://man7.org/linux/man-pages/man2/sync.2.html (accessed 2026-10-15)
- [sync-source] Linux v6.12: syncfs and sync_filesystem in fs/sync.c. https://github.com/torvalds/linux/blob/v6.12/fs/sync.c (accessed 2026-10-16)
- [errseq-doc] Linux kernel: The errseq_t datatype. https://docs.kernel.org/core-api/errseq.html (accessed 2026-10-15)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-15)

### Synchronous replication

URL: https://hesela.dev/terms/synchronous-replication/
Status: shipping

Record updated: 2026-10-12

Synchronous replication makes successful completion depend on acknowledgement that a specified set of replicas has reached the processing stage required by the replication contract.

Note: Name the acknowledgement boundary instead of assuming that synchronous means query-visible. PostgreSQL 18 distinguishes a standby filesystem write, durable WAL flush and transaction replay; configured synchronous standbys are required for remote waiting. This database usage is broader than a storage contract requiring completed remote disk writes. Required replicas add latency and their unavailability can block commits.

Related terms:
- [asynchronous-replication](https://hesela.dev/terms/asynchronous-replication/)
- [replication-lag](https://hesela.dev/terms/replication-lag/)
- [mirroring](https://hesela.dev/terms/mirroring/)
- [io-fencing](https://hesela.dev/terms/io-fencing/)
- [chain-replication](https://hesela.dev/terms/chain-replication/)
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)

Citations:
- [pg-commit] PostgreSQL 18: WAL settings, synchronous_commit. https://www.postgresql.org/docs/18/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT (accessed 2026-10-12)
- [pg-standbys] PostgreSQL 18: synchronous_standby_names. https://www.postgresql.org/docs/18/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES (accessed 2026-10-12)
- [pg-streaming] PostgreSQL 18: warm standby and synchronous replication. https://www.postgresql.org/docs/18/warm-standby.html#SYNCHRONOUS-REPLICATION (accessed 2026-10-12)
- [hesela-replication] Replication acknowledgements: received, durable, applied. https://hesela.com/analyses/replication-acknowledgements-durability-lag/ (accessed 2026-10-12)

### Synthetic full backup

URL: https://hesela.dev/terms/synthetic-full-backup/
Status: shipping

Record updated: 2026-10-14

A synthetic full backup reconstructs a complete backup for a selected recovery point from retained full and incremental backup data without rereading the entire protected dataset from production.

Note: Synthesis reuses existing backup data. Veeam's documented Hyper-V workflow first takes a new incremental backup, so the overall job still reads recent production changes. [veeam-synthesis]

Advantages:
- PostgreSQL can use a combined full backup in place of its source chain for a later combination. (sources: [combine])

Limitations:
- PostgreSQL pg_combinebackup checks chain relationships, not the integrity of every input. (sources: [combine])
- With pg_combinebackup --link, hard-linked input and output files can affect each other when modified. (sources: [combine])
- PostgreSQL --no-sync skips the final durability wait; checksum-state changes across inputs can leave invalid page checksums. (sources: [combine])
- Linux reflinks isolate later writes through copy-on-write but still share underlying storage; they are not independent media copies. (sources: [ficlone])

Related terms:
- [full-backup](https://hesela.dev/terms/full-backup/)
- [incremental-backup](https://hesela.dev/terms/incremental-backup/)
- [backup-manifest](https://hesela.dev/terms/backup-manifest/)
- [backup-verification](https://hesela.dev/terms/backup-verification/)
- [restore-test](https://hesela.dev/terms/restore-test/)

Citations:
- [combine] PostgreSQL 18: pg_combinebackup, dependency chains and hard links. https://www.postgresql.org/docs/18/app-pgcombinebackup.html (accessed 2026-10-14)
- [veeam-synthesis] Veeam Backup & Replication: How Synthetic Full Backup Works (Hyper-V). https://helpcenter.veeam.com/docs/vbr/userguide/synthetic_full_hiw_hv.html (accessed 2026-10-14)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-14)
- [ficlone] Linux man-pages: FICLONE, shared storage and copy-on-write isolation. https://www.man7.org/linux/man-pages/man2/FICLONE.2const.html (accessed 2026-10-14)

### Systematic code

URL: https://hesela.dev/terms/systematic-code/
Also known as: Systematic encoding
Status: shipping

Record updated: 2026-10-13

A systematic code includes the original data symbols unchanged among its encoded symbols.

Note: In a generator-matrix representation this can be expressed by an identity block. Systematic layout alone does not imply MDS recovery: Hesela's GF(7) enumeration contains a systematic non-MDS counterexample. It is a teaching calculation, not a production codec. [hesela-matrix]

Limitations:
- An identity block does not prove that arbitrary surviving rows form an invertible recovery matrix.

Related terms:
- [maximum-distance-separable-code](https://hesela.dev/terms/maximum-distance-separable-code/)
- [reed-solomon-code](https://hesela.dev/terms/reed-solomon-code/)
- [erasure-coding](https://hesela.dev/terms/erasure-coding/)

Citations:
- [rfc5510] Lacan, Roca, Peltotalo and Peltotalo. RFC 5510 (2009), sections 3.1, 8.2-8.4: systematic encoding and the erasure-channel assumption.. https://www.rfc-editor.org/rfc/rfc5510.html (accessed 2026-10-13)
- [hesela-matrix] Hesela: Reed-Solomon recovery needs more than a fragment count (synthetic exact arithmetic). https://hesela.com/analyses/reed-solomon-matrix-recovery-guarantees/ (accessed 2026-10-13)

### INCITS T10 SCSI

URL: https://hesela.dev/terms/t10-scsi/
Status: shipping

Record updated: 2026-10-13

The standards body maintaining SCSI command sets used by SAS, FC, and iSCSI block devices.

Note: T10 separates the SCSI architecture model, command sets and transport protocols in its standards work. SAS is one SCSI transport; it does not make the broader SCSI architecture obsolete. [t10-architecture]

Related terms:
- [scsi](https://hesela.dev/terms/scsi/)
- [sas](https://hesela.dev/terms/sas/)
- [fibre-channel](https://hesela.dev/terms/fibre-channel/)
- [initiator-target](https://hesela.dev/terms/initiator-target/)

Citations:
- [c1] INCITS T10 SCSI. https://en.wikipedia.org/wiki/SCSI (accessed 2026-03-26)
- [t10-architecture] T10 working drafts: SCSI architecture, command sets and transports. https://www.t10.org/drafts.htm (accessed 2026-10-13)

### RAID tail hour

URL: https://hesela.dev/terms/tail-hour/
Also known as: tail hour
Status: research

Record updated: 2026-10-15

In The Tail at Store, a RAID tail hour is a group-hour in which at least one data drive has an hourly average I/O latency at least twice its group's median.

Note: The event is defined at hourly resolution and does not measure the fraction of individual slow requests or establish simultaneous stalls. A relative baseline can miss a shared absolute slowdown. [hao] The sample boundary differs from Perseus's workload-dependent slowdown ratio.

Related terms:
- [tail-latency](https://hesela.dev/terms/tail-latency/)
- [slowdown-ratio](https://hesela.dev/terms/slowdown-ratio/)
- [fail-slow](https://hesela.dev/terms/fail-slow/)

Citations:
- [hao] Hao et al., The Tail at Store, FAST 2016, sections 3.3 and 6. https://www.usenix.org/system/files/conference/fast16/fast16-papers-hao.pdf (accessed 2026-10-15)
- [hesela-tail] Hesela: Slow RAID hours are not request tail latency; source audit and reproducible counterexamples. https://hesela.com/analyses/storage-tail-slowdowns-raid-fanout/ (accessed 2026-10-15)

### Tail latency

URL: https://hesela.dev/terms/tail-latency/
Also known as: latency tail
Status: research

Record updated: 2026-10-15

Tail latency describes the high-latency part of an operation response-time distribution, usually summarized using specified high percentiles.

Note: State the operation population, timing boundaries, percentile estimator and observation window. An hourly mean cannot reconstruct request p99, and a wait-for-all fan-out request follows the slowest required response rather than an average leaf. [dean] The linked synthetic examples isolate these measurement differences.

Related terms:
- [latency-storage](https://hesela.dev/terms/latency-storage/)
- [tail-hour](https://hesela.dev/terms/tail-hour/)
- [coordinated-omission](https://hesela.dev/terms/coordinated-omission/)
- [fail-slow](https://hesela.dev/terms/fail-slow/)

Citations:
- [dean] Dean and Barroso, The Tail at Scale, CACM 56(2), 2013; DOI 10.1145/2408776.2408794. https://www.barroso.org/publications/TheTailAtScale.pdf (accessed 2026-10-15)
- [hesela-tail] Hesela: Slow RAID hours are not request tail latency; source audit and reproducible counterexamples. https://hesela.com/analyses/storage-tail-slowdowns-raid-fanout/ (accessed 2026-10-15)

### Tape buffer synchronization

URL: https://hesela.dev/terms/tape-buffer-synchronization/
Also known as: tape buffer flush
Status: shipping

Record updated: 2026-10-16

Tape buffer synchronization is completion of a supported operation that confirms previously buffered tape data and marks have been written to the medium.

Note: IBM 3592 documents WRITE FILEMARKS with IMMED=0 and transfer length zero for this purpose. Successful status matters, not just issuing a command. [ibm-3592] In Linux v6.12, MT_ST_NOWAIT_EOF changes MTWEOF and close-time filemarks to immediate operation, including the MTWEOF zero-count path; check configuration before treating completion as a synchronization boundary. [linux-st-code]

Limitations:
- Confirmation of covered writes is not proof of long-term readability or an application-level restore. (sources: [ibm-3592])

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)
- [tape-filemark](https://hesela.dev/terms/tape-filemark/)
- [restore-test](https://hesela.dev/terms/restore-test/)

Citations:
- [linux-st] Linux v6.12: SCSI tape driver, buffering and MT_ST_NOWAIT_EOF. https://github.com/torvalds/linux/blob/v6.12/Documentation/scsi/st.rst (accessed 2026-10-16)
- [linux-st-code] Linux v6.12 st.c: st_flush, st_set_options and st_int_ioctl. https://github.com/torvalds/linux/blob/v6.12/drivers/scsi/st.c#L2804 (accessed 2026-10-16)
- [ibm-3592] IBM 3592 SCSI Reference GA32-0968-07, section 5.2.52, page 199 (2026). https://www.ibm.com/support/pages/system/files/inline-files/3592%20SCSI%20Reference_GA32-0968-07.pdf#page=231 (accessed 2026-10-16)

### Tape encryption

URL: https://hesela.dev/terms/tape-encryption/
Status: shipping

Encrypting data as it is written to tape cartridges to protect offline media.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)
- [self-encrypting-drive](https://hesela.dev/terms/self-encrypting-drive/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)

Citations:
- [c1] Tape encryption. https://en.wikipedia.org/wiki/Linear_Tape-Open (accessed 2026-03-26)

### Tape filemark

URL: https://hesela.dev/terms/tape-filemark/
Also known as: filemark, tape mark
Status: shipping

Record updated: 2026-10-16

A tape filemark is a recorded logical delimiter separating files in a sequential tape stream.

Note: A mark is not itself a universal acknowledgement that earlier data reached the medium: immediate command semantics can allow buffered completion. IBM 3592 WRITE FILEMARKS with IMMED=0 and count=0 instead synchronizes pending data and marks without adding a delimiter. [ibm-3592] Linux MTWEOFI and MT_ST_NOWAIT_EOF require particular care when interpreting completion. [linux-st]

Limitations:
- File boundaries and confirmed medium completion are distinct properties. (sources: [ibm-3592], [linux-st])

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)
- [tape-buffer-synchronization](https://hesela.dev/terms/tape-buffer-synchronization/)

Citations:
- [linux-st] Linux v6.12: SCSI tape driver, buffering and MT_ST_NOWAIT_EOF. https://github.com/torvalds/linux/blob/v6.12/Documentation/scsi/st.rst (accessed 2026-10-16)
- [linux-st-code] Linux v6.12 st.c: st_flush, st_set_options and st_int_ioctl. https://github.com/torvalds/linux/blob/v6.12/drivers/scsi/st.c#L2804 (accessed 2026-10-16)
- [ibm-3592] IBM 3592 SCSI Reference GA32-0968-07, section 5.2.52, page 199 (2026). https://www.ibm.com/support/pages/system/files/inline-files/3592%20SCSI%20Reference_GA32-0968-07.pdf#page=231 (accessed 2026-10-16)

### Tape library

URL: https://hesela.dev/terms/tape-library/
Status: shipping

Record updated: 2026-10-15

Automated systems inserting LTO or enterprise tape cartridges into drives.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [lto](https://hesela.dev/terms/lto/)
- [ltfs](https://hesela.dev/terms/ltfs/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [tapealert](https://hesela.dev/terms/tapealert/)

Citations:
- [c1] Tape library. https://en.wikipedia.org/wiki/Tape_library (accessed 2026-03-26)

### Magnetic tape storage

URL: https://hesela.dev/terms/tape/
Also known as: tape drive, cartridge tape
Status: shipping

Record updated: 2026-10-16

Recorded firstSeen: 1951 (sources: [c2])

Sequential storage on linear magnetic tape in removable cartridges, used mainly for backup and cold archive.

Note: Magnetic tape records data on flexible oxide-coated ribbon in cartridges or reels, streamed past a helical or linear head assembly. Access is sequential: locating a file means winding to the right position, so latency is high relative to disk, but streaming bandwidth, removable media, and offline (“air gap”) custody suit backup and long-term archive. In modern enterprise practice, LTO Ultrium is the dominant open interchange format; proprietary enterprise libraries also exist historically. Tape complements always-online nearline HDD and object tiers rather than replacing random-access primary storage. Cost models emphasize media $/TB and energy when cartridges sit on shelves, not spindle power.

Advantages:
- Low cost per stored terabyte and offline portability for air-gapped copies. (sources: [c1])

Limitations:
- Random access is poor compared to disk or flash. (sources: [c1])

Related terms:
- [lto](https://hesela.dev/terms/lto/)
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [ltfs](https://hesela.dev/terms/ltfs/)
- [ltfs-index](https://hesela.dev/terms/ltfs-index/)
- [ltfs-data-placement-policy](https://hesela.dev/terms/ltfs-data-placement-policy/)
- [medium-auxiliary-memory](https://hesela.dev/terms/medium-auxiliary-memory/)
- [tape-filemark](https://hesela.dev/terms/tape-filemark/)
- [tape-buffer-synchronization](https://hesela.dev/terms/tape-buffer-synchronization/)

Citations:
- [c1] Magnetic tape data storage. https://en.wikipedia.org/wiki/Magnetic_tape_data_storage (accessed 2026-03-26)
- [c2] UNIVAC tape. https://www.computerhistory.org/revolution/memory-storage/8/187/695 (accessed 2026-03-26)
- [n3] LTO Program — FAQs about LTO technology. https://www.lto.org/faqs-about-lto/ (accessed 2026-10-07)
- [n4] LTO Program — Trust LTO overview. https://www.lto.org/trustlto/ (accessed 2026-10-07)
- [n5] IBM — Linear Tape File System (LTFS) overview. https://www.ibm.com/products/linear-tape-file-system (accessed 2026-10-07)

### TapeAlert

URL: https://hesela.dev/terms/tapealert/
Also known as: Tape Alert
Status: shipping

Record updated: 2026-10-15

TapeAlert is a SCSI status-reporting mechanism for tape devices that exposes condition flags through LOG SENSE page 2Eh.

Note: Flag numbers must be interpreted for the target device class: IBM LTO drive flag 4 identifies a media condition, whereas Oracle SL150 library flag 4 identifies a hardware fault [ibmlto] [oracle]. The HPE LTO-7 guide documents clear-on-read log parameters and zeros for unsupported flags [hpehost]. A later zero is not proof that no earlier event occurred. Coordinate readers and retain observations rather than treating flags as cumulative incident counters.

Limitations:
- Set/clear behavior is implementation-specific; NetBackup 10.x itself reads the log at job boundaries, so additional collectors need an explicit collection policy. (sources: [netbackup])
- Status flags do not supply a cartridge failure-rate denominator or establish readability of data that has not been read. (sources: [analysis])

Related terms:
- [lto](https://hesela.dev/terms/lto/)
- [tape-library](https://hesela.dev/terms/tape-library/)

Citations:
- [ibmlto] IBM Docs, TS4500: TapeAlert flags supported by LTO tape drives. https://www.ibm.com/docs/en/ts4500-tape-library?topic=flags-tapealert-supported-by-lto-tape-drives (accessed 2026-10-15)
- [oracle] Oracle StorageTek SL150 Modular Tape Library: Log Sense (4Dh), TapeAlert page 2Eh. https://docs.oracle.com/en/storage/tape-storage/storagetek-sl150-modular-tape-library/slorm/log-sense-4dh.html (accessed 2026-10-15)
- [hpehost] HPE Storage LTO-7 Ultrium Tape Drives Technical Reference Manual, Volume 3: TapeAlert log page 2Eh. https://support.hpe.com/hpesc/public/docDisplay?docId=sd00006909en_us&docLocale=en_US&page=GUID-D7147C7F-2016-0901-0922-0000000005A5.html (accessed 2026-10-15)
- [netbackup] Veritas NetBackup Backup Planning and Performance Tuning Guide (2024-04-16): How NetBackup TapeAlert works. https://origin-www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v19526982-146141073 (accessed 2026-10-15)
- [analysis] Hesela: TapeAlert observation limits and explicit event-rate arithmetic. https://hesela.com/analyses/tape-tapealert-failure-points/ (accessed 2026-10-15)

### TBW

URL: https://hesela.dev/terms/tbw/
Status: shipping

Terabytes Written rating estimates total host writes an SSD warranty covers before wear exhaustion.

Related terms:
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [dwpd](https://hesela.dev/terms/dwpd/)

Citations:
- [c1] TBW. https://en.wikipedia.org/wiki/Solid-state_drive (accessed 2026-03-26)

### TCG Opal

URL: https://hesela.dev/terms/tcg-opal/
Status: shipping

A Trusted Computing Group spec for managing hardware encryption on self-encrypting storage devices.

Related terms:
- [self-encrypting-drive](https://hesela.dev/terms/self-encrypting-drive/)
- [nvme](https://hesela.dev/terms/nvme/)

Citations:
- [c1] TCG Opal. https://en.wikipedia.org/wiki/Opal_Storage_Specification (accessed 2026-03-26)

### Temporal validation

URL: https://hesela.dev/terms/temporal-validation/
Also known as: time-forward validation, chronological validation
Status: shipping

Record updated: 2026-10-14

Temporal validation evaluates a predictor on later observations using training information available before the evaluation boundary.

Note: Training on earlier observations and testing on later ones approximates a future-prediction task; a random split can expose training to future conditions. [sklearn-validation] For disk errors, Xu et al. report a setting-specific gap between random and time-forward evaluation, not a universal correction factor. [xu-atc18] Chronological separation is different from grouping by drive identity: it does not by itself test generalization to unseen drives. Feature selection and preprocessing must be fitted using training data only. [sklearn-pitfalls]

Limitations:
- Storage evaluation should state prediction time, outcome horizon, label availability, drive overlap and test prevalence; a chronological split alone is not proof that all leakage is absent. (sources: [xu-atc18], [sklearn-validation], [sklearn-pitfalls])

Related terms:
- [smart](https://hesela.dev/terms/smart/)
- [class-prevalence](https://hesela.dev/terms/class-prevalence/)
- [precision](https://hesela.dev/terms/precision/)
- [recall](https://hesela.dev/terms/recall/)
- [f1-score](https://hesela.dev/terms/f1-score/)
- [drive-day](https://hesela.dev/terms/drive-day/)
- [prediction-horizon](https://hesela.dev/terms/prediction-horizon/)
- [grouped-cross-validation](https://hesela.dev/terms/grouped-cross-validation/)
- [failure-label](https://hesela.dev/terms/failure-label/)

Citations:
- [sklearn-validation] scikit-learn: cross-validation, grouped data and time-series evaluation.. https://scikit-learn.org/stable/modules/cross_validation.html (accessed 2026-10-14)
- [xu-atc18] Xu et al. Improving Service Availability of Cloud Systems by Predicting Disk Error. USENIX ATC 2018, sections 2.2 and 4.4.. https://www.usenix.org/system/files/conference/atc18/atc18-xu-yong.pdf (accessed 2026-10-14)
- [sklearn-pitfalls] scikit-learn: common pitfalls, preprocessing and data leakage.. https://scikit-learn.org/stable/common_pitfalls.html#data-leakage (accessed 2026-10-14)

### Thermal flying-height control (TFC)

URL: https://hesela.dev/terms/thermal-flying-height-control/
Also known as: TFC, thermal fly-height control
Status: shipping

Record updated: 2026-10-15

Thermal flying-height control uses an embedded heater to adjust HDD head-disk clearance through local thermal protrusion.

Note: Heating changes the shape near the read/write element; gas-bearing response also affects the resulting clearance [control]. It is a spacing-control mechanism, not SSD thermal throttling. Research touchdown procedures are not instructions to stress a drive carrying valuable data.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [head-disk-interface](https://hesela.dev/terms/head-disk-interface/)
- [flying-height](https://hesela.dev/terms/flying-height/)
- [touchdown-sensor](https://hesela.dev/terms/touchdown-sensor/)

Citations:
- [control] Juang and Bogy: Design and Analysis of a Flying Height Control Slider with Thermal Nanoactuator, CML report 06004, sections 1-2. https://cml.berkeley.edu/wp-content/uploads/blue-reports/06004.pdf (accessed 2026-10-15)
- [analysis] Hesela: HDD mechanical faults, evidence and diagnostic limits. https://hesela.com/analyses/hdd-mechanical-failure-points/ (accessed 2026-10-15)

### SSD thermal throttling

URL: https://hesela.dev/terms/thermal-throttling-ssd/
Status: shipping

Record updated: 2026-10-16

SSD thermal throttling is a controller response that limits activity or performance to manage device temperature.

Note: Thermal behavior depends on the device and firmware; NVMe HCTM is one specified control mechanism, not a synonym for every thermal safeguard. Its action counters must be distinguished from time above warning or critical thresholds. [base23] The WDC temperature-statistics command reports vendor-specific fields on supported devices, so its output is not a portable inventory of every SSD's sensors or shutdown thresholds. [nvmecli]

Limitations:
- A slowdown alone does not establish a thermal cause, and a zero HCTM counter can mean an unimplemented field rather than no throttling. (sources: [nvmelog])

Related terms:
- [ssd](https://hesela.dev/terms/ssd/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [sd-express](https://hesela.dev/terms/sd-express/)
- [nvme-composite-temperature](https://hesela.dev/terms/nvme-composite-temperature/)
- [host-controlled-thermal-management](https://hesela.dev/terms/host-controlled-thermal-management/)
- [nvme-warning-composite-temperature-time](https://hesela.dev/terms/nvme-warning-composite-temperature-time/)
- [nvme-critical-composite-temperature-time](https://hesela.dev/terms/nvme-critical-composite-temperature-time/)

Citations:
- [base23] NVM Express Base Specification 2.3: Figure 210 (pp. 214-217), temperature hysteresis section 5.2.26.1.3.1, HCTM Figure 417 (p. 410). https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-Revision-2.3-2025.08.01-Ratified.pdf (accessed 2026-10-15)
- [nvmelog] libnvme v1.15: nvme_smart_log field definitions (July 2025). https://github.com/linux-nvme/libnvme/blob/v1.15/doc/man/nvme_smart_log.2 (accessed 2026-10-15)
- [nvmecli] nvme-cli v2.13: WDC vendor temperature statistics command. https://github.com/linux-nvme/nvme-cli/blob/v2.13/Documentation/nvme-wdc-vs-temperature-stats.1 (accessed 2026-10-15)

### Thin provisioning

URL: https://hesela.dev/terms/thin-provisioning/
Status: shipping

Record updated: 2026-10-13

Presenting logical storage capacity while allocating physical backing from a shared pool as writes require it.

Note: Linux device-mapper thin pools separate logical mappings from underlying allocation. The no_discard_passdown feature removes mappings without forwarding discard to the data device; ignore_discard disables discard support. These modes are not equivalent. Reclamation at one layer does not establish erasure at a lower layer. Logical volume size and filesystem free space do not establish pool headroom. LVM exposes Data% and Meta% separately; monitor both and verify that automatic extension has available volume-group space and time to respond. Linux 6.12 distinguishes data-space exhaustion from metadata exhaustion or failed metadata operations, which can require offline repair and checks of higher layers. File preallocation is not evidence of an end-to-end reservation across this stack.

Limitations:
- A thin-pool mapping can be removed without a discard reaching the underlying device. (sources: [dm-thin])
- Pool data and metadata are separate finite resources; sufficient logical capacity does not prevent exhaustion. (sources: [lvmthin], [dm-thin])
- Metadata exhaustion must not be treated as merely waiting for an ordinary data-pool extension. (sources: [dm-thin])

Related terms:
- [snapshot](https://hesela.dev/terms/snapshot/)
- [block-storage](https://hesela.dev/terms/block-storage/)
- [all-flash-array](https://hesela.dev/terms/all-flash-array/)
- [discard](https://hesela.dev/terms/discard/)
- [scsi-unmap](https://hesela.dev/terms/scsi-unmap/)
- [sparse-file](https://hesela.dev/terms/sparse-file/)
- [hole-punching](https://hesela.dev/terms/hole-punching/)
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Thin provisioning. https://en.wikipedia.org/wiki/Thin_provisioning (accessed 2026-03-26)
- [dm-thin] Linux 6.12: device-mapper thin provisioning, optional feature arguments. https://raw.githubusercontent.com/torvalds/linux/v6.12/Documentation/admin-guide/device-mapper/thin-provisioning.rst (accessed 2026-10-11)
- [hesela-discard] Hesela: Discard is not zeroing. https://hesela.com/analyses/discard-is-not-zeroing/ (accessed 2026-10-11)
- [lvmthin] LVM2: lvmthin(7), physical allocation, discards and pool exhaustion. https://man7.org/linux/man-pages/man7/lvmthin.7.html (accessed 2026-10-12)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)

### Storage throughput

URL: https://hesela.dev/terms/throughput-storage/
Status: shipping

Record updated: 2026-10-13

Storage throughput is the amount of data transferred per unit time at a specified system boundary, usually expressed in bytes per second.

Note: On 21 May 2021 Principled Technologies finished a KIOXIA-commissioned Vdbench test of one three-node VMware vSAN cluster per configuration. At 128K, 100 percent sequential read, the 100 percent IOrate cluster totals were 10,366 MB/s on NVMe, 4,566 MB/s on 12 Gbps SAS, and 2,776 MB/s on 6 Gbps SATA. Latency on those same rows was 13.88 ms, 13.27 ms, and 3.51 ms. The gigabit rates are the printed link labels and are not converted to MB/s. Table: https://hesela.dev/datasets/sata-sas-nvme-measured-throughput/ For one completed-operation population and interval, divide total transferred bytes by elapsed seconds; with mixed sizes, the matching bytes-per-operation mean is weighted by operation count, not by byte share [hesela-accounting]. A link rate in bits/s is not a measured data-transfer rate.

Limitations:
- Cluster MB/s at each configuration's own 100 percent Vdbench IOrate is not a per-drive peak and not a common-latency comparison. At 128K the NVMe total was 10,366 MB/s at 13.88 ms, while SATA was 2,776 MB/s at 3.51 ms. (sources: [pt-science-0921])

Related terms:
- [iops](https://hesela.dev/terms/iops/)
- [sata](https://hesela.dev/terms/sata/)
- [sas](https://hesela.dev/terms/sas/)
- [nvme](https://hesela.dev/terms/nvme/)
- [io-request-size](https://hesela.dev/terms/io-request-size/)
- [queue-depth](https://hesela.dev/terms/queue-depth/)

Citations:
- [c1] Storage throughput. https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics (accessed 2026-03-26)
- [pt-science-0921] The science behind the report: Process more read-heavy I/O with HPE ProLiant DL385 Gen10 Plus servers configured with KIOXIA value SAS and NVMe mainstream SSDs (Principled Technologies, September 2021). https://www.principledtechnologies.com/KIOXIA/RM5-Series-value-SAS-and-CD6-NVMe-mainstream-vs-SATA-Vdbench-science-0921.pdf (accessed 2026-10-11)
- [pt-report-0921] Process more read-heavy I/O with HPE ProLiant DL385 Gen10 Plus servers configured with KIOXIA value SAS and NVMe mainstream SSDs (Principled Technologies, September 2021). https://www.principledtechnologies.com/KIOXIA/RM5-Series-value-SAS-and-CD6-NVMe-mainstream-vs-SATA-Vdbench-0921.pdf (accessed 2026-10-11)
- [kioxia-faq-2021] What You Need To Know About PCIe 4.0 NVMe SSDs, KIOXIA FAQ, April 2021, Rev. 2.5. https://www.kioxia.com/content/dam/kioxia/shared/business/ssd/asset/KIOXIA_What_You_Need_To_Know_About_PCIe_4_NVMe_SSDs_FAQ.pdf (accessed 2026-10-11)
- [hesela-accounting] Hesela: IOPS, bytes and average occupancy; synthetic accounting examples.. https://hesela.com/analyses/storage-latency-coordinated-omission/#io-accounting (accessed 2026-10-13)
- [linux-iostats] Linux kernel documentation: I/O statistics fields; completed requests, merged requests and sectors.. https://docs.kernel.org/admin-guide/iostats.html (accessed 2026-10-13)

### Thunderbolt storage

URL: https://hesela.dev/terms/thunderbolt-storage/
Status: shipping

PCIe tunneling over Thunderbolt enables external NVMe enclosures at near-internal link speeds.

Related terms:
- [pcie-storage](https://hesela.dev/terms/pcie-storage/)
- [nvme](https://hesela.dev/terms/nvme/)
- [m2](https://hesela.dev/terms/m2/)

Citations:
- [c1] Thunderbolt storage. https://en.wikipedia.org/wiki/Thunderbolt_(interface) (accessed 2026-03-26)

### Tiered compaction

URL: https://hesela.dev/terms/tiered-compaction/
Also known as: Size-tiered compaction
Status: shipping

Record updated: 2026-10-14

Tiered compaction allows multiple sorted runs to accumulate and merges groups of runs into typically larger runs instead of maintaining one run at every tier.

Note: Policies commonly group similarly sized runs; exact selection rules vary. Tiering generally reduces rewriting relative to leveling while retaining more runs to search and more obsolete data between merges. These are trade-offs, not fixed amplification factors. [rocks-compaction] Universal compaction is RocksDB's implementation in this family, not a synonym for every tiered policy. It selects runs consecutive in age order; one run can span several SST files. Its space trigger is an estimate, not a hard limit on disk use. [rocks-universal]

Related terms:
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [compaction](https://hesela.dev/terms/compaction/)
- [leveled-compaction](https://hesela.dev/terms/leveled-compaction/)
- [read-amplification](https://hesela.dev/terms/read-amplification/)
- [space-amplification](https://hesela.dev/terms/space-amplification/)

Citations:
- [rocks-compaction] RocksDB project. Compaction: leveled, tiered and hybrid policies.. https://github.com/facebook/rocksdb/wiki/Compaction (accessed 2026-10-14)
- [rocks-universal] RocksDB project. Universal Compaction: run selection, temporary space and amplification heuristic.. https://github.com/facebook/rocksdb/wiki/Universal-Compaction (accessed 2026-10-14)
- [hesela] Hesela. Bloom filters: optimize the lookup, not each filter; compaction and measurement boundaries.. https://hesela.com/analyses/bloom-filters-lsm-read-cost/ (accessed 2026-10-14)

### Tiled magnetic recording

URL: https://hesela.dev/terms/tiled-media/
Status: research

A proposed patterning approach grouping grains into magnetic tiles for higher density.

Related terms:
- [bit-patterned-media](https://hesela.dev/terms/bit-patterned-media/)
- [hamr](https://hesela.dev/terms/hamr/)

Citations:
- [c1] Tiled magnetic recording. https://en.wikipedia.org/wiki/Perpendicular_recording (accessed 2026-03-26)

### TLC SSD

URL: https://hesela.dev/terms/tlc-ssd/
Status: shipping

SSDs using triple-level cell NAND as the mainstream balance of cost and endurance.

Related terms:
- [tlc](https://hesela.dev/terms/tlc/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)

Citations:
- [c1] TLC SSD. https://en.wikipedia.org/wiki/Triple-level_cell (accessed 2026-03-26)

### Triple-level cell (TLC)

URL: https://hesela.dev/terms/tlc/
Also known as: 3 bits per cell
Status: shipping

Record updated: 2026-10-16

NAND flash that stores three bits per cell using eight charge levels, common in consumer and many enterprise SSDs.

Note: Triple-Level Cell NAND stores three bits per cell across eight voltage levels. Narrower margins than SLC/MLC increase program time and reduce raw endurance, which controllers offset with over-provisioning, strong ECC, and often an SLC-mode write cache. TLC (especially 3D TLC) is the dominant media class in client SSDs and many datacenter read-intensive or mixed-use drives as of the mid-2020s. It is not a protocol or form factor—pair TLC with SATA/NVMe and client vs enterprise firmware when comparing SKUs. Endurance (TBW/DWPD) must come from the specific datasheet, not from the “TLC” label alone. Samsung's 2015 technical whitepaper documents its client TLC SSD introduction in 2012. This is a commercialization milestone, not an invention date; a global first appearance is not established here. [n2]

Related terms:
- [qlc](https://hesela.dev/terms/qlc/)
- [mlc](https://hesela.dev/terms/mlc/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)
- [slc](https://hesela.dev/terms/slc/)
- [slc-cache](https://hesela.dev/terms/slc-cache/)
- [pseudo-slc](https://hesela.dev/terms/pseudo-slc/)

Supersedes:
- [mlc](https://hesela.dev/terms/mlc/)

Superseded by:
- [qlc](https://hesela.dev/terms/qlc/)

Citations:
- [c1] Triple-level cell. https://en.wikipedia.org/wiki/Triple-level_cell (accessed 2026-03-26)
- [n2] Samsung — Evaluating MLC vs TLC vs V-NAND. https://s7d2.scene7.com/is/content/SamsungUS/b2b/resource/2015/11/25/WHP-SSD-MLCvsTLC-OCT15J_1.pdf (accessed 2026-10-16)
- [n3] SNIA — NVMe, SAS, and SATA SSD endurance white paper. https://www.snia.org/sites/default/files/SSSI/NVMe_SAS_SATA_Endurance_White_Paper.pdf (accessed 2026-10-07)

### Torn write

URL: https://hesela.dev/terms/torn-write/
Also known as: partial page write
Status: shipping

Record updated: 2026-10-14

A torn write is an interrupted write that persists only part of its intended update, potentially leaving a database page with mixed old and new contents.

Note: A database page may span several storage write units, so a page write cannot automatically be treated as atomic. PostgreSQL documents full-page images as protection for recovery from this failure. Transaction atomicity and page-write atomicity describe different boundaries. Torn-write protection permits the complete old value instead of a mixture; it does not by itself make the replacement durable. Linux RWF_ATOMIC requests this protection for one supported direct-I/O range. In FAST 2013, shorn writes described partial updates below the expected atomic unit; the tested SSDs included mixed old/new 4 KiB records. This historical observation does not estimate current-device risk. Powersafe overwrite is independent: it concerns unchanged bytes outside the requested range, so it can coexist with a torn target range. [sqlite-psow]

Limitations:
- A transaction log containing only change records may not reconstruct a partially written page. (sources: [pg-settings])

Related terms:
- [full-page-write](https://hesela.dev/terms/full-page-write/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)
- [rwf-atomic](https://hesela.dev/terms/rwf-atomic/)
- [statx-write-atomic](https://hesela.dev/terms/statx-write-atomic/)
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [lost-write](https://hesela.dev/terms/lost-write/)
- [physical-sector](https://hesela.dev/terms/physical-sector/)
- [powersafe-overwrite](https://hesela.dev/terms/powersafe-overwrite/)

Citations:
- [pg-reliability] PostgreSQL 18: Reliability. https://www.postgresql.org/docs/18/wal-reliability.html (accessed 2026-10-11)
- [pg-settings] PostgreSQL 18: WAL settings. https://www.postgresql.org/docs/18/runtime-config-wal.html (accessed 2026-10-11)
- [hesela-wal] WAL, checkpoints and torn pages: three different recovery guarantees. https://hesela.com/analyses/wal-checkpoints-torn-pages/ (accessed 2026-10-11)
- [pwritev2] Linux man-pages 6.19, readv(2): RWF_ATOMIC. https://man7.org/linux/man-pages/man2/readv.2.html (accessed 2026-10-12)
- [hesela-atomic] Linux atomic writes: untorn does not mean durable. https://hesela.com/analyses/linux-atomic-writes-durability/ (accessed 2026-10-12)
- [zheng-power] Zheng, Tucek, Qin and Lillibridge: Understanding the Robustness of SSDs under Power Fault, FAST 2013, sections 4.2 and 5.3. https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf (accessed 2026-10-12)
- [hesela-sector-alignment] 512e, 4Kn and alignment: geometry is not durability. https://hesela.com/analyses/sector-sizes-alignment-not-durability/ (accessed 2026-10-12)
- [sqlite-psow] SQLite: Powersafe Overwrite, scope, assumptions and torn pages.. https://www.sqlite.org/psow.html (accessed 2026-10-14)

### Touchdown sensor (TDS)

URL: https://hesela.dev/terms/touchdown-sensor/
Also known as: TDS, embedded contact sensor
Status: shipping

Record updated: 2026-10-15

An HDD touchdown sensor is a temperature-sensitive element used to observe thermal changes near the head-disk interface during clearance and contact studies.

Note: Ma et al. describe a thin-film resistance sensor whose response includes both pre-contact cooling changes and contact-related heating [touchdown]. Their experiment recorded its AC component; the spacing signal and sensor signal were not acquired simultaneously in the stage comparison. A sensor variation alone is not proof of contact, a calibrated absolute gap or a catastrophic head crash.

Related terms:
- [head-disk-interface](https://hesela.dev/terms/head-disk-interface/)
- [thermal-flying-height-control](https://hesela.dev/terms/thermal-flying-height-control/)

Citations:
- [touchdown] Ma, Xue, Peng and Bogy: Study of Head Disk Interface Characterization using Touchdown Sensor and Electro-Magnetic Signal in Hard Disk Drives, CML report 15013, sections I-III. https://cml.berkeley.edu/wp-content/uploads/blue-reports/15013.pdf (accessed 2026-10-15)
- [analysis] Hesela: HDD mechanical faults, evidence and diagnostic limits. https://hesela.com/analyses/hdd-mechanical-failure-points/ (accessed 2026-10-15)

### FTL translation page

URL: https://hesela.dev/terms/translation-page/
Also known as: mapping page
Status: shipping

Record updated: 2026-10-12

An FTL translation page is a flash page containing address-mapping entries.

Note: A demand-mapping miss may fetch it before the requested user data.

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [dram-cache-ssd](https://hesela.dev/terms/dram-cache-ssd/)
- [hmb](https://hesela.dev/terms/hmb/)
- [mapping-cache](https://hesela.dev/terms/mapping-cache/)

Citations:
- [learned] Shengzhe Wang, Zihang Lin, Suzhen Wu, Hong Jiang, Jie Zhang and Bo Mao. LearnedFTL: A Learning-Based Page-Level FTL for Reducing Double Reads in Flash-Based SSDs. HPCA 2024, pp. 616-629, sections II-IV; DOI 10.1109/HPCA57654.2024.00054.. https://ranger.uta.edu/~jiang/publication/Conferences/2024/HPCA24%28LearnedFTL%29.pdf (accessed 2026-10-12)
- [hesela] SSD mapping caches: why DRAM size is not a speed rating. https://hesela.com/analyses/ssd-mapping-cache-hmb/ (accessed 2026-10-12)

### TRIM

URL: https://hesela.dev/terms/trim/
Also known as: ATA TRIM
Status: shipping

The ATA DATA SET MANAGEMENT Trim function tells a device that specified logical block ranges are no longer needed.

Note: TRIM is ATA terminology; SCSI UNMAP and NVMe Dataset Management Deallocate are related operations, not alternate names for the same command. Linux exposes discard above these protocol-specific interfaces. Ordinary discard is not secure discard or a guarantee that old physical copies were erased.

Advantages:
- Helps maintain write performance and reduces unnecessary erase cycles. (sources: [c1])

Limitations:
- Ordinary discard is not secure discard; util-linux documents secure discard as a separate, device-dependent operation that also erases garbage-collection copies. (sources: [discard])

Related terms:
- [ssd](https://hesela.dev/terms/ssd/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [sata](https://hesela.dev/terms/sata/)
- [nvme](https://hesela.dev/terms/nvme/)
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)
- [sanitize-nvme](https://hesela.dev/terms/sanitize-nvme/)
- [discard](https://hesela.dev/terms/discard/)
- [scsi-unmap](https://hesela.dev/terms/scsi-unmap/)
- [deallocated-read-behavior](https://hesela.dev/terms/deallocated-read-behavior/)

Citations:
- [c1] TRIM. https://en.wikipedia.org/wiki/TRIM (accessed 2026-03-26)
- [n2] TechTarget — What is SSD TRIM?. https://www.techtarget.com/it-infrastructure/definition/SSD-TRIM (accessed 2026-10-07)
- [n3] NVM Express — NVM Command Set Specification (Dataset Management / deallocate). https://nvmexpress.org/wp-content/uploads/NVMe-NVM-Command-Set-Specification-1.0a-2021.07.26-Ratified.pdf (accessed 2026-10-07)
- [n4] Linux storage — discard/TRIM stack discussion (LF slides). https://events.static.linuxfound.org/sites/events/files/slides/discard_0.pdf (accessed 2026-10-07)
- [discard] util-linux: blkdiscard documentation. https://github.com/util-linux/util-linux/blob/master/sys-utils/blkdiscard.8.adoc (accessed 2026-10-10)
- [hesela] Hesela: SSD sanitization: why TRIM and a successful command are not enough. https://hesela.com/analyses/ssd-sanitization-trim-evidence/ (accessed 2026-10-10)
- [sg-unmap] sg3_utils: sg_unmap manual, description. https://raw.githubusercontent.com/hreinecke/sg3_utils/master/doc/sg_unmap.8 (accessed 2026-10-11)
- [hesela-discard] Hesela: Discard is not zeroing. https://hesela.com/analyses/discard-is-not-zeroing/ (accessed 2026-10-11)

### TMR read head

URL: https://hesela.dev/terms/tunnel-magnetoresistive-head/
Status: shipping

Tunnel magnetoresistance sensors succeeded GMR heads for higher signal on dense tracks.

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [pmr](https://hesela.dev/terms/pmr/)

Citations:
- [c1] TMR read head. https://en.wikipedia.org/wiki/Tunnel_magnetoresistive_effect (accessed 2026-03-26)

### U.2 / U.3

URL: https://hesela.dev/terms/u2/
Also known as: SFF-8639, U.2 SSD
Status: shipping

Enterprise SSD bay and connector family derived from SFF-8639, supporting NVMe and legacy SAS/SATA pinouts in U.3.

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [edsff](https://hesela.dev/terms/edsff/)
- [pcie-lanes](https://hesela.dev/terms/pcie-lanes/)

Citations:
- [c1] SFF-8639. https://en.wikipedia.org/wiki/SFF-8639 (accessed 2026-03-26)

### UASP

URL: https://hesela.dev/terms/uasp/
Also known as: UAS, USB Attached SCSI, USB Attached SCSI Protocol
Status: shipping

Record updated: 2026-10-15

USB Attached SCSI Protocol (UASP) transports SCSI commands over USB and supports multiple outstanding commands, without by itself guaranteeing throughput, SMART pass-through or durable writes.

Note: Linux v6.12 registers the uas driver separately from usb-storage. Its abort callback returns FAILED without sending a device abort; a separate recovery handler attempts a USB device reset. An abort or reset message identifies recovery, not a defective bridge or a healthy disk. The usb-storage.quirks flag u prevents UAS binding, whereas t blocks ATA(12)/ATA(16) pass-through on UAS: driver selection and health-data visibility are different capabilities. These are pinned implementation details, not a universal restriction of the protocol.

Advantages:
- Command queuing can provide concurrency when the host, bridge and device support it.

Limitations:
- A timeout does not identify a failed component or prove a write never executed.
- Disabling UAS can change error-recovery behavior without fixing the underlying fault.

Related terms:
- [usb-mass-storage](https://hesela.dev/terms/usb-mass-storage/)
- [scsi](https://hesela.dev/terms/scsi/)
- [io-timeout](https://hesela.dev/terms/io-timeout/)

Citations:
- [c1] UASP. https://en.wikipedia.org/wiki/USB_Attached_SCSI (accessed 2026-03-26)
- [uas-linux] Linux v6.12: UAS driver implementation. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/drivers/usb/storage/uas.c (accessed 2026-10-15)
- [usb-quirks] Linux v6.12: usb-storage.quirks. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/Documentation/admin-guide/kernel-parameters.txt (accessed 2026-10-15)
- [hesela-usb] USB storage resets: recovery is not a root-cause diagnosis. https://hesela.com/analyses/usb-sata-bridge-uas-failure-signatures/ (accessed 2026-10-15)

### UDO

URL: https://hesela.dev/terms/udo/
Status: eol

Ultra Density Optical was a 30 GB-class professional WORM optical cartridge format.

Related terms:
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [worm-storage](https://hesela.dev/terms/worm-storage/)

Citations:
- [c1] UDO. https://en.wikipedia.org/wiki/Ultra_Density_Optical (accessed 2026-03-26)

### Uncorrectable bit error rate

URL: https://hesela.dev/terms/uncorrectable-bit-error-rate/
Also known as: UBER, uncorrectable bit error ratio
Status: shipping

Record updated: 2026-10-12

Uncorrectable bit error rate is a storage reliability metric that normalizes unrecovered data-error outcomes by a specified bit count after the stated correction and recovery procedures.

Note: State the event unit and denominator: Solidigm's D7-P5810 brief specifies UBER in sectors per bits read. [solidigm-p5810] Cai and colleagues instead normalize codeword failure rate by codeword length in their ECC comparison. [cai2017] Neither convention counts every wrong bit in a failed unit. A specification limit is not an observed fleet rate, and does not by itself establish independent, constant-probability errors.

Limitations:
- A source's counting convention must accompany its UBER value before comparison or use in a reliability model. (sources: [solidigm-p5810], [cai2017])

Related terms:
- [bit-error-rate](https://hesela.dev/terms/bit-error-rate/)
- [raw-bit-error-rate](https://hesela.dev/terms/raw-bit-error-rate/)
- [error-correcting-code](https://hesela.dev/terms/error-correcting-code/)
- [codeword](https://hesela.dev/terms/codeword/)
- [ldpc](https://hesela.dev/terms/ldpc/)
- [latent-sector-error](https://hesela.dev/terms/latent-sector-error/)

Citations:
- [solidigm-p5810] Solidigm D7-P5810 product brief, page 3 reliability table and page 4 qualification note.. https://www.solidigm.com/content/dam/solidigm/en/site/products/data-center/product-briefs/d7-5810/documents/solidigm-d7-p5810-product-brief.pdf (accessed 2026-10-12)
- [cai2017] Cai et al. Error Characterization, Mitigation, and Recovery in Flash Memory Based Solid-State Drives (2017), sections II.C and VI.C.. https://research.ece.cmu.edu/safari/pubs/1706.08642.pdf (accessed 2026-10-12)
- [hesela-ldpc] Hesela: LDPC in NAND, the read cost of confidence.. https://hesela.com/analyses/ldpc-soft-decoding-read-cost/ (accessed 2026-10-12)

### Unlink

URL: https://hesela.dev/terms/unlink/
Also known as: unlink()
Status: shipping

Record updated: 2026-10-16

Unlink is the removal of a directory entry naming a file; POSIX semantics preserve existing open references, while network-filesystem behavior requires additional qualification.

Note: Linux unlink() removes a name; if that was the last hard link, existing open references can keep the file usable after its pathname disappears. Reclamation depends on releasing the remaining references, not merely removing one pathname. A symbolic-link argument removes the symbolic link itself, not its target. Plain unlink() does not remove directories; unlinkat() with AT_REMOVEDIR requests directory removal instead. Namespace removal is not secure erasure or proof of crash-persistent deletion. On ext4, orphan recovery completes pending reclamation after a crash; it does not establish whether an application's namespace change was durably synchronized. [linux-v6-12-ext4-orphan] [linux-fsync-2] Removing and recreating a coordination-file name can let participants lock different files; a persistent name is part of the locking protocol, not disposable cleanup. [hesela-locks] NFS requires a separate scope check: the Linux unlink manual documents active silly-renamed files as a possible EBUSY cause and warns about loss of access to files still in use. [linux-unlink-2] See the NFS records for conditional server preservation. [hesela-unlink]

Advantages:
- Allows a name to be removed without interrupting existing users of the open file.

Limitations:
- Other hard links and open references can preserve the file after the name is removed.
- Does not promise physical erasure or persistent deletion after a crash.
- Do not assume all NFS clients and servers preserve every remote open reference when a name is removed.

Related terms:
- [inode](https://hesela.dev/terms/inode/)
- [hard-link](https://hesela.dev/terms/hard-link/)
- [atomic-rename](https://hesela.dev/terms/atomic-rename/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [directory-fsync](https://hesela.dev/terms/directory-fsync/)
- [ext4-orphan-inode](https://hesela.dev/terms/ext4-orphan-inode/)
- [ext4-orphan-file](https://hesela.dev/terms/ext4-orphan-file/)
- [advisory-file-lock](https://hesela.dev/terms/advisory-file-lock/)
- [nfs-silly-rename](https://hesela.dev/terms/nfs-silly-rename/)
- [nfs-preserve-unlinked](https://hesela.dev/terms/nfs-preserve-unlinked/)

Citations:
- [linux-unlink-2] Linux man-pages 6.19: unlink(2). https://man7.org/linux/man-pages/man2/unlink.2.html (accessed 2026-10-15)
- [linux-open-2] Linux man-pages 6.19: open(2). https://man7.org/linux/man-pages/man2/open.2.html (accessed 2026-10-15)
- [linux-fsync-2] Linux man-pages 6.19: fsync(2). https://man7.org/linux/man-pages/man2/fsync.2.html (accessed 2026-10-15)
- [hesela-namespace] Hesela: The name changes; existing readers do not. https://hesela.com/analyses/atomic-rename-directory-durability/#namespace-identity (accessed 2026-10-15)
- [linux-v6-12-ext4-orphan] Linux v6.12: ext4 orphan inode handling. https://github.com/torvalds/linux/blob/adc218676eef25575469234709c2d87185ca223a/fs/ext4/orphan.c (accessed 2026-10-15)
- [hesela-locks] Hesela: A lock follows the opened file, not the replacement name. https://hesela.com/analyses/atomic-rename-directory-durability/#lock-identity (accessed 2026-10-16)
- [hesela-unlink] Why deleted NFS files become .nfs files. https://hesela.com/analyses/nfs-silly-rename-open-unlink/ (accessed 2026-10-16)

### UNMAP

URL: https://hesela.dev/terms/unmap/
Status: shipping

The SCSI UNMAP command requests deallocation of logical blocks.

Note: This legacy record remains available to preserve its stable URL and JSON identifier. The detailed SCSI command entry is scsi-unmap. UNMAP should not be used as the protocol-neutral name for ATA TRIM or NVMe Dataset Management; use discard for the cross-stack concept.

Related terms:
- [discard](https://hesela.dev/terms/discard/)
- [trim](https://hesela.dev/terms/trim/)
- [scsi-unmap](https://hesela.dev/terms/scsi-unmap/)

Citations:
- [sg-unmap] sg3_utils: sg_unmap manual, description. https://raw.githubusercontent.com/hreinecke/sg3_utils/master/doc/sg_unmap.8 (accessed 2026-10-11)
- [hesela-discard] Hesela: Discard is not zeroing. https://hesela.com/analyses/discard-is-not-zeroing/ (accessed 2026-10-11)

### Unserializable write

URL: https://hesela.dev/terms/unserializable-write/
Also known as: unserializable writes
Status: shipping

Record updated: 2026-10-13

An unserializable write is a storage failure in which recovered contents cannot be reconciled with an operation order allowed by the known write history.

Note: In the FAST 2013 power-fault study, the relevant history includes synchronous issue and completion ordering. A record can pass its own checksum while the collection violates that history. This storage-recovery usage is not a claim that a database offers serializable transaction isolation. [zheng-power]

Related terms:
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)
- [lost-write](https://hesela.dev/terms/lost-write/)
- [torn-write](https://hesela.dev/terms/torn-write/)
- [checksum](https://hesela.dev/terms/checksum/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)

Citations:
- [zheng-power] Zheng et al., FAST 2013, section 3.2: Detecting global failures. https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf (accessed 2026-10-13)

### Unwritten extent

URL: https://hesela.dev/terms/unwritten-extent/
Also known as: uninitialized extent
Status: shipping

Record updated: 2026-10-16

An allocated filesystem extent whose data is not initialized and is exposed as zeros when read through the filesystem.

Note: Unlike a hole it has allocation; unlike delayed allocation it has assigned storage. FIEMAP marks this state UNWRITTEN; direct-device contents are undefined, so filesystem zero reads do not establish device contents or sanitization. FIEMAP DELALLOC implies UNKNOWN, but UNKNOWN alone does not identify delayed allocation. A three-file Hesela observation on ext4 found identical zero readback before and after allocation changes; this is a scoped example, not a universal physical-space measurement.

Related terms:
- [file-extent](https://hesela.dev/terms/file-extent/)
- [fiemap](https://hesela.dev/terms/fiemap/)
- [file-preallocation](https://hesela.dev/terms/file-preallocation/)
- [sparse-file](https://hesela.dev/terms/sparse-file/)
- [hole-punching](https://hesela.dev/terms/hole-punching/)
- [delayed-allocation](https://hesela.dev/terms/delayed-allocation/)

Citations:
- [fiemap] Linux 6.12: FIEMAP extent states and access restrictions. https://docs.kernel.org/6.12/filesystems/fiemap.html (accessed 2026-10-16)
- [hesela-allocation] Sparse files, preallocation and thin-pool capacity. https://hesela.com/analyses/sparse-files-preallocation-thin-capacity/ (accessed 2026-10-13)
- [hesela-observation] Hesela: three-run ext4 allocation observation, source hashes and environment. https://hesela.dev/research/allocation-observation.json (accessed 2026-10-16)

### USB mass storage

URL: https://hesela.dev/terms/usb-mass-storage/
Status: shipping

Record updated: 2026-10-15

The USB device class that presents block storage to hosts using BOT or UASP transports.

Note: Bulk-Only Transport and UAS are different command transports, not disk-health classifications. Linux compatibility flags can suppress selected commands or prevent UAS binding; a matching built-in rule can also depend on the USB device-revision range. Successful block reads do not imply that ATA SMART pass-through works. smartctl 7.5 documents that an unavailable SMART RETURN STATUS may reflect limitations or bugs in intermediate layers; its threshold-based fallback is not the missing drive-reported result. Preserve missing telemetry as unknown, not zero.

Limitations:
- Block I/O, health telemetry and write-durability guarantees must be checked separately.

Related terms:
- [uasp](https://hesela.dev/terms/uasp/)
- [consumer-ssd](https://hesela.dev/terms/consumer-ssd/)
- [sd-express](https://hesela.dev/terms/sd-express/)

Citations:
- [c1] USB mass storage. https://en.wikipedia.org/wiki/USB_mass_storage_device_class (accessed 2026-03-26)
- [uas-linux] Linux v6.12: UAS driver implementation. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/drivers/usb/storage/uas.c (accessed 2026-10-15)
- [usb-quirks] Linux v6.12: usb-storage.quirks. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/Documentation/admin-guide/kernel-parameters.txt (accessed 2026-10-15)
- [hesela-usb] USB storage resets: recovery is not a root-cause diagnosis. https://hesela.com/analyses/usb-sata-bridge-uas-failure-signatures/ (accessed 2026-10-15)
- [smartctl] smartctl 7.5: pass-through and health status. https://raw.githubusercontent.com/smartmontools/smartmontools/f276b249fdc84019403491303479485030ac7c80/smartmontools/smartctl.8.in (accessed 2026-10-15)
- [uas-matches] Linux v6.12: version-bounded UAS quirks. https://raw.githubusercontent.com/torvalds/linux/adc218676eef25575469234709c2d87185ca223a/drivers/usb/storage/unusual_uas.h (accessed 2026-10-15)

### V-NAND

URL: https://hesela.dev/terms/v-nand/
Status: shipping

Samsung's brand for its charge-trap 3D NAND vertical stacking architecture.

Related terms:
- [3d-nand](https://hesela.dev/terms/3d-nand/)
- [charge-trap-flash](https://hesela.dev/terms/charge-trap-flash/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] V-NAND. https://en.wikipedia.org/wiki/3D_NAND (accessed 2026-03-26)

### Value log

URL: https://hesela.dev/terms/value-log/
Also known as: vLog
Status: shipping

Record updated: 2026-10-12

A value log is an append-oriented record store whose values are located through a separate index.

Note: WiscKey includes keys and length fields in its log records; moving live records also changes their index references. A value log is not automatically a write-ahead log. [wisckey]

Related terms:
- [key-value-separation](https://hesela.dev/terms/key-value-separation/)
- [lsm-tree](https://hesela.dev/terms/lsm-tree/)
- [database-write-amplification](https://hesela.dev/terms/database-write-amplification/)

Citations:
- [wisckey] Lanyue Lu, Thanumalayan Sankaranarayana Pillai, Andrea C. Arpaci-Dusseau and Remzi H. Arpaci-Dusseau. WiscKey: Separating Keys from Values in SSD-conscious Storage. USENIX FAST 2016, pp. 133-148, sections 3.2-3.3 and 4.. https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf (accessed 2026-10-12)
- [hesela-kv] Key-value separation: the cleaning bill moves elsewhere. https://hesela.com/analyses/key-value-separation-cleaning-cost/ (accessed 2026-10-12)

### Volume manager

URL: https://hesela.dev/terms/volume-manager/
Status: shipping

Host or array software that groups physical drives into logical volumes and snapshots.

Related terms:
- [raid](https://hesela.dev/terms/raid/)
- [thin-provisioning](https://hesela.dev/terms/thin-provisioning/)
- [lvm](https://hesela.dev/terms/lvm/)

Citations:
- [c1] Volume manager. https://en.wikipedia.org/wiki/Logical_volume_management (accessed 2026-03-26)

### WAL archiving

URL: https://hesela.dev/terms/wal-archiving/
Also known as: continuous WAL archiving
Status: shipping

Record updated: 2026-10-14

WAL archiving preserves write-ahead-log segments for later recovery before normal log recycling can remove them.

Note: PostgreSQL 18 archives completed segments; low activity can delay archival. Local commit durability therefore does not by itself prove archive coverage. [pg-archive]

Limitations:
- A successful archive command must mean the file is safely preserved, not merely that copying was attempted. (sources: [pg-archive])
- archive_timeout schedules segment switches, not completed transfers; treating it alone as an end-to-end RPO bound is unjustified. This is Hesela's inference from the documented mechanism. (sources: [pg-timeout])
- last_archived_wal does not prove all earlier segments were archived: ordering is not guaranteed. Some failures that restart the archiver are not counted in pg_stat_archiver. (sources: [pg-stats], [pg-archive])

Related terms:
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)
- [recovery-target](https://hesela.dev/terms/recovery-target/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [backup-verification](https://hesela.dev/terms/backup-verification/)

Citations:
- [pg-archive] PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery. https://www.postgresql.org/docs/18/continuous-archiving.html (accessed 2026-10-14)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-14)
- [pg-timeout] PostgreSQL 18: archive_timeout. https://www.postgresql.org/docs/18/runtime-config-wal.html#GUC-ARCHIVE-TIMEOUT (accessed 2026-10-14)
- [pg-stats] PostgreSQL 18: pg_stat_archiver. https://www.postgresql.org/docs/18/monitoring-stats.html#PG-STAT-ARCHIVER-VIEW (accessed 2026-10-14)

### Warm storage tier

URL: https://hesela.dev/terms/warm-storage/
Status: shipping

Capacity-oriented online storage balancing cost and occasional access latency.

Related terms:
- [hot-warm-cold](https://hesela.dev/terms/hot-warm-cold/)
- [nearline-hdd](https://hesela.dev/terms/nearline-hdd/)

Citations:
- [c1] Warm storage tier. https://en.wikipedia.org/wiki/Information_lifecycle_management (accessed 2026-03-26)

### Wear leveling

URL: https://hesela.dev/terms/wear-leveling/
Also known as: wear levelling
Status: shipping

A flash management technique that spreads erase cycles across blocks so no single region wears out prematurely.

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [nand-flash](https://hesela.dev/terms/nand-flash/)
- [ssd](https://hesela.dev/terms/ssd/)
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [bad-block-management](https://hesela.dev/terms/bad-block-management/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [planar-nand](https://hesela.dev/terms/planar-nand/)

Citations:
- [c1] Wear leveling. https://en.wikipedia.org/wiki/Wear_leveling (accessed 2026-03-26)

### Winchester disk architecture

URL: https://hesela.dev/terms/winchester-architecture/
Also known as: Winchester technology, Winchester head
Status: eol

Record updated: 2026-10-11

Winchester disk architecture combines low-mass, lightly loaded flying heads with lubricated disks in a protected head-disk assembly; it does not require non-removable media.

Note: IBM's 1973 3340 used removable 3348 modules containing the disks, heads, carriage and spindle. Keeping each head with its recorded surface avoided the interchange alignment adjustments of conventional disk packs. The heads touched the disk at start and stop, not during normal recording. Mulvany's contemporary design paper describes a drive-operated sliding door and a filtered-air interface: protected packaging is not a claim of a permanently hermetic cartridge. Later fixed assemblies should not be projected backward onto the original removable module. The 2004 participants attributed the Winchester name to a proposed pair of 30 MB spindles, not the final 35/70 MB module capacities; that naming account is retrospective.

Advantages:
- Dedicated head/surface pairing reduced interchange alignment requirements while retaining removable modules. (sources: [mulvany1974])

Limitations:
- The historical name does not specify modern head geometry, interface, capacity or a hermetic seal. (sources: [mulvany1974])

Related terms:
- [hdd](https://hesela.dev/terms/hdd/)
- [ramac](https://hesela.dev/terms/ramac/)
- [defect-skipping](https://hesela.dev/terms/defect-skipping/)
- [count-key-data](https://hesela.dev/terms/count-key-data/)

Citations:
- [c1] Winchester disk architecture. https://en.wikipedia.org/wiki/Winchester_disk_drive (accessed 2026-03-26)
- [mulvany1974] R. B. Mulvany, Engineering Design of a Disk Storage Facility with Data Modules, IBM J. Res. Dev. 18(6), 489-505 (1974); pp. 489-494, 502-504. https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/IBM_Journal_of_Research_and_Development/186/ibmrd1806D.pdf (accessed 2026-10-11)
- [chm2004] IBM 3340 and 3350 oral-history panel, Computer History Museum, 6 April 2004, pp. 3-5 (participant recollections). https://archive.computerhistory.org/resources/text/Oral_History/IBM_3340_3350/3340_3350.oral_history.2004.102657933.pdf (accessed 2026-10-11)

### WORM storage

URL: https://hesela.dev/terms/worm-storage/
Also known as: Write once read many
Status: shipping

Record updated: 2026-10-15

Write-once-read-many storage preserves recorded content against subsequent alteration while allowing repeated reads.

Note: WORM describes preservation of fixed content, not one medium or a certification by itself. [snia] A recovery review must still identify the protected data, retention scope and required dependencies; the companion analysis separates preservation from successful restoration. [hesela-backup-evidence]

Advantages:
- Preserves recorded fixed content without permitting later alteration. (sources: [snia])

Limitations:
- A WORM label does not specify storage-service bypass rights or guarantee usable encryption keys. (sources: [manage])

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [lto](https://hesela.dev/terms/lto/)
- [air-gap-backup](https://hesela.dev/terms/air-gap-backup/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [object-lock](https://hesela.dev/terms/object-lock/)
- [legal-hold](https://hesela.dev/terms/legal-hold/)

Citations:
- [c1] WORM storage. https://en.wikipedia.org/wiki/Write_once_read_many (accessed 2026-03-26)
- [snia] SNIA Dictionary: Write Once Read Many. https://www.snia.org/education/online-dictionary/term/write-once-read-many (accessed 2026-10-15)
- [manage] Amazon S3: Object Lock considerations. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html (accessed 2026-10-15)
- [hesela-backup-evidence] Hesela: Backup verification is not a restore test. https://hesela.com/analyses/backup-verification-is-not-a-restore-test/ (accessed 2026-10-15)

### Write-ahead log

URL: https://hesela.dev/terms/write-ahead-log/
Also known as: WAL
Status: shipping

Record updated: 2026-10-16

A write-ahead log is a recovery log whose relevant records must become durable before the corresponding changes are persisted in database data files.

Note: Write-ahead logging names the ordering protocol; the write-ahead log is its record stream. PostgreSQL can replay logged changes after a crash, so committing a transaction need not flush every modified data page. A record in a memory buffer is not yet a durable record. Preserving older WAL for point-in-time recovery is a separate archive-retention task. [pg-archive] SQLite's alternative rollback journal stores before-images; its WAL-mode atomicity applies per database, not to a multi-file ATTACH transaction as a set. [sqlite-attach] Replication-slot retention serves a consumer's catch-up needs; it does not replace a separately preserved recovery archive. [pg-slots]

Advantages:
- Allows changed data pages to be written later while preserving logged recovery information. (sources: [pg-intro])

Limitations:
- Recovery still depends on storage honoring synchronization requests. (sources: [pg-reliability])

Related terms:
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)
- [full-page-write](https://hesela.dev/terms/full-page-write/)
- [fsync](https://hesela.dev/terms/fsync/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)
- [point-in-time-recovery](https://hesela.dev/terms/point-in-time-recovery/)
- [wal-archiving](https://hesela.dev/terms/wal-archiving/)
- [rollback-journal](https://hesela.dev/terms/rollback-journal/)
- [sqlite-super-journal](https://hesela.dev/terms/sqlite-super-journal/)
- [checkpoint-starvation](https://hesela.dev/terms/checkpoint-starvation/)
- [sqlite-wal-end-mark](https://hesela.dev/terms/sqlite-wal-end-mark/)
- [rocksdb-column-family](https://hesela.dev/terms/rocksdb-column-family/)
- [rocksdb-atomic-flush](https://hesela.dev/terms/rocksdb-atomic-flush/)
- [group-commit](https://hesela.dev/terms/group-commit/)
- [asynchronous-commit](https://hesela.dev/terms/asynchronous-commit/)
- [replication-slot](https://hesela.dev/terms/replication-slot/)
- [logical-decoding](https://hesela.dev/terms/logical-decoding/)

Citations:
- [pg-intro] PostgreSQL 18: Write-Ahead Logging. https://www.postgresql.org/docs/18/wal-intro.html (accessed 2026-10-11)
- [pg-reliability] PostgreSQL 18: Reliability. https://www.postgresql.org/docs/18/wal-reliability.html (accessed 2026-10-11)
- [hesela-wal] WAL, checkpoints and torn pages: three different recovery guarantees. https://hesela.com/analyses/wal-checkpoints-torn-pages/ (accessed 2026-10-11)
- [pg-archive] PostgreSQL 18: Continuous Archiving and Point-in-Time Recovery. https://www.postgresql.org/docs/18/continuous-archiving.html (accessed 2026-10-14)
- [sqlite-attach] SQLite: ATTACH DATABASE, atomicity across files. https://sqlite.org/lang_attach.html (accessed 2026-10-14)
- [pg-slots] PostgreSQL 18: replication slots and WAL retention. https://www.postgresql.org/docs/18/warm-standby.html#STREAMING-REPLICATION-SLOTS (accessed 2026-10-16)

### Write amplification

URL: https://hesela.dev/terms/write-amplification/
Also known as: WA, WAF, write amplification factor
Status: shipping

Record updated: 2026-10-12

Device-level byte write amplification is the ratio of bytes programmed to the storage medium to bytes written by the host over the same accounting interval.

Note: State the measurement boundary and whether the numerator includes metadata, parity and other internal writes. Operation-count and byte-count ratios are not interchangeable when write sizes differ. Copyback can reduce relocation traffic without changing programmed bytes. Database output/logical input is a separate accounting boundary; see database-write-amplification. If host-written bytes are zero, the interval ratio is undefined, including 0/0. Read reclaim can still program NAND; preserve physical-program deltas and elapsed time instead of replacing the undefined ratio with zero.

Limitations:
- A traffic reduction or a latency improvement does not by itself measure this ratio. (sources: [hesela-copyback])

Related terms:
- [ftl](https://hesela.dev/terms/ftl/)
- [garbage-collection](https://hesela.dev/terms/garbage-collection/)
- [qlc](https://hesela.dev/terms/qlc/)
- [trim](https://hesela.dev/terms/trim/)
- [channel-nand](https://hesela.dev/terms/channel-nand/)
- [nand-copyback](https://hesela.dev/terms/nand-copyback/)
- [read-modify-write](https://hesela.dev/terms/read-modify-write/)
- [database-write-amplification](https://hesela.dev/terms/database-write-amplification/)
- [read-reclaim](https://hesela.dev/terms/read-reclaim/)

Citations:
- [c1] Write amplification. https://en.wikipedia.org/wiki/Write_amplification (accessed 2026-03-26)
- [snia-bytes] Steve Peters, LSI. What Can/Can't be Done and What's Nice to Have in the New Stack. SNIA-hosted presentation, slide 11: Write Amplification.. https://www.snia.org/sites/default/files/NVM13-Peters_NVM_programming.pdf (accessed 2026-10-11)
- [snia-ops] SNIA dictionary: write amplification factor (operation-count convention). https://www.snia.org/education/online-dictionary/term/write-amplification-factor (accessed 2026-10-11)
- [hesela-copyback] Hesela: NAND copyback, faster relocation is not fewer writes. https://hesela.com/analyses/nand-copyback-ecc-boundary/ (accessed 2026-10-11)
- [hesela-reclaim] Hesela: SSD read reclaim and read-only accounting. https://hesela.com/analyses/ssd-read-reclaim-hidden-writes/ (accessed 2026-10-12)

### Write-back cache

URL: https://hesela.dev/terms/write-back-cache/
Status: shipping

Record updated: 2026-10-12

Write-back caching completes a write after updating the cache and defers updating its backing store until later.

Note: Write completion and durable commit are separate boundaries. Linux buffers modified file data and writes it back later; applications use synchronization and must handle writeback errors. A cache read alone is not proof of persistence. Device-level protection does not replace the application's own commit protocol. Write-back describes an update policy, not whether the cache is volatile: a persistent cache can precede the backing store. Linux dm-cache marks cached write-back updates dirty relative to the origin. Flush and FUA requests carry separate persistence requirements through the block stack.

Related terms:
- [write-through-cache](https://hesela.dev/terms/write-through-cache/)
- [ssd](https://hesela.dev/terms/ssd/)
- [fsync](https://hesela.dev/terms/fsync/)
- [writeback-error](https://hesela.dev/terms/writeback-error/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [cache-flush](https://hesela.dev/terms/cache-flush/)
- [force-unit-access](https://hesela.dev/terms/force-unit-access/)

Citations:
- [linux-vfs] Linux VFS: Handling errors during writeback. https://www.kernel.org/doc/html/latest/filesystems/vfs.html#handling-errors-during-writeback (accessed 2026-10-10)
- [sqlite-atomic] SQLite: Atomic Commit. https://www.sqlite.org/atomiccommit.html (accessed 2026-10-10)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-10)
- [linux-cache] Linux kernel documentation. Explicit volatile write back cache control: REQ_PREFLUSH and REQ_FUA.. https://docs.kernel.org/block/writeback_cache_control.html (accessed 2026-10-12)
- [dm-cache] Linux kernel documentation. Device-mapper cache: operating modes and on-disk metadata.. https://docs.kernel.org/admin-guide/device-mapper/cache.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)

### Write combining

URL: https://hesela.dev/terms/write-combining/
Status: shipping

Merging adjacent small writes into fewer large operations to reduce amplification on flash or SMR.

Related terms:
- [write-amplification](https://hesela.dev/terms/write-amplification/)
- [smr](https://hesela.dev/terms/smr/)
- [ssd](https://hesela.dev/terms/ssd/)

Citations:
- [c1] Write combining. https://en.wikipedia.org/wiki/Write_amplification (accessed 2026-03-26)

### Write-intent bitmap

URL: https://hesela.dev/terms/write-intent-bitmap/
Also known as: RAID bitmap
Status: shipping

A write-intent bitmap tracks regions of a redundant array that may need synchronization after interrupted writes.

Note: A bit identifies a region, not the old or new user data needed to replay its update.

Advantages:
- Tracks potentially unsynchronized regions so recovery can avoid scanning every region. (sources: [md])

Limitations:
- A bitmap is not a data journal or an independent copy of missing contents. (sources: [md], [journal])

Related terms:
- [raid-write-hole](https://hesela.dev/terms/raid-write-hole/)
- [partial-parity-log](https://hesela.dev/terms/partial-parity-log/)
- [raid-5](https://hesela.dev/terms/raid-5/)
- [mirroring](https://hesela.dev/terms/mirroring/)

Citations:
- [md] Linux v6.12: RAID arrays, dirty/degraded assembly and bitmap metadata. https://github.com/torvalds/linux/blob/v6.12/Documentation/admin-guide/md.rst (accessed 2026-10-11)
- [journal] Linux v6.12: RAID 4/5/6 cache. https://github.com/torvalds/linux/blob/v6.12/Documentation/driver-api/md/raid5-cache.rst (accessed 2026-10-11)
- [hesela-raid] Hesela: RAID write hole, bitmap and PPL. https://hesela.com/analyses/raid-write-hole-bitmap-ppl/ (accessed 2026-10-11)

### Write-once media

URL: https://hesela.dev/terms/write-once-media/
Also known as: WORM media, write once read many media
Status: shipping

Recorded firstSeen: 1984-04 (sources: [c4])

Storage that physically or logically prevents rewriting committed regions.

Note: Write-once media are storage media whose recording step cannot be undone, so a committed region can be read any number of times but never overwritten. In optical form the recording step is typically a laser heating a thin film so that it melts or ablates into a non-reflective mark (course notes on optical disks; the SEC's 1997 rule release describes WORM optical storage as a laser heat source burning a pattern on a metallic film), and the SEC release lists alloying, bubble-forming, moth-eye (Plasmon), phase-change, dye/polymer and magneto-optic methods as other write-once approaches. Dated milestones from sources opened: an Optimem (division of Shugart) paper at the April 1984 Optical Data Storage meeting describes the Optimem 1000 as a write-once drive of 1 GB per surface; the IBM 3363 Optical Disk Drive was announced on 2 April 1987 for IBM PCs and PS/2 systems, with a 130 mm (5.25-inch) removable write-once cartridge of 200 MB (vendor claim), a spiral format of 512-byte sectors, 23 sectors per track and 17,100 tracks (about 201 million bytes by arithmetic on those figures), and IBM-stated average seek under 230 ms across one-third of the disk (vendor claim); Computer History Museum catalogues 3363 units made in February and November 1987. IBM's DOS file driver made the drive appear rewritable by keeping earlier versions of a file, which IBM described as an automatic audit trail (vendor claim). A 1990 trade report credited Information Storage Inc. (ISI) as a pioneer of WORM drives, with 1.28 GB on a 5.25-inch disk, and said the 5.25-inch WORM market never really took off and was slowed by erasable magneto-optical units (the newsletter's opinion). A May 1991 trade report said IBM was replacing 12-inch WORM optical disks and jukeboxes in its ImagePlus catalogue with 5.25-inch media in the 3995 Optical Library Dataservers, at 610 MB per cartridge over both sides, because smaller disks turn faster and have many suppliers (IBM executive's explanation); the new products were not due before June 1992. CD-R carried the model to the compact disc: Taiyo Yuden's Takashi Ishiguro, who developed it, dates the first working recording to 13 June 1988 and describes a polycarbonate disc with a pre-molded guide groove, an organic dye layer, a gold or silver reflector and a protective coat, where the recording laser forms marks by dye decomposition plus substrate deformation, and he gives capacity as growing from 530 MB (63 min) to the standard's 700 MB (80 min) limit. CD-R is specified in Part II of the Orange Book by Philips and Sony and was first called CD-WO; Ishiguro says standardisation with Philips and Sony followed in 1989, while a Philips paper abstract says the first Orange Book draft was published in November 1990, so the sources disagree on the standardisation date and this record does not resolve it. Regulation was a documented driver in the United States: the Securities Industry Association asked the SEC staff in 1991 to allow electronic storage and in May 1992 asked for a no-action position on optical disk with WORM safeguards; the staff issued a no-action letter on 18 June 1993 and the SEC proposed a rule on 9 July 1993. The SEC adopted amendments to Rule 17a-4(f) in February 1997 (Federal Register 12 February 1997, effective 14 April 1997; a 2022 SEC release cites the adopting release as dated 31 January 1997), requiring broker-dealers using electronic storage media to preserve records exclusively in a non-rewriteable, non-erasable format, verify recording automatically, serialize and time-date media, index and duplicate records, and use a third-party download undertaking, while explicitly not limiting the media to optical disk (optical tape and WORM CD-ROM were named). A 2001 SEC interpretation found those requirements consistent with the E-SIGN Act, and per the 2022 release a 2003 interpretation clarified that WORM does not mandate optical disks. Amendments adopted on 12 October 2022 (effective 3 January 2023, compliance date 3 May 2023) kept WORM as an option and added an audit-trail alternative that must permit re-creation of an original record if it is modified or deleted. This record covers only SEC Rule 17a-4 and does not describe other regulators' rules.

Advantages:
- Committed data cannot be altered by later writes, which the SEC accepted as an integrity safeguard: its 1997 amendment to Rule 17a-4(f) required electronic storage media to preserve records exclusively in a non-rewriteable, non-erasable format. (sources: [c11], [c12])
- Removable cartridges let the written volume be stored away from the drive; IBM positioned the 3363 for security, archive and backup uses where removability matters (vendor claim). (sources: [c2])
- CD-R was designed so that discs written to the Orange Book play in CD players made before CD-R existed, per its developer (vendor claim). (sources: [c8])
- The IBM 3363 file driver kept earlier versions of a file, which IBM said gave users an automatic audit trail and archive (vendor claim). (sources: [c2])

Limitations:
- Written regions cannot be erased or rewritten, so file systems must append: the IBM 3363 driver made the drive appear rewritable only by keeping old versions, and CD-R discs are written in sessions and can be finalised so that no further writes are accepted. (sources: [c2], [c9])
- Defects on write-once media show up only when data is written: course notes describe direct-read-after-write, with a block that fails verification rewritten in the next block, and give bit error rates of about 10^-6 for optical media versus 10^-8 for magnetic media in the mid-1990s (single source, course notes). The SEC rule likewise required automatic verification of the recording process. (sources: [c7], [c11])
- Capacity per disc is bounded by the standard: CD-R grew only from 530 MB (63 min) at its start to the Orange Book limit of 700 MB (80 min), per its developer (vendor claim); 5.25-inch WORM drives were reported in 1990 to have been slowed by erasable magneto-optical units (trade-press opinion). (sources: [c8], [c5])
- Media formats were fragmented: IBM moved its ImagePlus optical offering from 12-inch to 5.25-inch WORM media in 1991, with different cartridge capacities per generation. (sources: [c6], [c2])
- WORM is no longer the only way to meet SEC Rule 17a-4 for electronic records: the October 2022 amendments added an audit-trail alternative, effective 3 January 2023 with compliance on 3 May 2023. (sources: [c13], [c14])

Related terms:
- [worm-storage](https://hesela.dev/terms/worm-storage/)
- [optical-archival](https://hesela.dev/terms/optical-archival/)
- [immutability-storage](https://hesela.dev/terms/immutability-storage/)
- [optical-jukebox](https://hesela.dev/terms/optical-jukebox/)
- [magneto-optical](https://hesela.dev/terms/magneto-optical/)
- [tape](https://hesela.dev/terms/tape/)

Citations:
- [c1] Write-once media. https://en.wikipedia.org/wiki/Write_once_read_many (accessed 2026-03-26)
- [c2] IBM Announcement Letter 187-064: IBM 3363 Optical Disk Drive (2 April 1987; mirror). http://ardent-tool.com/storage/187-064.txt (accessed 2026-10-12)
- [c3] IBM 3363 optical WORM drive, catalogue 102671161 (Computer History Museum). https://www.computerhistory.org/collections/catalog/102671161 (accessed 2026-10-12)
- [c4] The Optimem 1000 Optical Disk Drive, G. R. Knight, Optical Data Storage 1984 (abstract). https://opg.optica.org/abstract.cfm?uri=ODS-1984-WCA4 (accessed 2026-10-12)
- [c5] History (1990): New International Consortium in Optical Disks, StorageNewsletter. https://www.storagenewsletter.com/2019/11/20/history-1990-new-international-consortium-in-optical-disks/ (accessed 2026-10-12)
- [c6] History (1991): IBM Gives Up 12-Inch Optical Discs for 5.25-Inch Media, StorageNewsletter. https://www.storagenewsletter.com/2020/02/12/history-1991-ibm-gives-up-12-inch-optical-discs-for-5-25-inch-media/ (accessed 2026-10-12)
- [c7] Chapter 12. Optical Disks, Computer Peripherals course notes (Nanyang Technological University). https://lintech.org/comp-per/12OPDISK.pdf (accessed 2026-10-12)
- [c8] CD-R development story, T. Ishiguro, Taiyo Yuden, Oyo Buturi 81(8), 2012 (Japanese). https://www.jstage.jst.go.jp/article/oubutsu/81/8/81_667/_pdf (accessed 2026-10-12)
- [c9] CD-R (Wikipedia). https://en.wikipedia.org/wiki/CD-R (accessed 2026-10-12)
- [c10] CD-R and the compatibility with CD, Heemskerk and Kablau, Optical Data Storage 1994 (abstract). https://exa.ai/library/publication/pp74919hsn7 (accessed 2026-10-12)
- [c11] SEC Release 34-38245, Federal Register 62 FR 6469 (12 Feb 1997). https://www.govinfo.gov/content/pkg/FR-1997-02-12/html/97-3426.htm (accessed 2026-10-12)
- [c12] SEC Release 34-44238: Guidance on electronic storage media and Rule 17a-4(f) (1 May 2001). https://www.sec.gov/rules-regulations/2001/05/commission-guidance-broker-dealers-use-electronic-storage-media-under-electronic-signatures-global (accessed 2026-10-12)
- [c13] SEC: Amendments to Electronic Recordkeeping Requirements for Broker-Dealers (small entity compliance guide, 28 Feb 2023). https://www.sec.gov/investment/amendments-electronic-recordkeeping-requirements-broker-dealers (accessed 2026-10-12)
- [c14] SEC Release 34-96034: Electronic Recordkeeping Requirements for Broker-Dealers (12 Oct 2022). https://www.sec.gov/files/rules/final/2022/34-96034.pdf (accessed 2026-10-12)

### Write quorum

URL: https://hesela.dev/terms/write-quorum/
Also known as: Write acknowledgement threshold
Status: shipping

Record updated: 2026-10-13

A write quorum is a protocol-approved set of replicas whose acknowledgements satisfy the requirement for completing a write.

Note: W is the acknowledgement threshold, not the number of destinations. Cassandra sends writes to all replicas, then waits for the configured consistency level. [cassandra] An acknowledgement's persistence meaning is a separate contract. [guarantees]

Limitations:
- A write timeout does not establish that no replica applied the mutation. (sources: [guarantees])

Related terms:
- [read-quorum](https://hesela.dev/terms/read-quorum/)
- [quorum-intersection](https://hesela.dev/terms/quorum-intersection/)

Citations:
- [cassandra] Apache Cassandra 5.0.0: Dynamo architecture, tunable consistency and data versioning.. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/architecture/dynamo.adoc (accessed 2026-10-13)
- [guarantees] Apache Cassandra 5.0.0: Guarantees, including lightweight transactions.. https://raw.githubusercontent.com/apache/cassandra/cassandra-5.0.0/doc/modules/cassandra/pages/architecture/guarantees.adoc (accessed 2026-10-13)
- [hesela-repair] Replica repair: what has actually converged?. https://hesela.com/analyses/replica-repair-coverage/ (accessed 2026-10-13)

### Write skew

URL: https://hesela.dev/terms/write-skew/
Status: shipping

Record updated: 2026-10-12

Write skew is a concurrency anomaly in which transactions read overlapping data and make disjoint writes whose combined outcome can violate an invariant that each transaction would preserve alone.

Note: It is possible under snapshot isolation without a same-row write conflict. Checking only the versions of the rows being written does not validate every cross-row read dependency.

Related terms:
- [snapshot-isolation](https://hesela.dev/terms/snapshot-isolation/)
- [serializability](https://hesela.dev/terms/serializability/)

Citations:
- [berenson-isolation] Hal Berenson et al. A Critique of ANSI SQL Isolation Levels. ACM SIGMOD 1995; MSR-TR-95-51, section 4.2.. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf (accessed 2026-10-12)
- [ports-ssi] Dan R. K. Ports and Kevin Grittner. Serializable Snapshot Isolation in PostgreSQL. PVLDB 5(12), 1850-1861, 2012, sections 2 and 4. arXiv:1208.4179v1.. https://arxiv.org/abs/1208.4179v1 (accessed 2026-10-12)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-12)

### Write-through cache

URL: https://hesela.dev/terms/write-through-cache/
Status: shipping

Record updated: 2026-10-12

Write-through caching propagates writes to the backing store as part of completing them at the cache layer.

Note: The guarantee is relative to that layer. Linux dm-cache write-through completes a cached write after both cache and origin devices have been updated, but lower layers can still contain volatile write caches. REQ_PREFLUSH and REQ_FUA address separate persistence requirements; write-through alone is not an end-to-end power-loss guarantee or an application transaction protocol.

Limitations:
- Backing-device completion must not be confused with persistence when lower-layer volatile caches are present. (sources: [dm-cache], [linux-cache])

Related terms:
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [direct-io](https://hesela.dev/terms/direct-io/)
- [cache-flush](https://hesela.dev/terms/cache-flush/)
- [force-unit-access](https://hesela.dev/terms/force-unit-access/)

Citations:
- [linux-cache] Linux kernel documentation. Explicit volatile write back cache control: REQ_PREFLUSH and REQ_FUA.. https://docs.kernel.org/block/writeback_cache_control.html (accessed 2026-10-12)
- [dm-cache] Linux kernel documentation. Device-mapper cache: operating modes and on-disk metadata.. https://docs.kernel.org/admin-guide/device-mapper/cache.html (accessed 2026-10-12)
- [hesela-stability] NFS stable writes: what COMMIT, flush and FUA actually promise. https://hesela.com/analyses/nfs-stable-writes-flush-fua/ (accessed 2026-10-12)

### Writeback error

URL: https://hesela.dev/terms/writeback-error/
Status: shipping

Record updated: 2026-10-15

A writeback error is a failure encountered while transferring modified cached data to its backing storage.

Note: Linux's generic tracking can report a failure to open file descriptions for the affected file even when their own writes did not fail. Duplicated descriptors share an open-file-description error cursor, so observing through one alias can consume the shared pending report. An error report neither identifies every damaged byte nor repairs data. Preserve the first failure when assessing transaction durability. syncfs broadens reporting to the filesystem selected by the descriptor; its error need not concern that descriptor's file. [sync-api]

Related terms:
- [fsync](https://hesela.dev/terms/fsync/)
- [errseq-t](https://hesela.dev/terms/errseq-t/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [fdatasync](https://hesela.dev/terms/fdatasync/)
- [sync-file-range](https://hesela.dev/terms/sync-file-range/)
- [open-file-description](https://hesela.dev/terms/open-file-description/)
- [syncfs](https://hesela.dev/terms/syncfs/)

Citations:
- [linux-vfs] Linux VFS: Handling errors during writeback. https://www.kernel.org/doc/html/latest/filesystems/vfs.html#handling-errors-during-writeback (accessed 2026-10-13)
- [hesela-fsync] Hesela: Why retrying a failed fsync does not prove durability. https://hesela.com/analyses/fsync-failure-retry-durability/ (accessed 2026-10-10)
- [dup-api] Linux man-pages 6.19: dup(2), shared open file descriptions. https://man7.org/linux/man-pages/man2/dup.2.html (accessed 2026-10-13)
- [filemap-source] Linux v6.12: file_check_and_advance_wb_err in mm/filemap.c. https://github.com/torvalds/linux/blob/v6.12/mm/filemap.c (accessed 2026-10-13)
- [sync-api] Linux man-pages 6.19: sync(2), filesystem scope and Linux 5.8 error reporting. https://man7.org/linux/man-pages/man2/sync.2.html (accessed 2026-10-15)

### Writes-follow-reads

URL: https://hesela.dev/terms/writes-follow-reads/
Also known as: Writes follow reads, WFR session guarantee
Status: shipping

Record updated: 2026-10-13

Writes-follow-reads requires every replica incorporating a session write to incorporate and order before it the updates relevant to that session's earlier reads.

Note: The dependency may originate in another session. For MongoDB, cross-session causal transfer uses operation time and cluster time; simply starting another client session does not carry that context. A causally consistent session does not isolate its operations from concurrent clients. Terry et al. section 3.3 separates ordering-only and propagation-only variants; neither alone is the full guarantee. The companion article provides an executable two-write example, not an implementation conformance test.

Related terms:
- [session-guarantees](https://hesela.dev/terms/session-guarantees/)
- [monotonic-writes](https://hesela.dev/terms/monotonic-writes/)

Citations:
- [session-guarantees] Douglas B. Terry et al. Session Guarantees for Weakly Consistent Replicated Data. PDIS 1994, sections 3.1-3.4, pp. 142-144.. https://classes.cs.uchicago.edu/archive/2026/spring/23380-1/papers/terry_sessionguarantees.pdf (accessed 2026-10-13)
- [mongodb-sessions] MongoDB Manual: Read Isolation, Consistency, and Recency; client sessions, causal guarantees and isolation.. https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency/ (accessed 2026-10-13)
- [hesela-consistency] Storage consistency: ordering is not a transaction or a durability promise. https://hesela.com/analyses/storage-consistency-ordering/ (accessed 2026-10-13)

### XFS Active Item List

URL: https://hesela.dev/terms/xfs-ail/
Also known as: XFS AIL
Status: shipping

Record updated: 2026-10-16

The XFS Active Item List tracks logged items whose journal records remain needed until later retirement.

Note: An item can be relogged while active; AIL and CIL tracking are separate. [design] Journal persistence and home-location writeback are distinct boundaries. [hesela-xfs] Linux v6.16 orders active items by LSN and moves relogged items forward only for a newer LSN; moving an oldest item can advance the minimum without retiring that item. [ail-code]

Related terms:
- [xfs-cil](https://hesela.dev/terms/xfs-cil/)
- [xfs-delayed-logging](https://hesela.dev/terms/xfs-delayed-logging/)
- [journal-checkpoint](https://hesela.dev/terms/journal-checkpoint/)
- [xfs-relogging](https://hesela.dev/terms/xfs-relogging/)
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)

Citations:
- [design] Linux v6.16: XFS Logging Design, asynchronous transactions, checkpoints and item lifecycle. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-15)
- [code] Linux v6.16: xfs_log_cil.c, per-CPU insertion, aggregation and asynchronous flush. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/xfs_log_cil.c (accessed 2026-10-15)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-15)
- [ail-code] Linux v6.16: xfs_trans_ail.c, ordered item movement and log-tail updates. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/xfs_trans_ail.c (accessed 2026-10-16)

### XFS Committed Item List

URL: https://hesela.dev/terms/xfs-cil/
Also known as: XFS CIL
Status: shipping

Record updated: 2026-10-15

The XFS Committed Item List tracks in-memory logged changes awaiting a journal checkpoint.

Note: CIL membership does not certify durable storage. [design] Linux v6.16 inserts items into per-CPU lists and aggregates them during a push. [code]

Related terms:
- [xfs-delayed-logging](https://hesela.dev/terms/xfs-delayed-logging/)
- [xfs-ail](https://hesela.dev/terms/xfs-ail/)

Citations:
- [design] Linux v6.16: XFS Logging Design, asynchronous transactions, checkpoints and item lifecycle. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-15)
- [code] Linux v6.16: xfs_log_cil.c, per-CPU insertion, aggregation and asynchronous flush. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/xfs_log_cil.c (accessed 2026-10-15)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-15)

### XFS deferred operation

URL: https://hesela.dev/terms/xfs-deferred-operation/
Also known as: XFS deferred work
Status: shipping

Record updated: 2026-10-16

An XFS deferred operation postpones metadata work to a later transaction to satisfy locking or reservation constraints.

Note: This is distinct from delayed logging's journal batching. [design] Recoverable work uses intent/done records; continuation can split one logical operation across transactions. [defer-code]

Related terms:
- [xfs-rolling-transaction](https://hesela.dev/terms/xfs-rolling-transaction/)
- [xfs-intent-log-item](https://hesela.dev/terms/xfs-intent-log-item/)
- [xfs-delayed-logging](https://hesela.dev/terms/xfs-delayed-logging/)

Citations:
- [design] Linux v6.16: XFS Logging Design, log space accounting and re-logging. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-16)
- [defer-code] Linux v6.16: xfs_defer.c, deferred operations and atomic intent continuation. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/libxfs/xfs_defer.c (accessed 2026-10-16)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-16)

### XFS delayed logging

URL: https://hesela.dev/terms/xfs-delayed-logging/
Status: shipping

Record updated: 2026-10-16

XFS delayed logging aggregates metadata changes in memory before committing them to the filesystem journal.

Note: Do not equate an in-memory commit with persistence. [design] The cited v6.16 source and FAST 2022 baseline are different versions; see the scoped review. [paper] [hesela-xfs]

Related terms:
- [xfs-cil](https://hesela.dev/terms/xfs-cil/)
- [xfs-ail](https://hesela.dev/terms/xfs-ail/)
- [journal-checkpoint](https://hesela.dev/terms/journal-checkpoint/)
- [logical-journaling](https://hesela.dev/terms/logical-journaling/)
- [xfs-relogging](https://hesela.dev/terms/xfs-relogging/)
- [xfs-deferred-operation](https://hesela.dev/terms/xfs-deferred-operation/)

Citations:
- [design] Linux v6.16: XFS Logging Design, asynchronous transactions, checkpoints and item lifecycle. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-15)
- [code] Linux v6.16: xfs_log_cil.c, per-CPU insertion, aggregation and asynchronous flush. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/xfs_log_cil.c (accessed 2026-10-15)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-15)
- [paper] Kim, Min, Oh and Won. ScaleXFS: Getting scalability of XFS back on the ring. FAST 2022, pp. 329-344.. https://www.usenix.org/system/files/fast22-kim.pdf (accessed 2026-10-16)

### XFS intent log item

URL: https://hesela.dev/terms/xfs-intent-log-item/
Also known as: XFS log intent
Status: shipping

Record updated: 2026-10-16

An XFS intent log item describes deferred work that log recovery may need to complete.

Note: A matching done item suppresses replay of that intent. A continuation records done plus a replacement intent in the same transaction, so done need not end the logical operation. [defer-code] Neither record alone acknowledges application durability. [hesela-xfs]

Related terms:
- [xfs-deferred-operation](https://hesela.dev/terms/xfs-deferred-operation/)
- [xfs-rolling-transaction](https://hesela.dev/terms/xfs-rolling-transaction/)
- [xfs-relogging](https://hesela.dev/terms/xfs-relogging/)

Citations:
- [defer-code] Linux v6.16: xfs_defer.c, deferred operations and atomic intent continuation. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/libxfs/xfs_defer.c (accessed 2026-10-16)
- [online-fsck] Linux v6.16: XFS Online Fsck Design, transaction chains and intent drains. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-online-fsck-design.rst (accessed 2026-10-16)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-16)

### XFS relogging

URL: https://hesela.dev/terms/xfs-relogging/
Also known as: XFS re-logging
Status: shipping

Record updated: 2026-10-16

XFS relogging records an object's outstanding metadata changes again in a newer transaction.

Note: Rolling transactions relog held items so they do not obstruct their own log-space progress. [design] Relogging is not home writeback and is not an application durability barrier. [hesela-xfs]

Related terms:
- [xfs-delayed-logging](https://hesela.dev/terms/xfs-delayed-logging/)
- [xfs-cil](https://hesela.dev/terms/xfs-cil/)
- [xfs-ail](https://hesela.dev/terms/xfs-ail/)
- [log-sequence-number](https://hesela.dev/terms/log-sequence-number/)
- [xfs-rolling-transaction](https://hesela.dev/terms/xfs-rolling-transaction/)
- [xfs-intent-log-item](https://hesela.dev/terms/xfs-intent-log-item/)

Citations:
- [design] Linux v6.16: XFS Logging Design, log space accounting and re-logging. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-16)
- [ail-code] Linux v6.16: xfs_trans_ail.c, ordered item movement and log-tail updates. https://github.com/torvalds/linux/blob/v6.16/fs/xfs/xfs_trans_ail.c (accessed 2026-10-16)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-16)

### XFS rolling transaction

URL: https://hesela.dev/terms/xfs-rolling-transaction/
Also known as: XFS transaction rolling
Status: shipping

Record updated: 2026-10-16

An XFS rolling transaction commits one step of a transaction chain and continues with a fresh transaction using a permanent log reservation.

Note: An inode lock can conceal intermediate changes from callers needing that lock, but the journal chain is not atomic. [design] Allocation-group observers have different locking boundaries. [online-fsck]

Related terms:
- [xfs-relogging](https://hesela.dev/terms/xfs-relogging/)
- [xfs-deferred-operation](https://hesela.dev/terms/xfs-deferred-operation/)
- [xfs-intent-log-item](https://hesela.dev/terms/xfs-intent-log-item/)

Citations:
- [design] Linux v6.16: XFS Logging Design, log space accounting and re-logging. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-delayed-logging-design.rst (accessed 2026-10-16)
- [online-fsck] Linux v6.16: XFS Online Fsck Design, transaction chains and intent drains. https://github.com/torvalds/linux/blob/v6.16/Documentation/filesystems/xfs/xfs-online-fsck-design.rst (accessed 2026-10-16)
- [hesela-xfs] Hesela: XFS delayed logging and commit boundaries. https://hesela.com/analyses/xfs-delayed-logging-commit-boundaries/ (accessed 2026-10-16)

### XTS-AES

URL: https://hesela.dev/terms/xts-aes/
Also known as: AES-XTS
Status: shipping

Record updated: 2026-10-15

XTS-AES is a tweakable AES encryption mode for storage data units that provides confidentiality without authenticating the data or its source.

Note: XTS preserves data length rather than appending an authentication tag. Decryption success is not a tamper-detection result. [nist-xts] This record uses the 2010 final SP 800-38E; the NIST publication record listed Revision 1 as an initial public draft on 15 October 2026, not a replacement final standard. [nist-status]

Limitations:
- XTS-AES alone does not establish that stored content is authentic or current. (sources: [nist-xts])

Related terms:
- [dm-crypt](https://hesela.dev/terms/dm-crypt/)
- [luks](https://hesela.dev/terms/luks/)
- [authenticated-encryption](https://hesela.dev/terms/authenticated-encryption/)
- [checksum](https://hesela.dev/terms/checksum/)

Citations:
- [nist-xts] NIST SP 800-38E (2010): XTS-AES confidentiality and authentication boundary, section 3. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38e.pdf (accessed 2026-10-15)
- [nist-status] NIST SP 800-38E publication record and revision planning note. https://csrc.nist.gov/pubs/sp/800/38/e/final (accessed 2026-10-15)
- [hesela-encryption] Hesela: Encryption is not authentication. https://hesela.com/analyses/checksums-identity-and-lost-writes/#encryption-boundaries (accessed 2026-10-15)

### ZAC

URL: https://hesela.dev/terms/zac/
Status: limited

Zoned ATA Commands are the SATA counterpart to ZBC for host-managed SMR HDDs.

Related terms:
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [smr](https://hesela.dev/terms/smr/)
- [zoned-block-device](https://hesela.dev/terms/zoned-block-device/)

Citations:
- [c1] ZAC. https://en.wikipedia.org/wiki/Zoned_block_device (accessed 2026-03-26)

### ZBC

URL: https://hesela.dev/terms/zbc/
Status: limited

Zoned Block Commands standardize host-managed SMR access for SCSI/SATA devices.

Related terms:
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [smr](https://hesela.dev/terms/smr/)
- [zoned-block-device](https://hesela.dev/terms/zoned-block-device/)

Citations:
- [c1] ZBC. https://en.wikipedia.org/wiki/Zoned_block_device (accessed 2026-03-26)

### ZFS error scrub

URL: https://hesela.dev/terms/zfs-error-scrub/
Also known as: OpenZFS error scrub
Status: shipping

Record updated: 2026-10-16

A ZFS error scrub is an integrity scan restricted to files already recorded with data errors.

Note: OpenZFS 2.3 exposes this mode as zpool scrub -e and requires a prior scrub with head_errlog enabled. [zscrub] It does not advance last_scrubbed_txg. [zprops]

Limitations:
- It does not establish that files outside the known-error set are free of corruption. (sources: [zscrub])

Related terms:
- [data-scrubbing](https://hesela.dev/terms/data-scrubbing/)
- [checksum](https://hesela.dev/terms/checksum/)
- [resilver](https://hesela.dev/terms/resilver/)
- [zfs-transaction-group](https://hesela.dev/terms/zfs-transaction-group/)

Citations:
- [zscrub] OpenZFS 2.3: zpool-scrub(8), error-scrub scope and prerequisites. https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html (accessed 2026-10-16)
- [zprops] OpenZFS 2.3: zpoolprops(7), last_scrubbed_txg. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpoolprops.7.html#last_scrubbed_txg (accessed 2026-10-16)

### ZFS Intent Log

URL: https://hesela.dev/terms/zfs-intent-log/
Also known as: ZIL
Status: shipping

Record updated: 2026-10-14

The ZFS Intent Log is a per-dataset recovery log that can persist filesystem operations before their transaction group reaches stable storage.

Note: Intent records can remain in memory until the TXG commits or be committed to the on-disk ZIL to satisfy a synchronous request; recovery replays relevant persisted records when the dataset is instantiated. The log can live in the main pool without a separate device. [zil-source] [pool-man] Copied records contain data, while an indirect record points to a block written outside the log. Transaction-data byte counters do not measure physical SLOG writes. [zil-header]

Related terms:
- [zfs-separate-log](https://hesela.dev/terms/zfs-separate-log/)
- [zfs-transaction-group](https://hesela.dev/terms/zfs-transaction-group/)
- [fsync](https://hesela.dev/terms/fsync/)
- [write-ahead-log](https://hesela.dev/terms/write-ahead-log/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)

Citations:
- [zil-source] OpenZFS 2.3.4: zil.c, log lifecycle, zil_commit and zil_replay. https://github.com/openzfs/zfs/blob/zfs-2.3.4/module/zfs/zil.c (accessed 2026-10-14)
- [pool-man] OpenZFS 2.3: zpoolconcepts(7), Intent Log and Cache Devices. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpoolconcepts.7.html (accessed 2026-10-14)
- [zil-header] OpenZFS 2.3.4: zil.h, indirect and copied log records; statistics units. https://github.com/openzfs/zfs/blob/zfs-2.3.4/include/sys/zil.h (accessed 2026-10-14)

### ZFS separate log

URL: https://hesela.dev/terms/zfs-separate-log/
Also known as: SLOG, separate intent log device
Status: shipping

Record updated: 2026-10-14

A ZFS separate log is dedicated pool log-device storage used for intent-log blocks instead of their default allocation in the main pool.

Note: A SLOG is optional, not the ZIL itself and not a general write cache or independent backup. Log devices may be mirrored, but RAID-Z log vdevs are not supported. [pool-man] logbias=throughput bypasses configured log devices while retaining synchronous semantics; sync=disabled instead ignores application synchronous requests. [props-man] Data protected by an indirect log record need not be copied into the SLOG. [write-source]

Related terms:
- [zfs-intent-log](https://hesela.dev/terms/zfs-intent-log/)
- [zfs-transaction-group](https://hesela.dev/terms/zfs-transaction-group/)
- [write-back-cache](https://hesela.dev/terms/write-back-cache/)
- [power-loss-protection](https://hesela.dev/terms/power-loss-protection/)
- [fsync](https://hesela.dev/terms/fsync/)

Citations:
- [pool-man] OpenZFS 2.3: zpoolconcepts(7), Intent Log and Cache Devices. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zpoolconcepts.7.html (accessed 2026-10-14)
- [props-man] OpenZFS 2.3: zfsprops(7), sync and logbias. https://openzfs.github.io/openzfs-docs/man/v2.3/7/zfsprops.7.html (accessed 2026-10-14)
- [write-source] OpenZFS 2.3.4: zfs_log.c, zfs_log_write selection of write state. https://github.com/openzfs/zfs/blob/zfs-2.3.4/module/zfs/zfs_log.c (accessed 2026-10-14)

### ZFS transaction group

URL: https://hesela.dev/terms/zfs-transaction-group/
Also known as: TXG, txg
Status: shipping

Record updated: 2026-10-14

A ZFS transaction group is an ordered batch of changes whose synchronization advances the pool's consistent persistent state.

Note: OpenZFS 2.3.4 describes open, quiescing and syncing states, potentially occupied by different groups at the same time. Syncing writes accumulated state and finishes by writing a new uberblock. A TXG identifier is not a timestamp or an application transaction ID, and the configured timeout does not guarantee a maximum crash-loss window. [txg-source] Once a TXG is durable, its in-memory intent records can be discarded without requiring a separate on-disk log write. [zil-source]

Related terms:
- [zfs-intent-log](https://hesela.dev/terms/zfs-intent-log/)
- [zfs-separate-log](https://hesela.dev/terms/zfs-separate-log/)
- [copy-on-write](https://hesela.dev/terms/copy-on-write/)
- [crash-consistency](https://hesela.dev/terms/crash-consistency/)
- [database-checkpoint](https://hesela.dev/terms/database-checkpoint/)

Citations:
- [txg-source] OpenZFS 2.3.4: txg.c, transaction-group lifecycle and synchronization. https://github.com/openzfs/zfs/blob/zfs-2.3.4/module/zfs/txg.c (accessed 2026-10-14)
- [zil-source] OpenZFS 2.3.4: zil.c, log lifecycle, zil_commit and zil_replay. https://github.com/openzfs/zfs/blob/zfs-2.3.4/module/zfs/zil.c (accessed 2026-10-14)

### Zip drive

URL: https://hesela.dev/terms/zip-drive/
Status: eol

A removable cartridge drive format from Iomega offering tens to hundreds of megabytes per disk in the 1990s.

Related terms:
- [tape](https://hesela.dev/terms/tape/)
- [floppy-disk](https://hesela.dev/terms/floppy-disk/)

Citations:
- [c1] Zip drive. https://en.wikipedia.org/wiki/Zip_drive (accessed 2026-03-26)

### Zoned namespaces (ZNS)

URL: https://hesela.dev/terms/zns/
Also known as: NVMe ZNS
Status: limited

Record updated: 2026-10-13

Zoned Namespaces (ZNS) is an NVMe command set that organizes a namespace into zones with sequential-write constraints and explicit reset before reuse.

Note: Zones expose a logical allocation boundary, not a promise of one physical NAND block or a dedicated performance domain. The host manages placement and reclamation while media reliability remains a device responsibility. Open and active resources are separate budgets; zone capacity can be smaller than zone size.

Advantages:
- Reduces FTL indirection and can lower write amplification versus fully random LBA SSDs. (sources: [c1])

Limitations:
- Host adaptation and resource accounting are required; moving reclamation out of the SSD does not eliminate database compaction or guarantee isolation between zones. (sources: [bjorling], [min])

Related terms:
- [nvme](https://hesela.dev/terms/nvme/)
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [ftl](https://hesela.dev/terms/ftl/)
- [enterprise-ssd](https://hesela.dev/terms/enterprise-ssd/)
- [zoned-namespace](https://hesela.dev/terms/zoned-namespace/)
- [zoned-block-device](https://hesela.dev/terms/zoned-block-device/)
- [active-zone-limit](https://hesela.dev/terms/active-zone-limit/)
- [open-zone-limit](https://hesela.dev/terms/open-zone-limit/)
- [zone-capacity](https://hesela.dev/terms/zone-capacity/)
- [zone-append](https://hesela.dev/terms/zone-append/)
- [zone-write-pointer](https://hesela.dev/terms/zone-write-pointer/)
- [zone-reset](https://hesela.dev/terms/zone-reset/)
- [zone-finish](https://hesela.dev/terms/zone-finish/)

Citations:
- [c1] Zoned Namespace. https://nvmexpress.org/specifications/ (accessed 2026-03-26)
- [bjorling] Bjorling, Aghayev, Holmberg, Ramesh, Le Moal, Ganger and Amvrosiadis. ZNS: Avoiding the Block Interface Tax for Flash-based SSDs. USENIX ATC 2021, pp. 689-703, sections 3-5 and Table 3.. https://www.usenix.org/system/files/atc21-bjorling.pdf (accessed 2026-10-11)
- [min] Min, Zhao, Liu and Krishnamurthy. eZNS: An Elastic Zoned Namespace for Commodity ZNS SSDs. OSDI 2023, pp. 461-477, sections 3-5.. https://www.usenix.org/system/files/osdi23-min.pdf (accessed 2026-10-11)
- [zns-docs] Western Digital, Zoned Storage: NVMe Zoned Namespaces devices, capacity and resource limits.. https://zonedstorage.io/docs/introduction/zns (accessed 2026-10-11)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-11)

### Zone Append

URL: https://hesela.dev/terms/zone-append/
Also known as: NVMe Zone Append
Status: shipping

Record updated: 2026-10-16

The native NVMe Zone Append command writes at a controller-selected position within a specified zone and returns the assigned starting logical block address on successful completion.

Note: Submission order need not be placement order. The caller must keep returned locations and separately establish recovery, durability and transaction boundaries; append is not a general-purpose atomic commit. Linux can also emulate append with ordinary writes; seeing a block-layer append operation does not prove that a native append command reached the device.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [zone-capacity](https://hesela.dev/terms/zone-capacity/)
- [open-zone-limit](https://hesela.dev/terms/open-zone-limit/)
- [persistence-ordering](https://hesela.dev/terms/persistence-ordering/)
- [zone-write-pointer](https://hesela.dev/terms/zone-write-pointer/)
- [zone-write-plugging](https://hesela.dev/terms/zone-write-plugging/)

Citations:
- [zns-spec] NVM Express, Zoned Namespace Command Set Specification, revision 1.1 (cover: 18 May 2021), sections 2.1.1.4, 3.4.1, 3.4.3 and Annex A. Copyright 2007-2021 NVM Express, Inc. ALL RIGHTS RESERVED.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-1.1-2021.06.02-Ratified.pdf (accessed 2026-10-11)
- [zoned-overview] Western Digital, Zoned Storage: device models, zone types, management commands and Zone Append.. https://zonedstorage.io/docs/introduction/zoned-storage (accessed 2026-10-11)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-11)
- [linux610-zoned] Linux v6.10, block/blk-zoned.c: blk_zone_wplug_prepare_bio and blk_zone_plug_bio.. https://github.com/torvalds/linux/blob/v6.10/block/blk-zoned.c (accessed 2026-10-16)

### Zone capacity

URL: https://hesela.dev/terms/zone-capacity/
Also known as: ZCAP
Status: shipping

Record updated: 2026-10-13

Zone capacity is the maximum number of logical blocks that may be written within a zone.

Note: Zone size describes the address span. Capacity may be smaller, leaving an unwritable tail; multiply logical-block counts by the formatted data bytes per LBA before comparing byte capacities. Early Finish can strand additional unwritten capacity until reset.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [zoned-block-device](https://hesela.dev/terms/zoned-block-device/)
- [active-zone-limit](https://hesela.dev/terms/active-zone-limit/)
- [zone-write-pointer](https://hesela.dev/terms/zone-write-pointer/)
- [zone-finish](https://hesela.dev/terms/zone-finish/)

Citations:
- [zns-docs] Western Digital, Zoned Storage: NVMe Zoned Namespaces devices, capacity and resource limits.. https://zonedstorage.io/docs/introduction/zns (accessed 2026-10-11)
- [zoned-overview] Western Digital, Zoned Storage: device models, zone types, management commands and Zone Append.. https://zonedstorage.io/docs/introduction/zoned-storage (accessed 2026-10-11)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-11)

### Zone Finish

URL: https://hesela.dev/terms/zone-finish/
Also known as: Finish Zone
Status: shipping

Record updated: 2026-10-13

Zone Finish changes an eligible sequential zone to Full, ending further writes until reset without discarding the data already written.

Note: Early Finish gives up the remaining writable space until reset. In ZNS, Full consumes neither open nor active resources and has no valid write pointer. Finish is therefore not Close, Reset or an application transaction commit.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [zone-capacity](https://hesela.dev/terms/zone-capacity/)
- [zone-write-pointer](https://hesela.dev/terms/zone-write-pointer/)
- [zone-reset](https://hesela.dev/terms/zone-reset/)
- [active-zone-limit](https://hesela.dev/terms/active-zone-limit/)
- [open-zone-limit](https://hesela.dev/terms/open-zone-limit/)

Citations:
- [zoned-overview] Western Digital, Zoned Storage: zone management commands and state transitions.. https://zonedstorage.io/docs/introduction/zoned-storage (accessed 2026-10-13)
- [zns-spec] NVM Express, Zoned Namespace Command Set Specification, revision 1.1 (18 May 2021), Figure 4 and sections 2.1.1.2.1.1, 3.4.3.1.2 and 3.4.3.1.4. Copyright 2007-2021 NVM Express, Inc. ALL RIGHTS RESERVED.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-1.1-2021.06.02-Ratified.pdf (accessed 2026-10-13)
- [hesela-zns] Hesela: ZNS resource limits, lifecycle and recovery boundaries. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-13)

### Zone Reset

URL: https://hesela.dev/terms/zone-reset/
Also known as: Reset Zone, Reset Zone Write Pointer
Status: shipping

Record updated: 2026-10-13

Zone Reset makes an eligible sequential zone empty for reuse, returns its write pointer to the zone start and invalidates access to its previous data.

Note: Reset is destructive whole-zone reclamation, not a repair operation or evidence of secure sanitization. ZNS 1.1 rejects Reset on Read Only and Offline zones. Before issuing Reset, the application must preserve any still-needed records and their recovery metadata elsewhere.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [zone-write-pointer](https://hesela.dev/terms/zone-write-pointer/)
- [zone-finish](https://hesela.dev/terms/zone-finish/)
- [data-sanitization](https://hesela.dev/terms/data-sanitization/)

Citations:
- [zoned-overview] Western Digital, Zoned Storage: zone management commands and state transitions.. https://zonedstorage.io/docs/introduction/zoned-storage (accessed 2026-10-13)
- [zns-spec] NVM Express, Zoned Namespace Command Set Specification, revision 1.1 (18 May 2021), Figure 4 and sections 2.1.1.2.1.1, 3.4.3.1.2 and 3.4.3.1.4. Copyright 2007-2021 NVM Express, Inc. ALL RIGHTS RESERVED.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-1.1-2021.06.02-Ratified.pdf (accessed 2026-10-13)
- [hesela-zns] Hesela: ZNS resource limits, lifecycle and recovery boundaries. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-13)

### Zone write locking

URL: https://hesela.dev/terms/zone-write-locking/
Status: shipping

Record updated: 2026-10-16

A Linux mechanism that serializes covered write requests to the same sequential zone using a per-zone lock.

Note: The upstream Linux 4.16-6.9 implementation resides in deadline or mq-deadline. Zone write plugging replaces it from Linux 6.10. This is not a global I/O order, a device ownership lock or a persistence guarantee; callers still supply valid offsets.

Related terms:
- [zone-write-plugging](https://hesela.dev/terms/zone-write-plugging/)
- [zoned-block-device](https://hesela.dev/terms/zoned-block-device/)
- [zone-write-pointer](https://hesela.dev/terms/zone-write-pointer/)

Citations:
- [linux-ordering-docs] Western Digital, Zoned Storage: Write Ordering Control; locking through Linux 6.9 and plugging from Linux 6.10.. https://zonedstorage.io/docs/linux/sched (accessed 2026-10-16)
- [linux69-deadline] Linux v6.9, block/mq-deadline.c: deadline_fifo_request, deadline_next_request and request dispatch.. https://github.com/torvalds/linux/blob/v6.9/block/mq-deadline.c (accessed 2026-10-16)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-16)

### Zone write plugging

URL: https://hesela.dev/terms/zone-write-plugging/
Status: shipping

Record updated: 2026-10-16

A Linux block-layer mechanism that queues covered writes per sequential zone before dispatch to preserve the issuer's sequential write pattern.

Note: Introduced upstream in Linux 6.10, it removes the mq-deadline dependency. Native Zone Append bypasses this plug; emulated append uses it. It neither fixes invalid application offsets nor serializes Reset or Finish against in-flight writes, and is not a durability guarantee.

Related terms:
- [zone-write-locking](https://hesela.dev/terms/zone-write-locking/)
- [zoned-block-device](https://hesela.dev/terms/zoned-block-device/)
- [zone-append](https://hesela.dev/terms/zone-append/)
- [zone-write-pointer](https://hesela.dev/terms/zone-write-pointer/)

Citations:
- [linux-ordering-docs] Western Digital, Zoned Storage: Write Ordering Control; locking through Linux 6.9 and plugging from Linux 6.10.. https://zonedstorage.io/docs/linux/sched (accessed 2026-10-16)
- [linux610-zoned] Linux v6.10, block/blk-zoned.c: blk_zone_wplug_prepare_bio and blk_zone_plug_bio.. https://github.com/torvalds/linux/blob/v6.10/block/blk-zoned.c (accessed 2026-10-16)
- [linux610-mq] Linux v6.10, block/blk-mq.c: blk_mq_submit_bio and zone plugging before request allocation.. https://github.com/torvalds/linux/blob/v6.10/block/blk-mq.c (accessed 2026-10-16)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-16)

### Zone write pointer

URL: https://hesela.dev/terms/zone-write-pointer/
Also known as: Zone WP
Status: shipping

Record updated: 2026-10-13

A zone write pointer identifies the next writable logical block address in a sequential zone when its current state makes that pointer valid.

Note: Under ZNS 1.1 the pointer is valid in Empty, implicitly open, explicitly open and Closed states, but not in Full, Read Only or Offline. It is not a committed-record count. Failed writes may advance or invalidate it; recovery must check the reported state as well as the pointer.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [zone-append](https://hesela.dev/terms/zone-append/)
- [zone-capacity](https://hesela.dev/terms/zone-capacity/)
- [zone-reset](https://hesela.dev/terms/zone-reset/)
- [zone-finish](https://hesela.dev/terms/zone-finish/)

Citations:
- [zns-spec] NVM Express, Zoned Namespace Command Set Specification, revision 1.1 (18 May 2021), Figure 4 and sections 2.1.1.2.1.1, 3.4.3.1.2 and 3.4.3.1.4. Copyright 2007-2021 NVM Express, Inc. ALL RIGHTS RESERVED.. https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-1.1-2021.06.02-Ratified.pdf (accessed 2026-10-13)
- [zonefs] Linux kernel documentation, zonefs: sequential zone files and I/O error handling.. https://docs.kernel.org/filesystems/zonefs.html (accessed 2026-10-13)
- [hesela-zns] Hesela: ZNS resource limits, lifecycle and recovery boundaries. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-13)

### Zoned block device (ZBD)

URL: https://hesela.dev/terms/zoned-block-device/
Status: shipping

Record updated: 2026-10-16

A zoned block device exposes a logical block address space divided into zones with zone-specific access rules.

Note: The device model is not Linux itself: Linux's zoned block layer provides a common interface to supported devices. Conventional, sequential-write-required and sequential-write-preferred zones are different types; the permitted types depend on the device model and protocol. ZNS and host-managed SMR are related implementations, not synonyms.

Related terms:
- [hm-smr](https://hesela.dev/terms/hm-smr/)
- [zns](https://hesela.dev/terms/zns/)
- [smr](https://hesela.dev/terms/smr/)
- [zone-capacity](https://hesela.dev/terms/zone-capacity/)
- [zone-append](https://hesela.dev/terms/zone-append/)
- [zone-write-plugging](https://hesela.dev/terms/zone-write-plugging/)
- [zone-write-locking](https://hesela.dev/terms/zone-write-locking/)

Citations:
- [c1] Zoned block device (ZBD). https://en.wikipedia.org/wiki/Zoned_block_device (accessed 2026-03-26)
- [zoned-overview] Western Digital, Zoned Storage: device models, zone types, management commands and Zone Append.. https://zonedstorage.io/docs/introduction/zoned-storage (accessed 2026-10-11)
- [zonefs] Linux kernel documentation, zonefs: sequential files, explicit-open and runtime sysfs attributes.. https://docs.kernel.org/filesystems/zonefs.html (accessed 2026-10-11)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-11)
- [linux-ordering-docs] Western Digital, Zoned Storage: Write Ordering Control; locking through Linux 6.9 and plugging from Linux 6.10.. https://zonedstorage.io/docs/linux/sched (accessed 2026-10-16)

### Zoned namespace

URL: https://hesela.dev/terms/zoned-namespace/
Status: shipping

Record updated: 2026-10-11

A zoned namespace is an NVMe namespace whose logical address space follows the ZNS command set's zone organization and write constraints.

Note: This existing record names the namespace object; zns names the command set. Their identifiers are retained for compatibility, not treated as two different storage technologies.

Related terms:
- [zns](https://hesela.dev/terms/zns/)
- [namespace-nvme](https://hesela.dev/terms/namespace-nvme/)
- [zone-capacity](https://hesela.dev/terms/zone-capacity/)
- [active-zone-limit](https://hesela.dev/terms/active-zone-limit/)

Citations:
- [c1] Zoned namespace. https://en.wikipedia.org/wiki/Zoned_Namespace (accessed 2026-03-26)
- [zns-docs] Western Digital, Zoned Storage: NVMe Zoned Namespaces devices, capacity and resource limits.. https://zonedstorage.io/docs/introduction/zns (accessed 2026-10-11)
- [hesela-zns] Hesela: ZNS resource limits and worked examples. https://hesela.com/analyses/zns-open-active-zone-limits/ (accessed 2026-10-11)