musor писал(а):слет разметки зон кристала
что это?
musor писал(а):для этого чипу придется отпаять и сунуть в дорогуший NAND програмер с не мене дорогим сокетом...
ну, если головы нет, то оно так. Флеш чаще всего eMMC, там восемь выводов шина данных, что-то вроде SPI для команд (то есть четыре пина), Reset и VCC с GND. 15 проводков припаять. В девайсах, где на плате места много, все эти сигналы бывают на тестпоинты выведены, а добрые люди публикуют распиновку тестпоинтов в интернетах. То есть, даже отпаивать чип нужно не всегда.
Повторюсь, в медиаплеерах на Android нет аккумулятора. Питание с них дёргают как попало - это штатная эксплуатация для них. Ну, бывает, слетает прошивка. Но редко.
Dik13 писал(а):это вы AXX может и не знаете(а может и назовёте причину, эффект)
а кто вас ещё научит-то кроме меня?
Флеш состоит из блоков. Записать можно только блок целиком. Очень грубо говоря, у блока один большой конденсатор, который нужно зарядить, чтобы блок стереть, и новую информацию в него записать. (При записи информации из единиц производятся нули. Один бит из нуля в единицу поднять нельзя, только весь блок) Процесс стирания блока (зарядки этого конденсатора) занимает много времени. Размер блока у дешёвой памяти огромный. Чтобы телефон не превращался в IBM PC времён флоппи-дисков (была такая шутка: "-папа, покажи мне что такое мультизадачность в windows 95? -сейчас, сынок, только дискета доформатируется...") запись всегда идёт в свободный блок, стёртый заранее. Даже если нужно пару байт записать. И блок, куда их записали, становится занятым блоком. А потом, в фоновом режиме происходит то, что в терминологии SSD называется trim - данные из не полностью занятых блоков считываются в буфер, комбинируются так, чтобы не было занятого блока из-за двух записанных байт, стираются освободившиеся блоки, и т.д. Муторное занятие, к тому же у флеша количество перезаписей ограничено, его можно такими процедурами легко протереть до дыр. По этому операции записи по возможности кэшируются операционной системой (и внутри самой микросхемы памяти тоже кэш есть). Пользователь штука такая, куча суетливых действий, а результат как правило нулевой
И записывать реально во флеш ничего не нужно. Экономится ресурс накопителя, и время. Но если вырубить питание - кэш теряется. И получается иногда (относительно редко), что программа записывала какую-то информацию о своём состоянии на диск. Половина записалась во флеш, а половина в кэше была. И после того, как питание восстановилось, и операционка загрузилась, программа испытывает сложности с восстановлением предыдущего состояния. "Глючит", если по-простому
В качестве примера придумал вот такую ситуацию: есть приложение-плеер медиафайлов. Проигрывает оно себе плейлист. Доходит до конца очередного файла. И нужно ему записать на диск в одном каком-то месте, что файл теперь следующий проигрывается. И в другое какое-то место сохранить отметку времени, на которой файл проигрывается. И вот информация о том, что теперь проигрывается другой файл, сохранилась на флеш. А информация о времени не сохранилась, осталась последняя - конец предыдущего файла, час-сорок. А в новом файле длина медиа час двадцать. При запуске медиа-плеера он попытается восстановить точку, в которой он завершил работу. Считает новый файл, и попытается перейти в нём на отметку времени час сорок. Возникает, некоторым образом, пердимонокль. А если отметка времени попадает в размер нового файла, он его начнёт проигрывать с этой отметки, как будто он там остановился. И не сможет
musor посмотреть 100500-й эпизод любимого сериала про милиционеров.
А если питание вырубилось в тот момент, когда работала программа, которая trim осуществляет, и с восстановлением её состояния возникли проблемы - тогда вместо trim может произойти неопределённый процесс (undefined behaviour, или "неведомая хреновня" по-русски). В том числе, и потеря таблицы разделов диска. Но вероятность этого события крайне низкая.