company_banner

Тестирование SSD на надёжность: 3dnews vs JEDEC vs здравый смысл. Где правда, брат?



    Всем известно легендарное тестирование SSD на надёжность от 3dnews (публикация от 2018.01), по результатам которого некоторые бюджетные накопители превзошли заявленный производителем ресурс в десятки раз.

    После этого исследования в народе появилась конспирологическая теория, что производители занижают ресурс у бюджетных SSD, а также распространилось убеждение, что практически все SSD умеют делать и качественно выполняют выравнивание износа.

    Исследование от 3dnews.ru было проведено по мотивам тестирования Techreport.com (публикация от 2013.08.20).

    Методика для измерения износостойкости также была использована одинаковая.

    Методика Techreport:
    We can push SSD endurance limits much faster with synthetic benchmarks. There are myriad options, but the best one is Anvil’s imaginatively named Storage Utilities.

    Developed by a frequenter of the XtremeSystems forums, this handy little app includes a dedicated endurance test that fills drives with files of varying sizes before deleting them and starting the process anew. We can tweak the payload of each loop to write the same amount of data to each drive. There’s an integrated MD5 hash check that verifies data integrity, and the write speed is more than an order of magnitude faster than DriveBench 2.0’s effective write rate.

    Anvil’s endurance test writes files sequentially, so it’s not an ideal real-world simulation. However, it’s the best tool we have, and it allows us to load drives with a portion of static data to challenge wear-leveling routines. We’re using 10GB of static data, including a copy of the Windows 7 installation folder, a handful of application files, and a few movies.

    Методика 3dnews.ru:
    Поэтому в нашем тесте выносливости мы используем отформатированные с файловой системой NTFS накопители, на которых непрерывно и попеременно создаются файлы двух типов: мелкие – со случайным размером от 1 до 128 Кбайт и крупные – со случайным размером от 128 Кбайт до 10 Мбайт. В процессе теста эти файлы со случайным заполнением множатся, пока на накопителе остаётся более 12 Гбайт свободного места, по достижении же этого порога все созданные файлы удаляются, делается небольшая пауза и процесс повторяется вновь. Помимо этого, на испытуемых накопителях одновременно присутствует и третий тип файлов – постоянный. Такие файлы общим объёмом 16 Гбайт в процессе стирания-перезаписи не участвуют, но используются для проверки правильной работоспособности накопителей и стабильной читаемости хранимой информации: каждый цикл заполнения SSD мы проверяем контрольную сумму этих файлов и сверяем её с эталонным, заранее рассчитанным значением.

    В обоих случаях использовалась утилита Anvil’s Storage Utilities.

    1. А что не так с методикой?


    Проблема заключается в том, что заполнение диска происходит последовательно. Что не соответствует ни реальным сценариям использования, ни процедуре измерения износостойкости, рекомендованной JEDEC (комитет инженерной стандартизации полупроводниковой продукции, иначе называемый Solid State Technology Association, куда входят все крупнейшие производители флэш-памяти).

    И ОС, и контроллер (если у него есть небольшой DRAM-кеш) группируют последовательные блоки идущие на запись и записывают большими нативными блоками, свойственными конкретному устройству. При этом практически отсутствует усиление записи и практически нет необходимости в алгоритмах выравнивания износа.

    В реальных условиях, как фактор мультипликации, так и качественная реализация алгоритма выравнивания износа имеют сильное влияние на ресурс накопителя.

    Проблема 1. При последовательной записи файлов WAF ≈ 1


    Тест, построенный так, что в нём фактор мультипликации записи (WAF) стремится к единице, будет предсказуемо давать завышенные результаты по ресурсу. У большинства дисков проанализированных 3dnews (из которых можно было извлечь WAF), коэффициент усиления записи был ≈1-1.11. Специалисты 3dnews объясняли это эффективными алгоритмами контроллеров. Лишь буквально у одного экземпляра WAF был 3, чтобы было объяснено неэффективным контроллером.

    Однако, по моему мнению, всё дело в методике теста, который генерировал последовательную запись (при которой WAF → 1), что и дало завышение ресурса SSD-накопителей.
    Далее я оценю во сколько раз.

    Проблема 2. Не тестируется качество алгоритма выравнивания износа


    При последовательном заполнении диска и последующем стирании плохо тестируется механизм выравнивания износа. Если производитель догадался сделать первые несколько ГБ диска (где находится битовая карта диска, FAT и прочие метаданные) работающими в режиме SLC (или кеширует их в буфере RAM), то алгоритм выравнивания износа может полностью отсутствовать в прошивке и всё равно при последовательной записи будeт достигнуты отличные показатели ресурса.

    Проблема 3. Не тестируется срок хранения данных после исчерпания ресурса


    Если вы уезжаете в путешествие на несколько месяцев, то непонятно можно ли доверять диску, который выработал свой паспортный ресурс.

    Проблема 4. Последовательное заполнение диска, с последующим практически полным стиранием, не является реальным пользовательским шаблоном поведения


    Поскольку SSD — это ещё довольно дорогой ресурс, то люди обычно стараются его использовать максимально полно и оставляют минимум свободного места.

    Идеальный тест, на мой взгляд, это чтобы во время тестирования SSD оставался забитым на 80-90%, при этом в случайном порядке старые файлы должны удаляться, а новые добавляться.

    2. Факторы мультипликации записи


    2.1. Фрагментация файловой системы


    Так как в Windows у SSD отключена дефрагментация, а размер кластера NTFS по умолчанию составляет 4КБ, то в реальной жизни диск сильно фрагментируется. В этом случае даже последовательная запись превращается по скорости практически в случайную.

    Контроллеру, чтобы записать 1 изменённый кластер приходится вначале считать всю аппаратную страницу NAND (которая может достигать сотен килобайт в размере), изменить 4КБ, а потом всю её записать. Если размер полезной ёмкости страницы NAND составляет 64КБ, то мы имеем усиление записи в 16 раз.

    Реальные размеры страниц в NAND
    Из комментария:

    Реальные размеры страниц в NAND микросхемах обычно все же не сотни килобайт, а 528, 2112, 4224, 4320, 8576, 8640, 8832, 8896, 9216, 17664, 18048, 18336 и т.д. Малые размеры справедливы для старых SLC микросхем, для TLC и QLC размеры поболее. Такие странные размеры потому, что кроме пользовательских данных необходимо хранить служебные данные (ECC, флаги, номера блоков, счетчики записей и т. п.).

    2.2. Алгоритм выравнивания износа


    Такой алгоритм может быть реализован в виде отдельного процесса внутри контроллера. Он будет работать примерно так:

    Чтобы переместить статические данные в область с более высоким износом, требуется осуществить запись, равную по размеру перемещаемым данным, при условии, что есть освобождённый TRIM блок. А при малом количестве свободных блоков придётся совершить 2 записи, чтобы поменять данные местами.

    RAM = a
    a = b
    b = RAM

    При малом или отсутствующем DRAM-буфере потребуется три записи.

    temp = a
    a = b
    b = temp

    Эти операции в идеальном алгоритме выравнивания износа будут выполняться крайне редко, так как имеет смысл перемещать только статические данные, чтобы задействовать в оборот страницы с низким износом, поэтому мы пренебрежём влиянием алгоритма выравнивания износа на мультипликацию записи. Хотя, конечно, нет никаких гарантий, что в реальных SSD используются идеальные алгоритмы.

    2.3. Типичная запись на SSD является случайной, блоком 4-8КБ


    Обычная природа записей на SSD представляет из себя в основном случайную запись 8КБ. Даже при отсутствии фрагментации размер типичного блока записи будет меньше размера страницы NAND и будет вызывать мультипликацию записи.

    2.4. Алгоритм сборки мусора


    Вот тут кроются самые большие подводные камни. Размер блока в NAND памяти достигает нескольких мегабайт. Блок состоит из нескольких страниц.

    Страницы могут быть прочтены и записаны по отдельности, а блок может быть стёрт только полностью.

    Со временем многие страницы в блоке помечаются как недействительные, так как данные которые были в них были изменены и записаны в другое место или из-за вызова TRIM. И рано или поздно сборщик мусора должен взять несколько частично заполненных блоков и скомпоновать из них полностью записанные и свободные.

    Пока есть свободное место, то скорее всего, он даже не будет запускаться, поэтому со временем в блоках образуются многочисленные дыры.

    Чем меньше места на диске, тем быстрее возрастает WAF (коэффициент мультипликации записи, Write Amplification Factor).

    Для иллюстрации увеличения WAF приведу следующую картинку:



    На картинке показаны блоки NAND памяти с данными, заполненные на 87.5%, разбитые на страницы. Для того чтобы освободить место для записи происходит перекомпоновка, при которой перезаписывается 7 блоков и стирается 1. Итого WAF получается = 8!

    Конечно, нужно ещё учесть, что у большинства SSD есть резервная область, в которую также происходит перераспределение записи. Но, как правило, она невелика.

    Типичный размер скрытой области для потребительских дисков составляет 7.37%, т.к. производители указывают размер в миллиардах байт, а микросхемы имеют ёмкость в гигабайтах. 1 гигабайт = 1 073 741 824 байт).

    В случае заполненности диска на 90% и наличии скрытой области размером в 7.37%, WAF будет равен 6.18!

    WAF может оценён по этой формуле:

    $WAF_\text{сборки мусора} = \frac {1} {1 - \frac {K_\text{заполненность диска}} {K_\text{резервной области}}}$



    Kзаполненность диска — от 0 до 1, где 1 — 100% заполнение диска.
    Kрезервной области — от 1, где 1 — 0% резервная область, 1.1 — 10% резервной области, и так далее.

    Приблизительный график зависимости WA от процента свободного места на диске.



    Из графика видно, что WA катастрофически нарастает по мере заполнения диска, приближаясь к 15 при полном заполнении диска с резервной областью 7.37% (типичное число для потребительских дисков, т.к. производители указывают размер в миллиардах байт, а микросхемы имеют ёмкость в гигабайтах. 1 гигабайт = 1 073 741 824 байт).

    Вы, наверное, сами замечали как сильно начинает тормозить телефон, если там оказываются считанные единицы процентов свободного места. Ведь в нём тоже используется флэш-память. Забивать память под 100% не только ужасно медленно, но и сильно тратит ресурс накопителя.

    Отдельная статья по теме.

    2.5. Общий WAF от всех факторов


    WAF, вносимые малосвязанными факторами, перемножаются.

    3. Методика измерения ресурса от JEDEC для пользовательских SSD



    В стандарте JEDEC «Solid-State Drive (SSD) Endurance Workloads» от сентября 2010 года, ревизия JESD219A есть описание методики для тестирования SSD.

    В двух словах: инженеры JEDEC записали логи записей, TRIM и flush (команда сброса буферов на диск) некоторого пользователя ноутбука за 7 месяцев, работающего в основном с офисными программами. Предположительно на ноутбуке была установлена Windows 7 (поддерживает TRIM c 2009 года) на файловой системе NTFS с размером кластера 4КБ.

    Детали о эталонном пользовательском компьютере и общая статистика
    Platform and Workload
    Collected on standard laptop PC, 2 GB RAM, 128 GB SATA SSD, operating system supporting trim
    Main use: office productivity
    Secondary use: storage of photos, music, and apps

    Trace Characteristics

    Writes/Trims/Flushes captured in a file with a CSV format: $command offset size
    49 GB footprint (total data touched)
    128 GB spanned (range of LBA’s accessed)

    Average amount of Trimmed space = 13 GB (average across duration of trace)

    Other Trace Characteristics
    Count of command
    Total # of commands (reads not
    counted)
    39923531
    # of Trims 2498963
    # of Writes 35391419
    # of Flush 2033149
    Operation types
    % of Trims 6.26%
    % of Writes 88.65%
    % of Flush 5.09%
    Sequential vs Random writes
    % of Sequential Writes 24.36%
    % of Random Writes 75.64%
    Total amount of data
    Trim (GB) 764.92
    Write (GB) 727.64


    Я распарсил этот лог, чтобы понять какие активности там записаны.
    512 1K+ 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
    Операции, % 1.88 0.79 1.15 36.76 7.49 46.29 2.74 1.40 1.49
    Объём записи, % 0.04 0.04 0.15 6.85 3.21 34.76 4.68 4.86 45.42

    При тестировании предлагается повторять записи по этому логу (Master Trace), пока не наберётся нужное число записанных терабайт (TBW), после чего нужно проверить в течении какого времени ячейки хранят заряд (retention time). Для пользовательского SSD это время должно быть около 2 лет при температуре хранения 25℃, если рабочая температура была 40℃. Поскольку 2 года никто ждать не будет, то повышают температуру хранения, что ведёт к более высокой утечке электронов, и по специальным таблицам (построенным по уравнению Аррениуса) вычисляют время хранения данных при нормальной температуре.



    Интересные факты:

    Как известно, NAND-память разбиты на страницы, которые объединяются в блоки. Запись и чтение происходит постранично, а стирание только блоками.

    Когда нужно что-то переписать, идеальная прошивка работает примерно так: она записывает страницы с изменёнными данными в блок, где ещё есть незаписанные страницы и устанавливает новое соответствие LBA→страница в FTL (Flash Translation Layer), а старую страницу помечает недействительной. Если же таких блоков нет, то запускается сборщик мусора, который компонует данные из полузаполненных блоков в заполненные с освобождением блоков.

    Это идеальный вариант. Не все пользовательские SSD имеют хорошие алгоритмы выравнивания износа. Что видно по драматически отличающимся результатам тестирования 3dnews.

    Типичный размер страницы составляет 8KB и выше, а размер блока 2MB и выше. В тестировании JEDEC диск никогда не заполнялся более 38%, поэтому там всегда, как я подозреваю, были свободные блоки и поэтому не было активной работы сборщика мусора, который тоже тратит ресурс SSD. Но был WAF (Write Multiplication Factor) из-за того, что данные иногда записывались неполными страницами, а иногда одна запись проходила по границе NAND-страниц.

    Я написал скрипт для вычисления WAF в зависимости от размера страницы в тестировании JEDEC. Вот WAF в зависимости от размера страницы NAND:
    1K 2K 4K 8K 16K 32K 64K 128K
    WAF 1.0 1.0 1.01 1.11 1.31 2.06 3.54 6.5

    В тестировании 3dnews WAF примерно равен 1, так как файлы записываются последовательно, а Windows имеет кеширование записи, в ходе которого сектора записываются упорядоченно.

    В типичном сценарии, когда страница равна 8К (Samsung 840 EVO) WAF всего 1.11 (погрешность на 11% от данных от 3dnews), что вроде бы можно простить. Но если мы учтём ещё WAF, который вносит алгоритм сборки мусора, то простить нельзя.

    4. Методика JEDEC для тестирования корпоративных дисков на износостойкость


    Она описана значительно более формализовано и условия более жёсткие. Задаётся чёткий процентаж записей различной длины. Записи размером до 4096 байт могут быть случайно смещены, а длиной от 4КБ должны быть выравнены по 4КБ смещениям.
    Размер записи Доля, %
    512 байт (0.5КБ) 4%
    1024 байт (1КБ) 1%
    1536 байт (1.5КБ) 1%
    2048 байт (2КБ) 1%
    2560 байт (2.5КБ) 1%
    3072 байт (3КБ) 1%
    3584 байт (3.5КБ) 1%
    4096 байт (4КБ) 67%
    8192 байт (8КБ) 10%
    16384 байт (16КБ) 7%
    32768 байт (32КБ) 10%
    65536 байт (64КБ) 10%

    Расчёт WAF в зависимости от размера страницы.
    1K 2K 4K 8K 16K 32K 64K 128K
    WAF 1.13 1.26 1.52 2.05 3.10 5.19 9.38 17.76

    5. Расчёт поправок к результатам тестирования 3dnews


    Нам нужны поправочные коэффициенты для того, чтобы износостойкость по методике 3dnews преобразовывать в износостойкость по методике Jedec.

    Для начала мы уменьшим достигнутый результат в 2 раза, так как в тестировании не проверялось долговечность хранения. Никто не хочет обнаружить, что после отпуска, накопитель в его компьютере перестал работать или покрылся бэдами. Цифра 2 взята с потолка.

    По методике JEDEC диск заполнен всего на 38%, что даём нам увеличение WAF из-за сборки мусора в 1.55 раза (по формуле выше). Этот коэффициент будет в знаменателе.

    Далее мы учтём фактор мультипликации записи в зависимости от размера страницы NAND (полученный при анализе тестирования пользовательских SSD по методике JEDEC) и перемножим на WAF, который имеем от сборщика мусора.

    $K_\text{поправки} = \frac {2 * WAF_\text{сборщика мусора от заполненности диска} * WAF_\text{от размера страницы и характера записей}} {WAF_\text{сборка мусора Jedec}}$


    Поправочные коэффициенты для дисков с избыточной областью в 7.37%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    2K 2.4 2.6 2.9 3.3 3.7 4.3 5.1 6.2 8.0 11.2 18.8
    4K 2.4 2.7 3.0 3.3 3.7 4.3 5.1 6.3 8.1 11.3 19.0
    8K 2.7 2.9 3.2 3.6 4.1 4.8 5.6 6.9 8.9 12.4 20.9
    16K 3.2 3.5 3.8 4.3 4.9 5.6 6.6 8.1 10.4 14.7 24.6
    32K 5.0 5.4 6.0 6.7 7.6 8.8 10.4 12.8 16.4 23.1 38.7
    64K 8.5 9.4 10.4 11.6 13.1 15.1 17.9 21.9 28.2 39.6 66.5
    128K 15.7 17.2 19.0 21.3 24.1 27.8 32.9 40.2 51.8 72.8 122.1

    Поправочные коэффициенты для дисков с избыточной областью в 10%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    2K 2.4 2.6 2.8 3.2 3.5 4.1 4.7 5.7 7.1 9.5 14.2
    4K 2.4 2.6 2.9 3.2 3.6 4.1 4.8 5.7 7.2 9.6 14.3
    8K 2.6 2.9 3.2 3.5 3.9 4.5 5.3 6.3 7.9 10.5 15.8
    16K 3.1 3.4 3.7 4.1 4.6 5.3 6.2 7.4 9.3 12.4 18.6
    32K 4.9 5.3 5.8 6.5 7.3 8.4 9.7 11.7 14.6 19.5 29.2
    64K 8.4 9.1 10.0 11.2 12.6 14.4 16.7 20.1 25.1 33.5 50.2
    128K 15.4 16.8 18.5 20.5 23.1 26.4 30.8 36.9 46.1 61.5 92.3


    Поправочные коэффициенты для дисков с избыточной областью в 20%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    2K 2.2 2.4 2.6 2.8 3.1 3.4 3.9 4.4 5.2 6.2 7.7
    4K 2.2 2.4 2.6 2.8 3.1 3.5 3.9 4.5 5.2 6.3 7.8
    8K 2.5 2.6 2.9 3.1 3.4 3.8 4.3 4.9 5.7 6.9 8.6
    16K 2.9 3.1 3.4 3.7 4.1 4.5 5.1 5.8 6.8 8.1 10.1
    32K 4.6 4.9 5.3 5.8 6.4 7.1 8.0 9.1 10.6 12.8 15.9
    64K 7.8 8.4 9.1 10.0 11.0 12.2 13.7 15.7 18.3 21.9 27.4
    128K 14.4 15.5 16.8 18.3 20.1 22.4 25.2 28.8 33.5 40.3 50.3


    Поправочные коэффициенты для дисков с избыточной областью в 30%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    2K 2.1 2.2 2.4 2.6 2.8 3.0 3.4 3.7 4.2 4.8 5.6
    4K 2.1 2.3 2.4 2.6 2.8 3.1 3.4 3.8 4.2 4.8 5.6
    8K 2.3 2.5 2.7 2.9 3.1 3.4 3.7 4.1 4.7 5.3 6.2
    16K 2.7 2.9 3.1 3.4 3.7 4.0 4.4 4.9 5.5 6.3 7.3
    32K 4.3 4.6 4.9 5.3 5.8 6.3 6.9 7.7 8.6 9.9 11.5
    64K 7.4 7.9 8.5 9.1 9.9 10.8 11.9 13.2 14.8 17.0 19.8
    128K 13.6 14.5 15.6 16.8 18.2 19.8 21.8 24.2 27.3 31.2 36.3


    6. Поправки к результатам тестирования 3dnews для использования пользовательских SSD в серверах


    Сразу скажу, что это плохая идея. Но многие так делают. Поэтому попробуем рассчитать поправочные коэффициенты для определения ресурса пользовательских дисков в качестве серверных. Мы берём износостойкость из тестирования 3dnews и делим её на нужный коэффициент, чтобы получить ожидаемый ресурс (методика JEDEC) при корпоративном применении.
    В серверах не требуется такое долговременное хранение в отключенном состоянии, как в пользовательских SSD. Вот соответствующая таблица:



    При типичной температуре 50℃ эксплуатации под нагрузкой накопитель должен обеспечивать 58 недель ≈ 1 год хранения данных в отключенном состоянии при 25℃.

    Для пользовательского применения (где требуется сохранность данных в течении 2-х лет в отключенном состоянии) мы уменьшили ресурс в 2 раза. Для корпоративного применения не нужен такой большой срок хранения, поэтому мы возьмём меньшее число, например, 1.3.

    После этого умножим на WAF, характерный для корпоративной нагрузке, а потом учтём работу сборщика мусора и получим следующие таблицы коэффициентов. Результат полученный 3dnews нужно разделить на это число.

    Есть проблема с тем, что в стандарте не описывается размер резервной области или свободного места для корпоративных дисков. Поэтому мы не можем точно оценить WAFкорпоративного теста JEDEC, поэтому возьмём это число (1.55) из теста пользовательских SSD JEDEC.

    Поправочные коэффициенты для дисков с избыточной областью в 7.37%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    1K 1.8 1.9 2.1 2.4 2.7 3.1 3.7 4.5 5.9 8.2 13.8
    2K 2.0 2.2 2.4 2.7 3.0 3.5 4.1 5.1 6.5 9.2 15.4
    4K 2.4 2.6 2.9 3.2 3.7 4.2 5.0 6.1 7.9 11.1 18.6
    8K 3.2 3.5 3.9 4.4 4.9 5.7 6.7 8.3 10.6 14.9 25.0
    16K 4.9 5.3 5.9 6.6 7.5 8.6 10.2 12.5 16.1 22.6 37.9
    32K 8.1 8.9 9.9 11.0 12.5 14.4 17.1 20.9 26.9 37.8 63.4
    64K 14.7 16.1 17.8 19.9 22.6 26.1 30.9 37.8 48.6 68.3 114.6
    128K 27.9 30.5 33.8 37.7 42.8 49.4 58.4 71.5 92.1 129.3 216.9

    Поправочные коэффициенты для дисков с избыточной областью в 10%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    1K 1.7 1.9 2.1 2.3 2.6 3.0 3.5 4.2 5.2 7.0 10.4
    2K 1.9 2.1 2.3 2.6 2.9 3.3 3.9 4.6 5.8 7.7 11.6
    4K 2.3 2.5 2.8 3.1 3.5 4.0 4.7 5.6 7.0 9.3 14.0
    8K 3.2 3.4 3.8 4.2 4.7 5.4 6.3 7.6 9.5 12.6 18.9
    16K 4.8 5.2 5.7 6.4 7.1 8.2 9.5 11.4 14.3 19.1 28.6
    32K 8.0 8.7 9.6 10.6 12.0 13.7 16.0 19.2 23.9 31.9 47.9
    64K 14.4 15.7 17.3 19.2 21.6 24.7 28.8 34.6 43.3 57.7 86.5
    128K 27.3 29.8 32.8 36.4 41.0 46.8 54.6 65.5 81.9 109.2 163.9


    Поправочные коэффициенты для дисков с избыточной областью в 20%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    1K 1.6 1.7 1.9 2.1 2.3 2.5 2.8 3.2 3.8 4.5 5.7
    2K 1.8 2.0 2.1 2.3 2.5 2.8 3.2 3.6 4.2 5.1 6.3
    4K 2.2 2.4 2.5 2.8 3.1 3.4 3.8 4.4 5.1 6.1 7.6
    8K 2.9 3.2 3.4 3.8 4.1 4.6 5.2 5.9 6.9 8.3 10.3
    16K 4.5 4.8 5.2 5.7 6.2 6.9 7.8 8.9 10.4 12.5 15.6
    32K 7.5 8.0 8.7 9.5 10.4 11.6 13.1 14.9 17.4 20.9 26.1
    64K 13.5 14.5 15.7 17.2 18.9 21.0 23.6 27.0 31.5 37.8 47.2
    128K 25.5 27.5 29.8 32.5 35.7 39.7 44.7 51.1 59.6 71.5 89.4


    Поправочные коэффициенты для дисков с избыточной областью в 30%.
    заполненность диска, %
    50 55 60 65 70 75 80 85 90 95 100
    1K 1.5 1.6 1.8 1.9 2.1 2.2 2.5 2.7 3.1 3.5 4.1
    2K 1.7 1.8 2.0 2.1 2.3 2.5 2.7 3.1 3.4 3.9 4.6
    4K 2.1 2.2 2.4 2.5 2.8 3.0 3.3 3.7 4.1 4.7 5.5
    8K 2.8 3.0 3.2 3.4 3.7 4.1 4.5 5.0 5.6 6.4 7.5
    16K 4.2 4.5 4.8 5.2 5.6 6.1 6.8 7.5 8.5 9.7 11.3
    32K 7.1 7.5 8.1 8.7 9.4 10.3 11.3 12.6 14.1 16.2 18.9
    64K 12.8 13.6 14.6 15.7 17.0 18.6 20.5 22.7 25.6 29.2 34.1
    128K 24.2 25.8 27.7 29.8 32.3 35.2 38.7 43.0 48.4 55.3 64.5


    8. Выводы


    Если вы никогда не выключаете свой компьютер на несколько месяцев, размер страницы NAND не более 16КБ, и диск заполнен примерно наполовину, то показатели ресурса достигнутые 3dnews нужно разделить на 3.

    Для типового сценария (занятость диска 90%, размер страницы 8КБ), чтобы получить ресурс по стандартам JEDEC, делим на 9 ресурс, полученный 3dnews.

    Если вы иногда отправляетесь в реально длительные путешествия, а накопитель в это время не используется, то советую оставаться в рамках паспортного ресурса, по истечении которого менять накопитель.

    Для редких случаев, когда размер страницы NAND больше 16КБ, а диск довольно плотно заполнен, то чтобы вычислить реальный ресурс накопителя, его нужно уменьшать в десятки, а иногда в сотни раз.

    А если вы засовываете бюджетный накопитель в сервер, то озаботьтесь и рейдом, и бэкапом. У вас не будет стабильного времени отклика и скоростей, защиты по питанию и других плюшек корпоративных накопителей, но ресурс вы можете вычислить с помощью поправочных делителей из соответствующей таблицы статьи. В типовом случае делим на 11.

    Ссылки


    Optimizing Linux with cheap flash drives
    Как определяем размер страницы и блока флэш-памяти

    P.S. Замеченные ошибки направляйте в личку. Повышаю за это карму.

    За изображение спасибо TripletConcept.


    Вы можете заказать виртуальную машину с SSD у RUVDS по купону ниже.

    RUVDS.com
    1 179,78
    RUVDS – хостинг VDS/VPS серверов
    Поддержать автора
    Поделиться публикацией

    Похожие публикации

    Комментарии 54

      +1
      Вы пробовали связаться с автором тестирования? Интересно было бы выслушать его контраргументы.
        0
        3dnews сознательно взяли ту же методику, что и TechReport.com. В их статье об этом написано.

        Тут скорее связываться нужно с автором из TechReport.com или автором Anvil's Storage Utilites. Нет, с ними не связывался.
          0
          Ещё интереснее было бы послушать разработчиков ПО контроллера диска. Без знания алгоритма его работы любые тестирования — гадание на кофейной гуще.

          Например тест 3DNews показывает что диск и половины заявленного объёма не запишет, а производитель даёт гарантию 5 лет или 100 Тб. Видимо у них свои тесты.

          Но сильно сомневаюсь в их желании беседовать на эту тему.
            +1
            Иногда выгодно дать большую гарантию, несмотря на то, что диск на неё не рассчитан. Исходя из того, что мало кто обратится, т.к. технологии устареют, будет лень, обычные юзеры редко используют на полную катушку…
              +1
              А где у них такое было? Наоборот на 3DNews типичные результаты тестирования получались в разы иногда больше чем на порядок выше заявленных производителями ресурсов.

              В этой статье хорошо описывает как раз почему — очень уж «комфортные» условия работы у дисков в таких тестах по сравнению с реальными условиями эксплуатации.

              P.S.
              Спасибо inetstar за статью. Само собирался на эту тему писать, даже кусочки из собственных же тут оставленных комментариев по теме в черновик собирать начал. Но тут вы практически «все написали за меня».
                0
                Уважаемый Mad__Max,
                А где у них такое было? Наоборот на 3DNews типичные результаты тестирования получались в разы иногда больше чем на порядок выше заявленных производителями ресурсов.
                Это написано не в самой статье, а в результатах тестирования
                Выносливость новой версии Western Digital Blue 3D NAND оказалась драматически низка: этот накопитель не только не смог перенести запись заявленного в условиях гарантии объёма, но и установил новый антирекорд надёжности – 82 Тбайт.
                Значит комфорт не всем дискам одинаково полезен?
                В этой статье хорошо описывает как раз почему — очень уж «комфортные» условия работы у дисков в таких тестах по сравнению с реальными условиями эксплуатации.
                Вот и мне интересно почему. Почему он умер в таких комфортных условиях? И сколько реально проживет согласно приведенных выше поправок к методике тестирования?

                Автор проделал большую работу. Я усомнился только в однозначности выводов, имея на входе лишь предположения об алгоритмах работы микропрограммы диска. Не думаю что ценность статьи от этого уменьшилась.
            +1
            В серверах не требуется такое долговременное хранение в отключенном состоянии
            Действительно ли срок хранения зависит от того, включен ли накопитель?
              +2
              И не только, ещё и от температуры. Утечка заряда.
                0
                Ну от температуры допустим понятно. Непонятно, есть ли зависимость от состояния включено/выключено. Накопитель производит регенерацию содержимого ячеек? В этом случае должно постоянно проводиться стирание/запись (с соответствующим ростом показателей в смарте). Ведь просто от включения накопителя утечка с затвора сама по себе не прекратится (максимум сменит направление).
                  0
                  Накопитель производит регенерацию содержимого ячеек? В этом случае должно постоянно проводиться стирание/запись (с соответствующим ростом показателей в смарте).
                  Контроллер во включенном состоянии периодически «тасует» данные, чтобы избежать неравномерного износа памяти. Этот процесс обеспечивает и обновление уровня заряда ячеек.
                    0
                    Это если данные постоянно перезаписываются. А если нет?
                      0
                      Тогда должен быть очень хороший контроллер, который будет отслеживать частые чтения + RAM-буфер для кеширования.
                        0
                        Извините, не понял, что контроллер должен будет делать с отслеженными чтениями?
                          0
                          Он будет перезаписывать ячейки зачитанные почти до потери разряда данными.
              0
              Если вы иногда отправляетесь в реально длительные путешествия, а накопитель в это время не используется, то советую оставаться в рамках паспортного ресурса, по истечении которого менять накопитель.

              Т.е. если накопитель просто лежит на полке — он изнашивается? Как так?
                +1
                Он не изнашивается, но может потерять информацию из-за утечки электронов из плавающих затворов.
                Может стать нечитаемым, если пролежит слишком долго.
                  0

                  не изнашивается, а теряет информацию
                  электроны утекают из затвора и в какой-то момент заряд становится таким, что при чтении получится не тот бит, который был при записи
                  чем выше температура, тем быстрее происходит деградация
                  изношенные ячейки теряют заряд быстрее новых

                    0
                    Тогда просто перезаписать заново — и можно пользоваться дальше. Разве это повлияет на дальнейшую «износостойкость» ячеек?
                      0
                      Если сбросится область диска, где была служебная информация, то диск придётся нести в гарантию выкидывать.
                        0
                        В статье 3DNews, которую вы обсуждаете, есть ссылка на спецификацию JEDEC
                        Иными словами, если речь идёт о новом SSD, то данные на нём в выключенном состоянии могут храниться годами (при обычном диапазоне температур). И лишь когда речь заходит о накопителе, который уже выработал установленный производителем ресурс, указанные в спецификации «сроки хранения» начинают приобретать какой-то смысл. То есть, 52 недели (год) – это тот минимальной период времени, в течение которого обычный потребительский накопитель обязан по спецификации сохранять данные в выключенном состоянии после того, как он уже выработал весь определённый в спецификациях ресурс.

                        Они ошибаются? И вас есть инфа от производителей что жизненно важная для диска «служебная информация» хранится в ненадежной памяти? Логичнее хранить служебную информацию в контроллере, его память гораздо надежнее.

                        Если вы иногда отправляетесь в реально длительные путешествия, а накопитель в это время не используется, то советую оставаться в рамках паспортного ресурса, по истечении которого менять накопитель.

                        Что значит определение «паспортный ресурс»? Объём данных, на запись которого производителем рассчитан диск? Тогда совсем непонятно как перерывы в использовании окажут влияние на то, сколько данных можно записать после окончания «паспортного ресурса».

                        Меня, как похоже и автора вопроса, очень интересует такой момент — после включения питания заряд в ячейках, потерянный при хранении, восстановится? И что мешает ему теряться при наличии питания? Поясните пожалуйста.
                          0
                          То есть, 52 недели (год) – это тот минимальной период времени, в течение которого обычный потребительский накопитель обязан по спецификации сохранять данные в выключенном состоянии после того, как он уже выработал весь определённый в спецификациях ресурс.


                          Нет противоречия. Паспортный ресурс — это одно, а когда он перевыбрал ресурс в 10 раз, то там и дня может не прохранить.

                          Логичнее хранить служебную информацию в контроллере, его память гораздо надежнее.


                          Это при условии, что контроллер обладает такой памятью. Экономически это будет дороже. Почему-то в процессоры не встраивают, как правило, такую память.

                          Тогда совсем непонятно как перерывы в использовании окажут влияние на то, сколько данных можно записать после окончания «паспортного ресурса».


                          Мысль была в том, что если диск рассчитан на 50ТБ, а на него записали 200ТБ, то надолго такой винт без питания лучше не оставлять. Он может потерять всю информацию.

                          Меня, как похоже и автора вопроса, очень интересует такой момент — после включения питания заряд в ячейках, потерянный при хранении, восстановится?


                          Он утеряется безвозвратно, кроме случаев, когда массив построен по схеме рейда и другие микросхемы сохранили заряд.

                          И что мешает ему теряться при наличии питания?


                          При массированном чтении одной ячейки (сотни тысяч раз) заряд утекает.
                          Периодическая перезапись, которую делает сборщик мусора или иные алгоритмы.

                          У нового диска срок хранения заряда примерно равен гарантии или несколько выше.
                            0
                            «Мысль была в том, что если диск рассчитан на 50ТБ, а на него записали 200ТБ, то надолго такой винт без питания лучше не оставлять. Он может потерять всю информацию.»
                            Вот теперь понял мысль. Спасибо!
                  0
                  «При типичной температуре 50℃ эксплуатации под нагрузкой накопитель должен обеспечивать 58 недель ≈ 1 год хранения данных в отключенном состоянии при 25℃.»

                  Вопрос: если накопитель находится во включенном состоянии, то заряд не утекает? У меня сложилось впечатление, что при записи данных, в ячейки либо загоняется определённое количество электронов либо сливается всё (для простоты возьмём SLC). И далее ячейка держит этот заряд, а, поскольку затвор не «герметичен», заряд утекает. И независимо от того, есть ли напряжение на контроллере или нет.

                  Таким образом вопрос сводится скорее к «как происходит рефреш в ячейках?» — как в DRAM, с некоторой периодичностью или методом «очистить блок, записать заново»?
                    0
                    Думаю, этот процесс совмещён с борьбой против неравномерного износа памяти. Т.е. контроллер периодически тасует данные, чтобы не допустимть ситуации, когда, упрощённо говоря, где-то в одном месте протрётся «дырка», после чего весь накопитель можно будет выкинуть. Заодно и рефреш делается.
                      +1
                      Думаю, этот процесс совмещён с борьбой против неравномерного износа памяти. Т.е. контроллер периодически тасует данные, чтобы не допустимть ситуации, когда, упрощённо говоря, где-то в одном месте протрётся «дырка», после чего весь накопитель можно будет выкинуть.

                      В гонке за производительность и за сохранение ресурса, микропрограммы NAND накопителей не увлекаются перезаписями статичных данных к которым нет никаких обращений. Они лежат мертвым грузом и блоки занимаемые ими не участвуют в ротации.

                      В итоге в DR лабораториях частые гости SSD которые были заполнены большим количеством статичных данных и в активной ротации блоков принимало участие слишком малое число блоков отчего и возник износ отдельных областей NAND памяти.

                      Кроме этого в АТА стандарте как-то не особо предусмотрена коммуникация ОС и SSD на предмет того, что грядет в ОС (например планируемое отключение). В связи с чем самовольные перезаписи в неудачные моменты — это дополнительные риски отказа устройства, которые заметно выше рисков получения нечитаемых данных из-за утечек зарядов.
                      0
                      После нескольких сот тысяч чтений заряд в любом случае теряется. Поэтому страница очищается, а данные записываются в другое место.

                      Не факт, что это реализовано во всех ссд. Думаю, что при активном сборщике мусора подобные записи происходят сами по себе.
                        +1
                        После нескольких сот тысяч чтений заряд в любом случае теряется.
                        Исходя из чего вы решили что он теряется при чтении «в любом случае»? И откуда данные про «несколько сот тысяч»?

                        Просто интересно, насколько я знаю, в микроконтроллерах используется подобная электрически перепрограммируемая память для прошивки и хранения данных. И без каких либо «обновлений» там годами производится несколько «сот тысяч чтений» в секунду. И ни один известный мне производитель не устанавливает ограничение на число чтений. Только на циклы стирание-запись и хранение.
                          +1
                          EEPROM — это совершенно другая память.
                          Везде, где для хранения информации используются электроны в плавающем затворе, есть этот феномен. Изучайте. А вот научная работа на эту тему. Там говорится, что после 50 000 чтений из одной ячейки уже данные теряются. Умные контроллеры с этим борются, перезаписывая информацию, применяя контрольные коды, схемы а-ля рейд.
                        +1
                        «При типичной температуре 50℃ эксплуатации под нагрузкой накопитель должен обеспечивать 58 недель ≈ 1 год хранения данных в отключенном состоянии при 25℃.»

                        Вопрос: если накопитель находится во включенном состоянии, то заряд не утекает?
                        Год при условии если накопитель уже выработал свой ресурс. Бытовой накопитель.

                        А что ему мешает утекать при поданном питании? Контроллер, когда ему нефик делать, многократно читает и сравнивает записанные данные. При частичной потере заряда чтение нестабильное. Дальнейшие действия на его усмотрение. Питания нет — проверять некому… я так думаю.
                        <Таким образом вопрос сводится скорее к «как происходит рефреш в ячейках?» — как в DRAM, с некоторой периодичностью или методом «очистить блок, записать заново»?
                        Думаю с некоторой периодичностью методом «очистить блок, записать заново». А разве есть другие варианты?
                        0
                        Лирическое отступление.
                        Насколько я понимаю, всё написанное в статье относится по большей части к накопителям, выработавшим паспортный ресурс. Ну или вплотную к этому приблизившимся. Для типичного случая эксплуатации SSD в пределах заявленного ресурса ничто из этого не актуально.
                        В самом деле, рядовой потребитель, приходя в магазин за SSD, понятия не имеет ни о тестах на 3dnews ни, тем более, об утечке электронов из ячеек:) Возможно, он что-то где-то слышал об ограниченности ресурса такого накопителя, но не факт. Так же, нигде в приложенных к диску бумажках ничего не написано о возможности потери данных в случае длительного отсутствия питания на диске. За последнее, впрочем, не ручаюсь, не читал полностью:) Он знает, что гарантия на накопитель — столько-то лет. Те, кто полюбознательнее прочитают еще про TBW. Ну а фирменная утилита, если что не так, подскажет что делать.
                        Возвращаясь к теме тестов выносливости — посмотрите на цифры. В 99% процентах случаев, в домашних условиях, пользователь не то что выработает паспортный ресурс за срок гарантии, а даже не приблизится к этому. Я уже несколько лет смотрю смарты побывавших у меня дисков и вижу, что это так и есть. Где-то попадалась цифра и у меня так же получалось, что среднестатистический пользователь пишет на SSD около 20 гигов в день. Считайте сами… Так что все эти петабайты в тестах не более, чем повод гордиться производителю. И, будь у меня Самсунг 850-й про и я каким-то образом умудрился бы выработать паспортный ресурс, то вряд ли меня бы сильно вдохновляло то, что в тесте 3dnews на него записали 7 петабайт. Никто ведь не обещает, что то, выдержал один экземпляр, должны выдержать все остальные…
                          0
                          рядовой потребитель, приходя в магазин за SSD, понятия не имеет ни о тестах на 3dnews

                          Мне все уши этими тестами прожужжали. Почти в каждой статье (или в комментах к статье) про SSD на Хабре есть ссылка на эти тесты.

                          относится по большей части к накопителям, выработавшим паспортный ресурс

                          Не совсем так. Дело в том, что паспортный ресурс определяется (методика JEDEC) при заполненности диска в 38%. Если же забить диск на 95% и качать 4К-торренты, то WAF будет около 9.7, что примерно в 6.5 раз превышает WAF при тестировании паспортного ресурса.

                          Приведёт ли это к проблемам — не знаю. Возможно. Во всяком случае скорость точно упадёт.

                          Наверное, это звучит странно, но по моему опыту торренты существенно быстрее качаются на SSD)
                            0
                            Что ж тут странного, SSD на то и есть, чтобы быть быстрее HDD. Железный конь пришел на смену крестьянской лошадке (с) Но по моим наблюдениям, тормоза при скачивании торрентов на hdd имеют место только в начале, когда клиент резервирует место на диске под скачиваемые файлы. Потом же никаких затыков нет, раскидать 10-11 МБ/с (при 100 мбит/с канале) на несколько файлов под силу даже hdd) А вот если канал будет мегабит на 500, тогда не уверен, что он справится.

                            Возвращаясь к WAF и TBW. В смарте SSD есть всем известный параметр «Total host writes», насколько я понимаю это и есть тот параметр по которому отслеживается ресурс. Так вот, в этой цифре учтен WAF или это тупо объем данных, переданных накопителю операционкой для записи? Если, например, я в одном случае отправлю туда 100Gb с WAF 1, а в другом с WAF 30 — на сколько увеличится показатель? Если не учитывает, то получается ерунда, если учитывает, то тестирование на 3dnews вполне корректно и показывает физическую живучесть памяти SSD.
                              +1
                              У 3dnews тест построен так, что WAF ≈ 1. Поэтому Total Host Writes в случае 3dnews будет верным по-любому.
                              +1
                              Мне все уши этими тестами прожужжали. Почти в каждой статье (или в комментах к статье) про SSD на Хабре есть ссылка на эти тесты.

                              Вы точно не рядовой потребитель) Под рядовым я подразумеваю пользователя т.н. «игрового компьютера», в котором всё светится разными цветами и для которого выпускают SSD с подсветкой. Недавно видел какой-то обзор, среди недостатков SSD было указано «недостаточно гибкое управление подсветкой»))) Ну не бред?..
                                0
                                С торрентами есть проблема даже на 100 мбит, если много раздач качаеся. Тогда диск начинает трещать. Если чел может себе позволить 500р тратить в месяц, то 500мбит — это в Москве сплошь и рядом.
                                  +1
                                  Почти во всех торрентах от 10 ГБ размер куска от 4 МБ, в крайнем случае 2 МБ. 100 Мбит/с позволит качать где-то 3 таких куска в секунду.

                                  Обычный диск при этом может иметь до 100 IOPS, что намного выше 3 кусков.

                                  Но с SMR-дисками всё сложнее, я потом напишу статью.
                                    0
                                    The most common sizes are 256 kB, 512 kB, and 1 MB.

                                    Источник.

                                    Если качаются параллельно 2 куска, то головки диска прягают от одного куска к другому и получается трэш. У типичного ноутбучного HDD размер сектора всего 512 байт.

                                    У меня когда файлов 5 загружались (сериал, каждая серия ≈750MB) уже трешить начинало на HDD Seagate 2TB sshd.
                                      0
                                      Разве в торрент клиенте нет буфера в памяти, чтобы сгладить эти прыжки?
                                        0
                                        Если файл большой и скорость высокая, то любой буфер заканчивается очень быстро.
                                          0
                                          Буфер позволяет не скакать туда-сюда головкам диска на каждый блок и писать непрерывно — у меня десятки раздач с диска и я не слышу треска головок постоянного.
                                            0
                                            У меня головки трещат при массированных закачках, а не на раздачах.
                                              0
                                              А какая разница — читать с диска данные и писать на него для магнитных дисков разница не такая уж существенная.
                                              У меня не трещали и при скачивании — буферизация мюторрента видимо хорошо работает. Ну или диск у меня очень тихий
                                                0
                                                Это было на ноутбучном винте.
                                                Разница огромная: у 99% пользователей интернета канал хуже по скорости, чем у меня (500 Мбит). Поэтому они не могут так резво скачивать у меня, как я у них.

                                                В теории, конечно, могут, но на практике с таким не сталкивался.

                                                Может дело и не в канале. Я не припомню случая, чтобы в момент когда я качаю, скорость отдачи была выше, чем скорость скачки.
                                              0
                                              Так ведь речь про скачивание, а не про раздачу.
                                                0
                                                Разница крайне незначительная — скорость дисков достигла 150 МБайт/с — мало у кого торренты с такой скоростью скачиваются
                                                  0
                                                  150 мегабайт это, конечно, редкость. А вот 30 потоков разом, в сумме мегабайт 20 в секунду, вполне обычная ситуация. При этом скачиваются блоки совершенно хаотично, так что вместо линейной записи, где HDD способны на 150 (и больше) мегабайт получается случайная, где хорошо если пара мегабайт будет.
                                                    0
                                                    20 Мбайт — то есть не меньше 200 Мбит канал — большая редкость много еще где и обычной ее трудно назвать. Ну и 30 потоков — легко сначала в буфер летят, потом на диск линейно пишутся.
                                                      0
                                                      А вот и нет. Если 30 потоков, то буфер заполняется кусочками из 30 потоков, а потом всё пишется в 30 разных кусков (если ФС нефрагментирована), или в 300, если фрагментирована.

                                                      И ещё всё зависит от устройства торрент-клиента. В нём может принудительно вызываться запись на диск минуя буфера при завершении скачивания торрент-блока.
                                                      The most common sizes are 256 kB, 512 kB, and 1 MB.
                                +2
                                Возвращаясь к теме тестов выносливости — посмотрите на цифры. В 99% процентах случаев, в домашних условиях, пользователь не то что выработает паспортный ресурс за срок гарантии, а даже не приблизится к этому. Я уже несколько лет смотрю смарты побывавших у меня дисков и вижу, что это так и есть.
                                А у меня другая ситуация, например:
                                habr.com/ru/post/476414
                                  –1

                                  Так у вас Linux, плюс специфическая файловая система. Мне думается, вы как раз из этого 1%. )

                                +1
                                Контроллеру, чтобы записать 1 изменённый кластер приходится вначале считать всю аппаратную страницу NAND (которая может достигать сотен килобайт в размере), изменить 4КБ, а потом всю её записать. Если размер страницы NAND составляет 64КБ, то мы имеем усиление записи в 16 раз.

                                Контроллер как правило оперирует блоками, которые в свою очередь состоят из группы NAND страниц (64,128 и т.п.). Размеры страниц в NAND микросхемах обычно все же не сотни килобайт, а 528, 2112, 4224, 4320, 8576, 8640, 8832, 8896, 9216, 17664, 18048, 18336 и др. Малые размеры справедливы для старых SLC микросхем, для современных TLC размеры поболее. Такие странные размеры потому, что кроме пользовательских данных необходимо хранить служебные данные (ECC, флаги, номера блоков, счетчики записей и т. п.).

                                Как-то на достаточно простом примере показывал организацию работы NAND контроллера и NAND памяти. В современных SSD алгоритмы будут более сложными, ну суть примерно такая же.

                                Для того, чтобы SSD не превращался в коматозника при записи мелких объектов применяется буферизация, а также вводится понятие блок-апдейтов. Это блоки в которых записываются отдельные страницы для разных блоков, которые точечно накладываются на транслируемое логическое пространство.

                                Например при восстановлении данных, когда нет возможности оперировать штатными структурами транслятора обычно необходимо проводить поблочную сборку и находить отдельные блок-апдейты и накладывать их данные отдельными страничками поверх собираемого поблочно для получения актуальных данных.

                                Если производитель догадался сделать первые несколько ГБ диска (где находится битовая карта диска, FAT и прочие метаданные) работающими в режиме SLC (или кеширует их в буфере RAM),

                                принцип работы таков: любой физический блок в логическом банке, может выполнить любую роль в реализуемым этим банком логическом пространстве. Посему нет отдельных блоков для метаданных файловых систем. Слишком их много, чтобы учитывать все разновидности. Алгоритм выравнивания износа сводится к анализу счетчиков записей в блоки, которые могут быть как в структурах транслятора, так и в служебных данных в самих страницах блока. При изменении содержимого блока у которого значение счетчика записей заметно больше, чем у свободных блоков выберется новый блок с наименьшим значением.

                                В буфер попадает все то, что часто используется. Но оно все равно оперативно пишется в NAND. Либо целиком блоками, либо блок-апдейтами. Если бы просто держать данный в RAM и не особо торопиться с обновлением их в NAND, то первое внезапное отключение питания приводило бы к катастрофической потере данных (в первую очередь серьезные потери в метаданных файловой системы). Микропрограмма SSD при буферизации оперирует определенными LBA диапазонами, которые часто запрашиваются и на основании этих запросов обычно выбирает, что подольше задержать в ОЗУ SSD.

                                P.S. простите, за слишком скомканный комментарий и сильное упрощение.
                                  0
                                  Информацию о реальном размере NAND-страниц добавил в статью в пункт 2.1 со ссылкой на ваш коммент.
                                  0
                                  Господа, меня лишь один вопрос волнует. Если накопитель периодически включен, но используется слабо (с него только система грузится), это считается? Или если он будет вхолостую работать, он потеряет записанные на него данные или нет (и почему)?
                                    0
                                    В вашем случае в течение гарантийного срока на винт данные точно не потеряются.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое