Как быстро убить флешку перезаписью?

Износ ячеек памяти сильнее чем EXT 4 из-за CoW.

Я тупанул. Я думал, думал, что речь идёт про мать, проц и всё в таком духе. Про износ ячеек памяти знаю.

Подведу промежуточный итог обсуждения. Для максимально быстрого вывода флешки из строя интенсивной записью мне следовало:

• Предварительно заполнить весь доступный объем мусором, чтобы нейтрализовать алгоритмы выравнивания износа.
• Писать в разные сектора, чтобы избежать кеширования в относительно долговечном SLC- или вообще RAM-кеше. Набор секторов для записи все еще следует держать ограниченным, чтобы впоследствии проверить работу алгоритмов выравнивания износа, но секторов должно быть достаточно, чтобы нейтрализовть все рабочие зоны кеша.
• Писать в достаточно удалённые друг от друга сектора, чтобы они не попадали в одну зону кеширования.

для такого случая придумали флешки промышленного уровня (industrial)

Для какого случая? В моем требуется 1.5 GB записи в год. Правда, в неоптимальном режиме: примерно по 100 байт каждую секунду. Теоретически для этого не требуется особая и дорогая флешка, должно хватать и обычной.

Финальный вопрос должен свестись к тому, стоит ли мне использовать какую-то экзотическую файловую систему типа JFS2 и NILFS2, стоит ли самому циклически писать лог в физические сектора или же взять что-то привычное вроде ext4.

А для этого я хочу хотя бы приблизительно понимать, что реально влияет на износ флешки, а что нет, а не то что пишут в популярных статьях.

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

стоит ли мне использовать какую-то экзотическую файловую систему типа JFS2 и NILFS2

Что-то f2fs не упомянута.

Предварительно заполнить весь доступный объем мусором, чтобы нейтрализовать алгоритмы выравнивания износа.

Я замечу, что это не обязательно поможет. Ничего не мешает алгоритму выравнивания износа отслеживать адреса, в которые идёт частая и редкая запись, и перебалансировать их по мере работы. Т.е. в более изношенные ячейки копировать те данные, которые меняются редко, а те данные, которые меняются часто, перекидывать на менее изношенные ячейки.

Собственно если ОС не вызывает TRIM, то это единственный способ работы такого алгоритма.

Единственный 100% способ проверить износ ячеек, это перезаписывать все адреса. Ну или получить прямой доступ к флешу в обход прошивки.

Я замечу, что это не обязательно поможет. Ничего не мешает алгоритму выравнивания износа отслеживать адреса, в которые идёт частая и редкая запись, и перебалансировать их по мере работы. Т.е. в более изношенные ячейки копировать те данные, которые меняются редко, а те данные, которые меняются часто, перекидывать на менее изношенные ячейки.

Такой результат меня тоже устроит. Он будет означать, что теперь даже в некоторых из дешевых флешек алгоритмы выравнивания позволяют не задумываться о выборе файловой системы в контексте износа ячеек перезаписью.

Главное при интерпретации результатов этого эксперимента - не ввести самого себя в заблуждение.

Наверное, надо взять хотя бы две флешки: одну нагрузить многократной перезаписью всего объема, а другую заполнить один раз, а затем перезаписывать ограниченный набор секторов.

В той статье, из 2010 года, про которую я ранее упомянал, https://www.usenix.org/legacy/event/fast10/tech/full_papers/boboila.pdf выравнивание износа было в 512 Мб флешке. Только оно там базово динамическое (Dynamic wear leveling). В каждой зоне просто сколько-то резервных блоков/секторов и новый сектор пишется в один из них. Если заполнить все сектора зоны и всё время долбить один сектор, то он будет поочерёдно записываться в разные резервные блоки и износ «размажется» по ним. То есть это не полное выравнивание износа, но как-то работает. И чтобы быстро убить флешку нужно «угадать» размер зоны, чтобы внутри зоны долбить один сектор.

о выборе файловой системы

Ну Write amplification то остаётся, у разных ФС разное. Плюс ещё ходят слухи, что во флешках «упрочнили» область FAT-таблицы, раз большинство флешек под FAT, то для тех адресов у флешки будет больше резервных блоков.

Ничего не мешает алгоритму выравнивания износа отслеживать адреса, в которые идёт частая и редкая запись

