Всем известно легендарное тестирование 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 (консорциум производителей флэш-памяти).
И ОС, и контроллер (если у него есть небольшой DRAM-кеш) группируют последовательные блоки идущие на запись и записывают большими нативными блоками, свойственными конкретному устройству. При этом практически отсутствует усиление записи и практически нет необходимости в алгоритмах выравнивания износа.
В реальных условиях, как фактор мультипликации, так и качественная реализация алгоритма выравнивания износа имеют сильное влияние на ресурс накопителя.
Проблема 1. При последовательной записи файлов WAF ≈ 1
Тест, который построенный так, чтобы свести к единице фактор мультипликации записи, будет предсказуемо давать завышенные результаты по ресурсу. Далее выясним насколько именно.
Проблема 2. Не тестируется качество алгоритма выравнивания износа
При последовательном заполнении диска и последующем стирании плохо тестируется механизм выравнивания износа. Если производитель догадался сделать первые несколько ГБ диска (где находится битовая карта диска, FAT и прочие метаданные) работающими в режиме SLC (или кеширует их в буфере RAM), то алгоритм выравнивания износа может полностью отсутствовать в прошивке и всё равно при последовательной записи будeт достигнуты отличные показатели ресурса.
Проблема 3. Не тестируется срок хранения данных после исчерпания ресурса
Если вы уезжаете в путешествие на несколько месяцев, то непонятно можно ли доверять диску, который выработал свой паспортный ресурс.
Проблема 4. Последовательное заполнение диска, с последующим практически полным стиранием, не является реальным пользовательским шаблоном поведения
Поскольку SSD — это ещё довольно дорогой ресурс, то люди обычно стараются его использовать максимально полно и оставляют минимум свободного места.
Идеальный тест, на мой взгляд, это чтобы во время тестирования SSD оставался забитым на 80-90%, при этом в случайном порядке старые файлы должны удаляться, а новые добавляться.
2. Факторы мультипликации записи
2.1. Фрагментация файловой системы
Так как в Windows у SSD отключена дефрагментация, а размер кластера NTFS по умолчанию составляет 4КБ, то в реальной жизни диск сильно фрагментируется. В этом случае даже последовательная запись превращается по скорости практически в случайную.
Контроллеру, чтобы записать 1 изменённый кластер приходится вначале считать всю аппаратную страницу NAND (которая может достигать сотен килобайт в размере), изменить 4КБ, а потом всю её записать. Если размер страницы NAND составляет 64КБ, то мы имеем усиление записи в 16 раз.
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 есть резервная область, в которую также происходит перераспределение записи. Но, как правило, она невелика.
В случае заполненности диска на 90% и наличии скрытой области размером в 6.66% (диск 120ГБ, реальное количество флэш-памяти 128ГБ), WAF будет равен 6.4!
WAF может оценён по этой формуле:
$$display$$begin{equation} WAF_{сборки мусора} = frac {1} {1 - frac {K_{заполненность диска}} {K_{резервной области}}} end{equation} $$display$$
Kзаполненность диска — от 0 до 1, где 1 — 100% заполнение диска.
Kрезервной области — от 1, где 1 — 0% резервная область, 1.1 — 10% резервной области, и так далее.
Приблизительный график зависимости WA от процента свободного места на диске.
Из графика видно, что WA катастрофически нарастает по мере заполнения диска, приближаясь к 16 при полном заполнении диска с резервной областью 6.66% (типовой размер для потребительских дисков).
Вы, наверное, сами замечали как сильно начинает тормозить телефон, если там оказываются считанные единицы процентов свободного места. Ведь в нём тоже используется флэш-память. Забивать память под 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КБ.
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, который вносит алгоритм сборки мусора, то простить нельзя.
Методика 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 |
Расчёт поправок к результатам тестирования 3dnews
Нам нужны поправочные коэффициенты для того, чтобы износостойкость по методике 3dnews преобразовывать в износостойкость по методике Jedec.
Для начала мы уменьшим достигнутый результат в 2 раза, так как в тестировании не проверялось долговечность хранения. Никто не хочет обнаружить, что после отпуска, накопитель в его компьютере перестал работать или покрылся бэдами. Цифра 2 взята с потолка.
По методике JEDEC диск заполнен всего на 38%, что даём нам увеличение WAF из-за сборки мусора в 1.55 раза (по формуле выше). Этот коэффициент будет в знаменателе.
Далее мы учтём фактор мультипликации записи в зависимости от размера страницы NAND (полученный при анализе тестирования пользовательских SSD по методике JEDEC) и перемножим на WAF, который имеем от сборщика мусора.
$$display$$begin{equation} K_{поправки} = frac {2 * WAF_{сборка диска от заполненности} * WAF_{от размера страницы и характера записей}} {WAF_{сборка мусора Jedec}} end{equation} $$display$$
Поправочные коэффициенты для дисков с избыточной областью в 6.66%.
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 50 | 55 | 60 | 65 | 70 | 75 | 80 | 85 | 90 | 95 | 100 | |
| 2K | 2.4 | 2.7 | 2.9 | 3.3 | 3.8 | 4.3 | 5.2 | 6.4 | 8.3 | 11.8 | 20.6 |
| 4K | 2.5 | 2.7 | 3.0 | 3.3 | 3.8 | 4.4 | 5.2 | 6.4 | 8.3 | 11.9 | 20.9 |
| 8K | 2.7 | 3.0 | 3.3 | 3.7 | 4.2 | 4.8 | 5.7 | 7.1 | 9.2 | 13.1 | 22.9 |
| 16K | 3.2 | 3.5 | 3.9 | 4.3 | 4.9 | 5.7 | 6.8 | 8.3 | 10.8 | 15.5 | 27.1 |
| 32K | 5.0 | 5.5 | 6.1 | 6.8 | 7.7 | 9.0 | 10.6 | 13.1 | 17.0 | 24.3 | 42.6 |
| 64K | 8.6 | 9.4 | 10.4 | 11.7 | 13.3 | 15.4 | 18.3 | 22.5 | 29.2 | 41.8 | 73.2 |
| 128K | 15.8 | 17.3 | 19.2 | 21.5 | 24.4 | 28.3 | 33.6 | 41.3 | 53.7 | 76.7 | 134.3 |
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
Поправки к результатам тестирования 3dnews для использования пользовательских SSD в серверах
Сразу скажу, что это плохая идея. Но многие так делают. Поэтому попробуем рассчитать поправочные коэффициенты для определения ресурса пользовательских дисков в качестве серверных. Мы берём износостойкость из тестирования 3dnews и делим её на нужный коэффициент, чтобы получить ожидаемый ресурс (методика JEDEC) при корпоративном применении.
В серверах не требуется такое долговременное хранение в отключенном состоянии, как в пользовательских SSD. Вот соответствующая таблица:
При типичной температуре 50℃ эксплуатации под нагрузкой накопитель должен обеспечивать 58 недель ≈ 1 год хранения данных в отключенном состоянии при 25℃.
Для пользовательского применения (где требуется сохранность данных в течении 2-х лет в отключенном состоянии) мы уменьшили ресурс в 2 раза. Для корпоративного применения не нужен такой большой срок хранения, поэтому мы возьмём меньшее число, например, 1.3.
После этого умножим на WAF, характерный для корпоративной нагрузке, а потом учтём работу сборщика мусора и получим следующие таблицы коэффициентов. Результат полученный 3dnews нужно разделить на это число.
Есть проблема с тем, что в стандарте не описывается размер резервной области или свободного места для корпоративных дисков. Поэтому мы не можем точно оценить WAFкорпоративного теста JEDEC, поэтому возьмём это число (1.55) из теста пользовательских SSD JEDEC.
Поправочные коэффициенты для дисков с избыточной областью в 6.66%.
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 50 | 55 | 60 | 65 | 70 | 75 | 80 | 85 | 90 | 95 | 100 | |
| 1K | 1.8 | 2.0 | 2.2 | 2.4 | 2.8 | 3.2 | 3.8 | 4.7 | 6.1 | 8.7 | 15.2 |
| 2K | 2.0 | 2.2 | 2.4 | 2.7 | 3.1 | 3.6 | 4.2 | 5.2 | 6.8 | 9.7 | 16.9 |
| 4K | 2.4 | 2.6 | 2.9 | 3.3 | 3.7 | 4.3 | 5.1 | 6.3 | 8.2 | 11.7 | 20.4 |
| 8K | 3.2 | 3.5 | 3.9 | 4.4 | 5.0 | 5.8 | 6.9 | 8.5 | 11.0 | 15.7 | 27.5 |
| 16K | 4.9 | 5.4 | 5.9 | 6.7 | 7.6 | 8.8 | 10.4 | 12.8 | 16.6 | 23.8 | 41.6 |
| 32K | 8.2 | 9.0 | 10.0 | 11.1 | 12.7 | 14.7 | 17.4 | 21.4 | 27.9 | 39.8 | 69.7 |
| 64K | 14.8 | 16.2 | 18.0 | 20.1 | 22.9 | 26.5 | 31.5 | 38.7 | 50.4 | 72.0 | 126.0 |
| 128K | 28.0 | 30.8 | 34.0 | 38.1 | 43.3 | 50.2 | 59.6 | 73.3 | 95.4 | 136.3 | 238.6 |
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
| заполненность диска, % | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 |
Выводы
Если вы никогда вы не выключаете свой компьютер на несколько месяцев, размер страницы NAND не более 16КБ, и диск заполнен примерно на половину, то показатели ресурса достигнутые 3dnews нужно разделить на 3.
Для типового сценария (занятость диска 90%, размер страницы 8КБ), чтобы получить ресурс по стандартам JEDEC, делим на 9 ресурс, полученный 3dnews.
Если вы иногда отправляетесь в реально длительные путешествия, а накопитель в это время не используется, то советую оставаться в рамках паспортного ресурса, по истечении которого менять накопитель.
Для редких случаев, когда размер страницы NAND больше 16КБ, а диск довольно плотно заполнен, то чтобы вычислить реальный ресурс накопителя, его нужно уменьшать в десятки, а иногда в сотни раз.
А если вы засовываете бюджетный накопитель в сервер, то озаботьтесь и рейдом, и бакапом. У вас не будет стабильного времени отклика и скоростей, защиты по питанию и других плюшек корпоративных накопителей, но ресурс вы можете вычислить с помощью поправочных делителей из соответствующей таблицы статьи. В типовом случае делим на 11.
Ссылки
Optimizing Linux with cheap flash drives.
Как определяем размер страницы и блока флэш-памяти.
P.S. Замеченные ошибки направляйте в личку. Повышаю за это карму.
За изображение спасибо TripletConcept.
Вы можете заказать виртуальную машину с SSD у RUVDS по купону ниже.
Автор: Сергей Ю. Каменев
