Здравствуйте, коллеги.
Имеется полтора года отработавший в качестве системного диска под Win10 MSI Spatium M480 2TB HS (не PRO) на Phison PS5018-E18 и Micron B47R (176 layers) который начал показывать очень странные результаты: система стала катастрофически долго загружаться. Perfmon показал, что скорость чтения упала до 10-30 Мб/с, отклик стал достигать миллисекундных значений и занятость под 100%.
Сразу предупрежу: Windows, вирусы/майнеры и прочая эзотерика тут не причем и советов "почистить реестр" или "проверить на вирусы" давать не стоит.
Данные были оффлайново слиты при помощи dd в сторонку по ssh, при этом скорость также не поднималась выше ~30Мб/c при свободной гигабитной сети. Правда тут могло упираться ssh, т.к. на приемной стороне CPU не умеет в аппаратное шифрование. Вся процедура заняла больше 12ти часов, подтверждая, что с SSD по чтению что-то происходит не так.
SMART был в норме: при 2800 часах работы записано 12.6Тб, процент использования - 1%, error log entries - 640.

Встал выбор: нести в гарантию, но год гарантии продавца уже прошел, а MSI Russia про такой SSD ничего не знает вообще, видимо 2Tb официально не поставлялись. Кроме того - на диске частные данные. Поэтому было принято решение очистить диск, причем не с использованием secure erase а "варварски" залить нулями. Заливка длилась около 4х часов, скорость ~140Мб/c, но это в один поток и без указания размена блока для dd (тупо забыл). После этого в SMART увеличились часы, записано стало 14.6Тб, error log entries - 672.

Но и чтение тоже выправилось: dd мегабайтными блоками в /dev/null вычитал диск за 36 минут (880Mб/c). И основание обращаться в гарантию заодно тоже
Гугление вывело на сообщение на форуме overclock.net и на тред в Reddit вокруг того же сообщения. Авторы утверждают, что подобное поведение получается из-за бага в прошивке и выпущенная Kingston'ом EFIK31.7 исправляет это.

Я нашел и эту прошивку и инструменты уважаемого коллеги vlo. У меня прошивка EIFM31.4, в архивах есть еще 2 разных EIFM31.6, но в треде написано, что и на 31.6 наблюдается проблема с чтением. Судя по букве К, кингстоновская прошивка под флеш Kingston (или Kioxia?), тогда как у меня - Micron и буква М в прошивке. Шить одно в другое, как я понимаю, нельзя. От MSI добиться чего-либо бесполезно, никаких апдейтов нет ни на российском, ни на международном сайте.

Вопрос:
- есть ли шанс, что Phison или кто-то из вендоров выпустил гипотетическую EIFM31.7 c фиксом?
- есть ли она у кого нибудь?
- чем и как шить? Для тренировки могу попробовать обновиться до какой-нибудь из имеющихся EIFM31.6

PS: У Кингстона в архиве, кроме бинарника EIFM31.7, лежат еще прошивки bridge_1 и bridge_2 упомянутые в task.ini, что говорит нам, что обновление не делается за один заход, т. к. требуются промежуточные прошивки. Весело...

megov
Судя по букве К, кингстоновская прошивка под флеш Kingston (или Kioxia?),
Нет, это значит, что прошивка от Кингстона.

у меня - Micron и буква М в прошивке.
Буква М - это универсальная прошивка. Тип памяти определяется цифрами (31).

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

есть ли шанс, что Phison или кто-то из вендоров выпустил гипотетическую EIFM31.7 c фиксом?
Погуглите. Пока не ищется.

Спасибо за разъяснение по кодам прошивок.

Окирпичть не боюсь, но про аварийные варианты восстановления где-нибудь прочесть хотелось бы.
Замыкания перемычек, подпайка UART не пугают. C JTAG посложнее
Пока, правда, не понимаю, чем шить. :/Дык, гуглил. С тем же отрицательным результатом, на данный момент.

вроде бы EIFM31.6_08032023.BIN самое свежее, что встречалось кроме кинга.
правда по внутренней нумерации есть впечатление, что кинговая 31.7 соответствует обычной 31.3. да и по размеру тоже. но возможно это ни о чем и не говорит.

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

Исправлено: vlo, 11.01.2025 00:11

Под "проблемами с флешем" имеется ввиду утечка заряда на старых записанных блоках?
Ибо, на форумах у коллег, были проблемы при чтении старых файлов (и, естественно - блоков).
В моем случае поведение похожее, но именно пофайловых замеров я не делал. В исходной системе
это был системный диск и много чего, созданного при установке, за полтора года скорее всего не менялось,
несмотря на обновления. Интересно, что при блочном вычитывании скорость тоже сильно варьировалась,
от провалов до ~10Мб/c в некоторых областях, до ~90Мб/c в конце тома.

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

PS: Вопрос в порядке собственной некомпетентности. Немного знаком с устройством и принципами хранения
для UV-EPROM, EEPROM, изначальных типов flash (тогда, когда одни были одинаковы по распиновке с ROM)
и классической DRAM. Для ROM/Flash - длительное хранение до десятков лет, для DRAM - обязательная
миллисекундная регенерация. А что сейчас со всякими [M/T/Q]LC? Хранение 4х/8ми/16ти состояний на каждом
затворе не только выводит чтение в область аналоговой схемотехники, но и должны требовать процедур
обновления/регенерации, подобных тем, что в DRAM. Ибо чтение не может быть совсем бесплатным с точки
зрения расходования записанного на затворе заряда. Или я туплю?

PS2: Коллега mrzet дал исчерпывающий ответ на мои вопросы в этом сообщении.

Исправлено: megov, 10.01.2025 23:57