Алгоритму может конкретно мешать возможности контроллера. На флешках и microSD карточках бывают реально очень слабые процессоры совсем крохи ОЗУ. Вполне возможно, что там до сих пор уровень ардуины — 8-бит CPU и несколько кБайт ОЗУ и какой-то очень примитивный алогоритм.

Держать связный список из отсортированных по числу записей номеров блоков и переставлять первый с последним иногда + немного статистики, чтобы делать это чаще, если нужно - много «мозгов» не надо.

Допустим, флешка 16 Гбайт, размер блока стирания 64 кБайт, получаем 250 тыс. номеров блоков. В 10 кБайт ОЗУ такой список никак не влезет, отсюда вылазят зоны, выравнивание износа только в границах зоны.

Здравствуйте, немного не по теме. У вас был опубликован цикл статей по stm32 называлось - Осваиваем STM32 снизу: 8 частей. Великолепный материал, очень любопытно и полезно, но сообщения туда сейчас закрыты, а по теме есть вопросы, вот и хотел спросить. Может как-то в личку или в тех же темах. Сам осваиваю stm32 в частности stm32f103c8t6, есть тупиковые моменты и не могу их решить. Спасибо. Моя учетка - megavoltt2024

me @ vbezhenar . com пишите, попробую помочь. Лички на лоре вроде нет.

отправил сообщение на почту.

Ответил.

Write amplification то остаётся, у разных ФС разное

Усиление записи я считаю посильной платой за выравнивание износа средствами файловой системы. Такой размен выгоден при отсутствии полноценного выравнивания износа контроллером флешки.

Если контроллер флешки выполняет полноценное выравнивание, то усиление записи выглядит вредным.

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

Плюс ещё ходят слухи, что во флешках «упрочнили» область FAT-таблицы, раз большинство флешек под FAT, то для тех адресов у флешки будет больше резервных блоков.

Полезное замечание. Вероятно, на этом основаны советы сохранять форматирование от производителя. Этим можно объяснить и быструю смерть флешек, отформатированных в другие ФС. Если производители прибегают к такому решению, значит полноценное выравнивание износа отсутствует.

убив так одну флешку никаких выводов не сделаешь. нужно несколько десятков чтоб была статистика. ведь даже из одной партии могут прожить по-разному.

убив так одну флешку никаких выводов не сделаешь. нужно несколько десятков чтоб была статистика. ведь даже из одной партии могут прожить по-разному.

По крайней мере алгоритм выравнивания износа в рамках одной модели не должен отличаться от одного экземпляра к другому. Именно он интересует меня больше всего.

отправил несколько сообщений по почте по stm32.

зачем читать после каждой записи, если цель просто угробить? Читайте после 10 записей…

Сделал проверку каждые 100 записей. Имею чуть более 300 циклов полной перезаписи в сутки. Пока все 3 контрольные суммы совпали; существенных изменений в скорости чтения и записи не обнаружено.

5000 циклов — это для TLC, вроде, во флешках ее уже не используют. А у QLC большой разброс, по разным данным от 100 до 1000.

1000 перезаписей я получу за 3-4 дня, а 5000 за 15-16. Ждать не очень долго, но это гарантированные количество циклов записи, а фактическое должно быть в несколько раз больше.

Как лучше поступить в случае, если я не обнаружу эффектов деградации за время эксперимента?

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

Есть вариант быстрый, но пока непонятный: выдержать обе флешки несколько часов при высокой температуре и сравнить чтение.

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

Поставь на (не с) неё винду и юзай эту винду, флешка сдохнет 100%.

Как алгоритм износа узнает о типе файловой системы и то что ячейки заняты полезными данными? Мне казалось там просто есть запасные - вот и всё, и оно самые изношенные заменяет из резерва

Не знаю, что посоветовать. С одной стороны, не так давно у меня появилась глючная SD-карточка, которая из телефона супруги, честно запилена за несколько лет фоточками и видео. Она дейсвительно проблемная. После форматирования телефон снова отказывается с ней работать. Я своей примитивной программой записал последовательность байт и раз в месяц считываю. И кол-во ошибочно считываемых байт не меняется за три месяца. Надо бы на уровне бит посравнивать, но пока лень.

