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

Лично мне ссылочку на статью скинул главный конструктор одного из предприятий радиоэлектронной промышленности с формулировкой «хочешь поржать?».

Пара ссылок по теме:

• www.youtube.com/watch?v=EuCSS9VtxCA
• zen.yandex.ru/media/id/5cebc7044d24ad00b31ddccc/zachem-liudi-zariajaiut-fleshnakopiteli-5d113734e1551900b0ad97a9

Я, конечно, поржал, но не над тем, над чем вы подумали. Мне приходилось принимать участие в разработке твердотельных накопителей на основе NAND-flash памяти, в том числе и для USB-флешек. На первый взгляд для технически подкованного человека кажется очевидным, что подключение накопителя к заряднику бессмысленно, так как кроме подачи питания никаких прочих действий с накопителем не производится, поэтому, кроме тепловыделения мы ничего не получим. В интернете много разных «разоблачений», смешков и даже откровенного стеба над бедными гуманитариями, которые спрашивают, стоит ли заряжать флешки. Можете смеяться, но я видел своими глазами, как разработчики флешек именно «заряжали» свои изделия, устанавливая их в зарядники на некоторое время!

USB-флешка является блочным устройством хранения данных: все адресное пространство разбито на секторы по 512 байт. Операционная система может обратиться по адресу определенного сектора (LBA) и прочитать его или перезаписать, все просто.

А теперь заглянем под капот нашей флешки…

В состав флешки входят микросхемы:

• контроллер;
• NAND-flash память.

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

• Память разделена на блоки, размером порядка единиц Мегабайт;
• Перед записью в блок памяти его необходимо стереть. При стирании все байты данных в блоке устанавливаются в значение 0xFF;
• Блок состоит из страниц, размером порядка десятков Килобайт;
• Запись данных в блок производится страницами, одновременно может быть записана сразу вся страница данных;
• Страницы данных внутри одного блока должны записываться строго в порядке возрастания их номеров;
• Каждая страница после стирания блока может быть записана только единожды до следующего стирания.

Вот, этот набор правил превращает такое простое действие (с точки зрения пользователя) как записать один сектор на USB-флешку в настоящую головоломку для разработчика контроллера этой самой флешки.

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

Для того, чтобы «подружить» user-friendly блочную адресацию накопителя и sadist-friendly адресацию NAND-flash памяти, внутри контроллера флешки крутится процессор, который реализует алгоритм трансляции адресов, он же FTL (Flash Translation Layer). В задачи алгоритма FTL входят:

• построение и поддержка таблицы трансляции адресов (page mapping);
• «сборка мусора» (garbage collection);
• выравнивание износа блоков NAND-flash памяти (wear leveling).

Знающие люди скажут, что есть еще и другие задачи, как, например, отслеживание битых блоков NAND-flash памяти (bad block management), но я об этом сейчас не хочу говорить, потому что к текущему делу не относится…

Немного ликбеза по обозначенным пунктам:

Page mapping

Ну, тут, пожалуй, все понятно… Адресное пространство логических адресов накопителя (LBA) транслируется в адреса блоков и страниц NAND-flash памяти (физический адрес) через огромный массив, индекс которого означает LBA, а значение элемента — физический адрес. Если необходимо перезаписать одну страницу, то данные этой страницы пишутся в свободный блок по порядку, а, затем, в массиве заменяется номер страницы на вновь записанный. Когда школьник покупает флешку 32ГБайта, а обнаруживает, что на ней только 29 ГБайт, школьник еще не знает, что недостающее место не китайцы на фабрике украли, а разработчики алгоритма FTL. Чтобы иметь возможность писать данные на накопитель.

Garbage Collection

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

Wear Leveling

Ничто не вечно под луной, а NAND-flash — особенно. Так уж вышло, что NAND-flash память имеет ограниченный ресурс, который выражается ограниченным числом циклов стирания блоков (возрастом блока). Блоки, которые стирались большее число раз (старые блоки), имеют большую вероятность выхода из строя, чем те, которые менее изношенные (молодые блоки).

Задумывались ли вы когда-нибудь над тем, что надо бы таблицу FAT перенести из нулевых адресов накопителя куда-нибудь в другое место, чтобы не протереть дырку в адресном пространстве флешки? Это вряд ли, да и не следует над этим думать. Потому что во флешке работает механизм выравнивания износа блоков. Суть его в том, что молодые блоки, меняются местами со старыми в принудительном порядке, чтобы износ всех блоков был равномерным в течение эксплуатации накопителя. Так у накопителя есть шанс жить долго и счастливо, пока все его блоки не умрут в один день.

А теперь о главном — зачем таки «заряжать» флешки?

1) Бывало у вас такое, что вы изо дня в день собираетесь постирать носки, но каждый вечер оказывается не до этого? А потом наступает такой момент, что чистых носков на завтра просто физически не осталось! И тогда вам приходится жертвовать сном ради стирки носков. Еще хуже, если приходится опаздывать на работу с феном в руках.

