Намедни меня очень заинтересовал вопрос касательно оптимального способа выделения ёмкости для резервной области SSD c целью «получить побольше IOPS по записи от Crucial CT1000MX500SSD1 и Kingston SH103S3/120G». Используются для виртуальных машин и игр. Прочитал тут пару древних тредов, в которых было упоминание такого критерия как over-provisioning (далее ОР). О, да я в этой теме «плаваю», появились вопросы... Следом пошла эта статья на хабре и английская википедия (pdf-вложения под индексами [19] и [21] оказались особенно интересными).
Правильно ли я понял, что массивы памяти SSD ЛЮБОГО производителя, во время их изготовления на заводе, при измерении ёмкости ВСЕГДА используют двоичный тип адресации? Т.е. ЛЮБОЙ SSD с пользовательской ёмкостью 1000 ГБ на самом деле имеет на борту 1000 ГиБ (что эквивалентно 1000 * 1.073741824 ≈ 1073.74 ГБ), т.е. ВСЕ, без исключения, терабайтники щеголяют дополнительной резервной областью величиной в 7% от пользовательской ёмкости. Так ли это? В даташитах - тишина. И используется ли она именно для ОР, т.к. служебных нужд еще полно: коррекция ошибок, замена бэд-блоков...
А не может ли случиться так, что производитель заранее поместит на свою плату массив такого объёма в ГиБ, который будет тютелька в тютельку соответствовать заявленному объёму в ГБ? Ведь тогда никакой резервной области для ОР быть не может.
Существует ли способ узнать полную ёмкость массива ячеек (она же рhysical сapacity, она же raw capacity) программным способом из под ОС, программатором, чтобы проверить этот дополнительный процент:
Percentage Over-provisioning = (Physical Capacity - User Capacity) / User Capacity.
Следующая цитата от ребят из Kingston также повергает в раздумья:
«The OP capacity set by the SSD manufacturer can vary in size, depending on the application class of the SSD and the total NAND Flash memory capacity.»
«Тotal NAND Flash memory capacity» неизвестна так же как «OP capacity» - ни в одном из нагугленных даташитов, для SSD от Kingston или Сrucial, нет упоминаний о данных критериях. А хде пра них можна узнать хоть што нибуть? Графические и консольные утилиты от производителя бесполезны: они показывают только тот процент объёма ОР, который выделяется из пользовательского пула (манипуляции с переменной MAX_LBA_ADDRESS). В этом источнике написали, что у крушиала таки есть 24 дополнительных гигабайта (а точно ГИГА, а не ГИБИ? а? а?) предназначенных для ОР, но он неофициальный. В основном же производители рекомендуют «откусить побольше от пирога пользовательской ёмкости и все станет хорошо».
Вот только после всего прочитанного я теперь жадный и хочу вести расчет по следующей схеме: та самая ёмкость от разницы в системах измерения + возможная дополнительная ёмкость для OP предусмотренная самим производителем + ёмкость выделенная из пользовательского пула лично мной = требуемый % от общей ёмкости массива ячеек (пусть будет 15% для примера).
GParted сообщает, что мне доступно для разметки 931.51 ГиБ (1000 ГБ, все верно). Отдавать 15% от них -
это ≈139.7 ГиБ (≈150.03 ГБ) - что-то дюже жирно. Если бы не прочёл выше упомянутые источники - отдал бы, а так... Что получается? (1024 - 931.51) / 931.51 ≈ 10 % (а это ≈92.49 ГиБ) уже есть, тогда от пользовательского пула нужно выделить всего 5 % ёмкости, а не все 15. Т.е. всего ≈46.58 ГиБ (≈50.01 ГБ), что значительно меньше. И это ещё не учтена возможная дополнительная ёмкость от производителя, о которой ничего не известно (снова тот же вопрос: где документальные или эмпирические подтверждения её наличия или отсутствия? я плохо гуглил? просветите меня в таком случае, будьте добры) - тогда, в ряде случаев, может получиться так, что и выделять ничего не надо вовсе.
Прошу подтвердить или опровергнуть правильность рассуждений. Ссылки на источники и особенно даташиты очень приветствуются.
Спасибо за внимание.