Написл я это к тому, что, ИМХО, слухи про тотальное быстрое стекание заряда в поношеном флеше сильно преувеличины. Для этого нужны годы. То есть если делать сравнительно чтение поношеной и новой флешек, то недели, месяц, наверное, маловато, может 10-20 месяцев что-то даст. Где-то читал, что, вроде как, «текущих» ячеек мало, большинство просто пробивается, и получается, что одни держат заряд долго, а другие вобще не держат.

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

Надо просто поставить винду на флешку.

может часть прошивки лежит во флешке с данными, а не в контроллере, может при длительном нагреве что-то с пайком клеем/компаундом произойдёт

Потому и спрашиваю. Допускаю, что нет температуры, пригодной для моего эксперимента. Но пусть тогда не несколько часов, а сутки. Не уверен, что смогу найти лабораторную печь на большее время.

если делать сравнительно чтение поношеной и новой флешек, то недели, месяц, наверное, маловато, может 10-20 месяцев что-то даст … получается, что одни держат заряд долго, а другие вобще не держат

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

Как алгоритм износа узнает о типе файловой системы и то что ячейки заняты полезными данными?

О типе файловой системы он не знает. При отсутствии TRIM он не знает и о полезности данных, но допускаю, что контроллер может в сжатом виде хранить блоки, содержащие только нули (или единицы), а освободившиеся использовать в качестве резерва.

Мне казалось там просто есть запасные - вот и всё, и оно самые изношенные заменяет из резерва.

Существуют и более сложные алгоритмы. Грубо говоря, контроллер может обменивать данные между более и менее изношенными страницами, поддерживая их износ на среднем уровне. Выше была ссылка на статью.

https://en.wikipedia.org/wiki/Wear_leveling

Интересно, если вкратце, информацию об износе и карте перемещений - ее можно вычитать? Наверное драйвера SSD так и делают в ОС

нтересно, если вкратце, информацию об износе и карте перемещений - ее можно вычитать? Наверное драйвера SSD так и делают в ОС

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

Драйверов SSD, как-бы и не существет. Это обычное устройство хранения с какими-то ограничениями и багами типа размера очереди, работы TRIM и т.д. Ну ещё под винду бывает в спец. утилитах от производителя SSD, где правильно называются расшифровываются параметры SMART.

И, насколько я знаю, даже специализированые утилиты по прошивке SSD ничего не могут из подобных данных вычитать. Прошить могут, а сообщить в каком состоянии прошивка, флеш не могут.

Прошить могут, а сообщить в каком состоянии прошивка, флеш не могут

Жаль что нет SSD-ориентированных расширений для SMART

просто профиль и кэш браузера там размести

Я пробовал многократно перезаписывать MBR, но это перегревало контроллер флешки и она отваливалась, а остыв снова работала.

По крайней мере, есть атрибуты SMART специфичные для SSD. Например,

171 0xAB SSD Program Fail Count
172 0xAC SSD Erase Fail Count
173 0xAD SSD Wear Leveling Count
176 0xB0 Erase Fail Count
177 0xB1 Wear Range Delta
178 0xB2 Used Reserved Block Count
179 0xB3 Used Reserved Block Count Total
180 0xB4 Unused Reserved Block Count Total

…

Некоторые атрибуты для HDD приобрели второе значение для SSD.

Кстати, для одной 64 GB флешки у меня отображается SMART, и можно запускать short/long тесты.

Что было бы интересно, так это узнать, активен ли сейчас GC, а также ручной триггер этого процесса. Ну и из любопытства иметь возможность получить FTL-таблицу и посылать запросы RAW-блоков (хотя бы на чтение).

Но и host-managed SMR HDD доступны только для энтерпрайза.

Да, эти я видел на SSD, правда их информации очень мало, но хоть что то и это хорошо

Ага. На дискете был драйвер усб для 98 винды

Кстати, для одной 64 GB флешки у меня отображается SMART, и можно запускать short/long тесты.

иметь возможность получить FTL-таблицу и посылать запросы RAW-блоков (хотя бы на чтение).

Ищу возможность дампить все служебные данные с HDD/USB Flash/SSD в Linux, с помощью открытого ПО. Можете дать совет?

Что было бы интересно, так это узнать, активен ли сейчас GC, а также ручной триггер этого процесса.

Что это?

1000 перезаписей я получу за 3-4 дня, а 5000 за 15-16.

