> Только не говорите, что флэшки очищаются после перезапуска.Нет, разумеется. Перезапуски тут не при чем. Флеш - крупноблочная память. При стирании огромный блок выставляется в дефолтное состояние. Например, "все 1" aka заполнение 0xFF (NOR) или "все 0" aka заполнение 0x00 в случае NAND.
Далее возможна более гранулярная запись нужных значений путем записи в отдельные биты или хотя-бы относительно мелкие страницы. Сие позволяет делать запись сравнительно мелкими порциями и если некто хочет записать что "foo = 2", то он может пойти и записать это. Затронув только нужные байты (или накрайняк 1 страницу на пару кило). Но есть одна проблема. Возможен переход битов только в одну сторону. В обратное (стертое) состояние биты возвращаются только erase всего огромного блока и никак иначе. Т.е. однажды чего-то записав в ячейку, произвольное значение в ту же ячейку уже не удастся положить. Но чисто технически - можно далее щелкать битами которые в "стертом" состоянии, переводя их в "запрограммированное". Отсюда вытекает возможность сделать ход конем: чтобы не стирать флеш на каждый пук, можно завести битовое поле которое показывает: валидна ли запись "foo=2" или нет. И писать его рядом с самой записью. Когда некто записал "foo=11", запись "foo=2" никуда не девается. Вместо этого в битовом поле статуса записи допрограммируются биты показывающие что запись более недействительна и далее ее все игнорируют. А запись "foo=11" допрограммируется в незапрограммированные ячейки рядом. Такой вот copy-on-write поневоле. Но разумеется наступит момент когда сектор забит до отказа и более некуда copy-on-write'ить. В этот момент (или ранее) надо сделать проход по сектору, собрать все валидные записи, пропустив все невалидные. Сделать erase сектора (все биты станут незапрограммированными) и впрограммировать все валидные записи. Сама по себе эта механика столь проста что ее делают даже на микроконтроллерах. Это совершенно обычный подход к хранению конфигурации и тому подобного во флеше который прицеплен "напрямую". А вот облажаться в этом - самсунь жжот!
> Трим имели ввиду? Это ни разу не сборщик.
Трим тут вообще не при чем - флеха BIOS прицеплена "напрямую" в том плане что там нет отдельного аппаратного контроллера который бы делал wear leveling и GC. Поэтому все это ложится на плечи системного фирмваре. Внезапно, да? Для конфигурационных переменных это делается в самой простейшей форме и как самсунь там смог так накосячить - вообще не понятно. До сих пор никто так люто не лажался в столь общеупотребительных механизмах.