Примерно это же происходит и с алгоритмом сборки мусора в FTL. Пользователь зачастую использует флешку для переноса каких-то данных с одного компьютера на другой. При этом, сценарий действий следующий: воткнуть флешку в комп — записать быстро файлы — выдернуть флешку — добежать до другого компа — воткнуть флешку — считать файлы. Через некоторое время пользователь начинает замечать, что его накопитель медленно работает. Обычно в таких случаях грешат на то, что «ну, просто флешка дешевая, старая. Вот, куплю новую, она будет летать!». И действительно будет! Но ее, скорее всего, постигнет та же участь через некторое время. Дело в том, что сценарий таких «короткометражек» не позволяет алгоритму garbage collection производить высвобождение блоков для записи, что рано или поздно приведет к тому, что свободных блоков больше просто физически не останется. И тогда контроллер вынужден сначала заняться высвобождением блоков, а затем только записью ваших файлов в них, отсюда и потеря скорости. Чтобы быть готовым принять ваши данные на полной скорости, накопителю необходимо свободное время для того, чтобы «постирать носки» заранее. Как легко догадаться, «зарядка» флешки снимает эту проблему, предоставляя контроллеру достаточно времени для наведения порядка в данных.

2) Проблема нехватки «личного времени» контроллера актуальна и для алгоритма выравнивания износа. Алгоритм Wear Leveling выполняется контроллером в моменты простоя накопителя, пока нет задач для записи или чтения пользовательских данных. Если же накопитель работает в режиме «короткометражек», то времени на выравнивание износа блоков просто нет. Неравномерный износ блоков приводит к тому, что старые блоки выходят из строя. При этом число доступных для записи блоков уменьшается, пока не наступит критичный момент, когда свободных блоков для записи просто не останется, хотя NAND-flash память в целом еще не изношена, и могла бы еще долго прослужить.

3) Эволюция научила нас прикапывать дорогие нам ценности где-нибудь подальше от проходных мест. Это хорошо работает в случае кладов и необитаемых островов. Но с цифровыми данными и NAND дело обстоит с точностью до наоборот. Наверняка, у вас были случаи, когда вы скинули на флешку какие-то фотографии со свадьбы друга, год флешка полежала в ящике стола (как вам казалось, в целости и сохранности), а потом некоторые из фоток прочитались только наполовину. Дело в том, что единожды записанная в NAND-flash память информация способна «протухнуть» со временем. Производитель памяти не гарантирует 100% сохраняемость данных, а просто озвучивает вероятность возникновения битовых ошибок.

Конечно же, контроллер накопителя решает задачу устранения битовых ошибок, добавляя избыточный код к данным, но какой бы ни был большой этот код, со временем заряд в ячейках NAND-памяти рассасывается, и число битовых ошибок может перевалить за любую корректирующую способность. Нельзя оставлять данные лежать долго в одиночестве в NAND-flash памяти, за ними надо ухаживать. А именно — периодически перезаписывать. Правильный контроллер производит периодически перечитывание данных, контроль числа битовых ошибок и перезапись данных в случае необходимости (пока число битовых ошибок не превысило допустимое). Разумеется, для этого также контроллеру необходимо «свободное время».

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

_________________________________

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

Когда школьник покупает флешку 32ГБайта, а обнаруживает, что на ней только 29 ГБайт, школьник еще не знает, что недостающее место не китайцы на фабрике украли, а разработчики алгоритма FTL.

Начнем с простого, что не стоит все списывать систему трансляции и ее нужды. Разница в емкости в первую очередь продиктована разными единицами измерения.
Гигабайт — это 1 000 000 000 байт
Гибибайт — это 1 073 741 824 байт

Накопитель емкостью 32 гигабайта 32 000 000 000 байт.
32 000 000 000 / 1 073 741 824 = 29,8 гибибайта.

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

В принципе невозможная ситуация, чтобы не было блоков для записи при наличии свободного пространства в логическом диапазоне.

Как-то немного затрагивал алгоритм работы одного из NAND контроллеров используемых в USB flash .
Если кратко, то в логическом банке число включаемых блоков в трансляцию всегда меньше количества блоков. Всегда есть полностью свободные блоки. Это можете увидеть из материала моей публикации.

Возможны разные подходы при записи данных в зависимости от их объема.

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

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

Проблема нехватки «личного времени» контроллера актуальна и для алгоритма выравнивания возрастов. Алгоритм Wear Leveling выполняется контроллером в моменты простоя накопителя, пока нет задач для записи или чтения пользовательских данных. Если же накопитель работает в режиме «короткометражек», то времени на выравнивание износа блоков просто нет.

Конечно можно делать различные предположения о выравнивании износа и перезаписях старых блоков. Но есть много «НО», которые дадут поле для размышления.

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

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

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

Алгоритмы «сбора мусора» — это попытка найти блоки с малым заполнением в NAND накопителях, чтобы сформировать блоки со смешанным содержимым (блок-апдейты), которые странично или группами страниц накладываются в трансляцию. Но для реализации этого алгоритма контроллеру нужна обратная связь с ОС. т.е. при удалении должны сообщаться LBA диапазоны, которые микропрограмма оттранслирует к конкретным блокам. Технология например для SSD и SMR HDD существует и называется TRIM. А много ли вы сможете найти USB flash с поддержкой TRIM?