Готова 1000. Проверка контрольной суммы выполнялась каждые 100 перезаписей. Все 10 контрольных сумм совпали. Скорости чтения и записи практически не изменились.

Выводы? Значимых нет.

1000 перезаписей я получу за 3-4 дня, а 5000 за 15-16.

6000 раз перезаписал весь объем китайской флешки на 8 GB. Контрольное чтение и сверку контрольной суммы выполнял каждые 100 записей. Расхождений нет. Не знаю, какой выбрать следующий эксперимент.

В треде высказаны две противоположные гипотезы. Согласно первой изношенные перезаписью ячейки должны терять данные быстрее новых. Поэтому флешке надо дать отлежаться долгое время. Какое? Неделю? Месяц? Год? Лучше, чтобы флешка хранилась при повышенной температуре для ускорения утечки заряда. Но не ясно, какая нужна температура, чтобы ускорить потерю заряда в несколько раз, и при этом не убить прошивку контроллера.

Согласно второй гипотезе самые изношенные ячейки либо пробиваются полностью, либо время хранения заряда в них не отличается от новых.

Какая из двух гипотез является верной?

тут нет никого из производителей чипов флеш памяти :) так что достоверной инфы не найдешь.

изношенные ячейки теряют заряд быстрее. «пробивание» диэлектрика при заряде ячейки не проходит для структуры без последствий, физика однако.

здесь отписывались что в флешках давно перешли от кодов выявления ошибок к кодам рида-соломона, позволяющих восстановить потерянные биты.
и при подключении контроллер читает весь объем, находит блоки с ошибками, восстанавливает через рид-соломонов и записывает восстановленный блок в новое место.
на практике отражалось в низких скоростях чтения с носителя в первое время после подключения. после «прогрева» носителя, сиречъ контроллер прочитал весь диск и успокоился, скорость нормализуются.
ты своими частыми подключениями «прогреваешь» носитель и данные восстанавливаются :)

тырнетик полнится теориями заговоров :)

Я вот недели три назад купил три одинаковых microSD размером 32 Гбайт, ну прогнал свой тест, две нормальные, на одной 24 Гбайт весь в ошибках. Причём с него читается не те даные, что записывались и со скоростью 7 Мбайт/с, а с остальных гигабайт этой карточки читаются правильные данные и со скоростью 70 Мбайт/с.

Если там всё восстановлено/перезаписано, то чего так медленно то? Я держал эту карточку во включном виде пару суток.

И NAND всегда требовал кода восстановления ошибок, просто, для SLC ЕМНИП, было типа 1 бит на 512 байт данных, а для TLC 4 бит.

А в данные разные писали, или байт в байт? Может контроллер умный, расчитан на запись идентичных блоков, видит что в блоке уже то, что нужно и не пишет... Скорость записи/чтения не измеряли?

А в данные разные писали, или байт в байт?

В обсуждемом тесте (когда я заполнял весь объем microSD), я заранее подготовил два случайных файла на весь объем флешки и чередовал их запись. Я сделал это ровно для того, чтобы избежать совпадения записываемых данных с уже записанными.

Скорость записи/чтения не измеряли?

Я измерял скорость записи и чтения вблизи контрольных точек. Первые 500 записей требовали 265-270 секунд. Далее время стало почему-то немного сокращаться, и примерно при 800 записях стало составлять стабильные 257-258 секунд.

Скорость чтения выглядит заметно менее стабильной, но полученная информация не очень точна, т.к. я в своем скрипте не предусмотрел отдельного измерения скорости чтения, в журнале зафиксировано только время всей итерации запись-чтение. Оно колеблется в диапазоне 356-393 секунды. Если допустить, что скорость записи в этой итерации и в предыдущей совпадают, можно получить примерное время чтения. Оно колеблется в диапазоне 104-134 секунды. Не имею предположений, от чего оно зависит. Возможно, от температуры в помещении. Если с пристрастием искать тенденцию, то она скорее к снижению времени чтения, но она не имеет значения на фоне отдельных колебаний.

Ну, значит у вас хорошая microSD. В целом, с ресурсом флеш-памяти непонятно, ресурсных тестов накопителей вобще почти нет. Был такой https://3dnews.ru/938764/resursnie-ispitaniya-ssd-obnovlyaemiy-material/page-... . Внезапно прекатил обновлять данные. Но там есть интерестное наблюдение:

Как видно по приведённому графику, число циклов перезаписи 3D TLC NAND в составе Crucial MX300 за всё время тестирования превысило 10 тысяч. И это – весьма примечательный показатель, ведь изначально Micron обещает для своей памяти ресурс лишь 1500 циклов перезаписи.

И подобное в других тестах встречается — что память отрабатывает заметно больше, чем обещает производитель. Либо производитель как-то улучшает техпроцесс, но не вносит изменения в документацию, либо присутствует большой разброс качества выпускаемых чипов, у одних 1500, у других 10000. Но таких тестов — чтобы «убивали» десяток-другой одинаковых накопителей я не находил.

Ну и там по ссылке, в конце гистограмма, ресурс в Тбайт, так как диски примерно по 1/4 Тбайт, то можно ресурс умножать на 4 и получать кол-во циклов. Только половина тестируемых SSD дотянула до 6 тыс.

память отрабатывает заметно больше, чем обещает производитель

Но там нет теста на длительность хранения. По JEDEC нужно, чтобы по исчерпании гарантированного ресурса потребительские SSD могли пролежать хотя бы 1 год при не более 30 градусах без питания.

Интересно, что для винчестеров рекомендованная температура должна не превышать 40 градусов, а для SSD при записи должна быть, наоборот, не меньше этих 40 градусов.

в Linux, с помощью открытого ПО

Да, самому любопытно.

Что это?

Garbage collection. Ну, и прочие (мифические) фоновые процессы.

Любопытно, в этом JC-64.8 Subcommittee указаны WD и Micron, а остальные производители памяти/SSD в курсе?

Вобще там развёрнутая таблица (по материалам Intel), вроде как, тоже включена в JEDEC. И, как бы, по ней проверять и положено, по не заштрихованой зоне, то есть после прогонки заданого объёма данных, причём определёнными операциями запись, чтение, TRIM, нужно не ждать 52 недели (1 год) при 30 градусах, а нагреть до 40 и подождать 14 недель.

И тут как бы всё просто и понятно. Но это требования к SSD, и у SSD в документации или SMARTе должны быть свои ограничения на объём записи/число циклов.

А упомянутые 1500 циклов, вроде как из даташита на чипы памяти. В даташитах на чипы NAND памяти, котороые я нашёл/изучил нет подобных зависимостей, там вобще может быть 10 лет и всё. И никакой информации, как зависит время хранения от температуры хранения, от температуры работы, от числа циклов. Но когда больше этих циклов, должны пойти проблемы стирания/потери данных, без длительного хранения.

Вот можно найти такое: https://www.macronix.com/Lists/ApplicationNote/Attachments/1920/AN0339V1-Endu... , можно сказать, дополнение к даташитам. Для микроновской памяти подобного не нашёл. Да, там SLC память, но и та таблица из JEDEC, скорее всего, по данным SLC. И вобще не совпадает, то есть чип памяти 100 тыс. циклов, 10 лет, но при <=100к циклов даётся 10 лет хранения при 35 градусах или 1 год при 55 градусах. Но при этом и здесь нету деления на «Active/PowerOff» температуры

Может, конечно, Micron и прочие с какого-то момента начали указывать не реальное кол-во циклов памяти, а то, на что нужно умножить объём флешки и получить допустимый TBW (объём записи). В реальных условиях усиление записи может быть 2-3, то есть число циклов NAND должно быть в 2-3 раза больше, чем то, что используется для вычисления TBW. В тесте 3Dnews запись последовательно, большими блоками, усиления записи особо и нет (около 1).

Первые 500 записей требовали 265-270 секунд. Далее время стало почему-то немного сокращаться, и примерно при 800 записях стало составлять стабильные 257-258 секунд.

Тем временем флешка выдержала 10000 полных перезаписей. Ничего особо не поменялось. Скорость записи продолжила расти, и стала менее постоянной. Колеблется в диапазоне 248-251 секунд.

Не вижу смысла продолжать текущий тест.

Дальнейший план: заполнить эту флешку и контрольную новую случайными данными, сравнить скорости чтения и записи, контрольные суммы, и повторить чтение дней через 10. Затем планирую сравнить через месяц. Если и тогда не увижу разницы, останется только жарить обе флешки в печи.

Буду рад услышать более интересные идеи для тестирования.