Наверняка, у вас были случаи, когда вы скинули на флешку какие-то фотографии со свадьбы друга, год флешка полежала в ящике стола (как вам казалось, в целости и сохранности), а потом некоторые из фоток прочитались только наполовину. Дело в том, что единожды записанная в NAND-flash память информация способна «протухнуть» со временем.

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

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

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

_____________________

Начнем с простого, что не стоит все списывать систему трансляции и ее нужды. Разница в емкости в первую очередь продиктована разными единицами измерения.
Гигабайт — это 1 000 000 000 байт
Гибибайт — это 1 073 741 824 байт

Накопитель емкостью 32 гигабайта 32 000 000 000 байт.
32 000 000 000 / 1 073 741 824 = 29,8 гибибайта.

Да, но нет. Да — в том плане, что 32*10^9 байт — это действительно 29,8 ГБайта. Нет — в том плане, что мне не известны производители NAND-flash памяти, которые делали бы число байт в странице (или число страниц в блоке, или число блоков в кристалле (и сразу скажу, что с TLC — отдельный разговор)) не кратными степени двойки в меньшую сторону. Все же микросхемы на 32 Гбита содержат 32*1024*1024*1024 бит (без учета sparearea).

В принципе невозможная ситуация, чтобы не было блоков для записи при наличии свободного пространства в логическом диапазоне.
… Всегда есть полностью свободные блоки.
… Это можете увидеть из материала моей публикации.

И да, и нет… Да — материал увидели, но… В статье вы рассмотрели одну конкретно реализацию блочного алгоритма FTL конкретного накопителя. На SSD такие алгоритмы не применяют. А там таки нет: без GC в принципе возможна такая ситуация, когда блоки свободные закончатся.

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

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

… контроллер не имеет представления были данные записаны год назад или вчера. Поэтому реализовать просто перезапись «старых данных» в принципе не представляется возможным… Основное выравнивание износа по факту происходит при изменении данных.

Ни да, ни нет. Возможно, я просто не понял ваш вопрос. Но ответить попробую. Возраст физических блоков (он же износ) измеряется не в часах ( и даже не в годах), а в количестве проведенных стираний блока. Для долгой счастливой жизни накопителя все блоки должны изнашиваться равномерно. Для выравнивания износа мало изменить данные, нужно их перезаписать в тот блок, который менее изношенный. Для ситуации, когда данные просто долго лежали и со временем «протухли» — отдельный разговор. Есть методы контроля степени разложения данных, но это не о количестве стираний речь эт другое.

… убитые накопители с NAND flash были заполнены статичными данными, а активное изменение шло в небольшой области, что привело к тому, что не так много блоков участвовало в ротации (имеется в виду, те что включены в трансляцию и подвергались изменению и блоки вне трансляции)

Да, почему бы и нет. Просто, эта флешка по какой-то причине не делала выравнивание блоков. Возможно, алгоритм такой… Или, возможно, ее просто не заряжали. О том и речь. ?

… технология например для SSD и SMR HDD существует и называется TRIM. А много ли вы сможете найти USB flash с поддержкой TRIM?

Нет, нет, и снова нет. TRIM и GarbageCollection — идеологически похожи, но не пересекающиеся функционалы. Они работают на разных уровнях. TRIM — снаружи диска по логическим адресам (LBA), GC — работает на уровне физических адресов NAND. Если мы, например, клонировали диск посекторно, то TRIM вам не сообщит о том, что на самом деле у вас 80% диска свободно от данных; с точки зрения контроллера, диск будет занят на все 100%. Тем не менее, когда вы начнете виндой на этот диск писать много мелких фалов по случайным адресам (именно писать, не стирая старые), то TRIM не будет работать (потому что у него нет оснований для освобождения кластеров). А Garbage Collection все равно должен устранять фрагментацию блоков в NAND-flash памяти. Тут легко запутаться в применениях, я понимаю ваше смятение.

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

Ни да, ни нет. Зависит от контроллера. Не стал бы так категорично утверждать. Некоторые контроллеры при обнаружении нечитаемых страниц переходят навсегда в режим read-only, чтобы пользователь мог спасти то, что сейчас есть на флешке. А некоторые — не переходят… И что они там выдают вместо непрочитанных данных? Ну, не знаю.

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

Да, да, да. Ошибки в NAND чаще всего и являются причиной нарушения таблиц трансляции, так как таблицы трансляции также хранятся в NAND.

Но эти явления в большинстве своем не связаны с естественной деградацией самой NAND памяти и ее содержимого.

То ли да, то ли нет, не понятно. В большинстве или не в большинстве — не могу судить, но то, что деградация NAND приводит к таким эффектам — это точно. Вот, прям точно. )

В итоге рекомендация включать USB flash с поданными на них постоянными 5В не кажется однозначно полезной.

О, да!.. Я рад, что после прочтения моей статьи технические специалисты меняют мнение с «заряжать USB — бред» на менее категоричное «не кажется однозначно полезной». Значит, мысль я донес. Спасибо.

Источник