Первая половина вашего комментария в духе «флешки не могут умирать, потому что они не живые»… То, что вы описали — да, это все так и есть, я о том и говорю. Просто не вдавался во внутреннюю кухню этого процесса.
По поводу GC — то же самое: я не говорю, что выравниванием возрастов занимается GC, для этого есть WL.
Safety remote device — штука интересная. На винде и на линуксе работает по-разному, потому что:
Винда… Винда записывает файлы на флешку сразу, как только это возможно. Старается не хранить данные в КЭШ. Даже индикатор прогресса записи файлов максимально точно описывает процесс записи на диск. Пожтому, с точки зрения данных, если файлы записались, то можно выдергивать накопитель из хоста, и быть уверенным, что файлы записались.
Линукс — штука не такой. Линукс очень сильно зависит от настроек, дистрибутива и все такое. Известные мне дистрибутивы (убунту, дэбиан) старались максимально КЭШировать запись на накопитель. Прогресс записи в линуксе неадекватно показвал скорость записи до 1000 МБайт/с, при том, что реально ни одной операции записи на накопиель не производилось. Если в этот момент вытащить накопитель из хаба, то на другом компе файлов мы, конечно не увидим. Зато, как и следовало ожидать, когда нажимает «Извлечь», то линукс говорит «погодите секундочку» и без всякого прогрессбара начинает запись файлов на накопитель. Понятное дело, что запись файлов бодбшого объема занимает больше секундочки. У меня тут к линуксу претензии, птому что польшователь по незнанию может подумать что просто все зависло, устал ждать, и выдернул накопитель. Скорее всего, птом придется повозиться еще и с битой FAT.
С линуксом все понятно, давайте копнем глубже винду:
Файлы пишутся как видятся — уже хорошо. Но в чем тогда суть Safety remote device? А в том, что кроме видимой активности копирования файлов может быть еще невидимая активность фоновых процессов (например, по флешке шарится антивирус). Или, например, пользователь может банально забыть, что у него открыт файл ворда прямо с флешки. Если у пользователя есть привычка делать Safety remote device, то ОС сообщит при попытке извлечения, что флешка используется, и на том уже спасибо. Safety remote device — это, скорее, гарантия того, что после извлечения уже никакая программа не будет лазить на диск.
Чем же опасна активность флешки во время извлечения? Объясняю. Не все производители добросовестно думают о том, что будет происходить с флешкой при пропадании питания, иногда экономят банально на конденсаторах даже. Если производится операция программирования NAND-памяти, и в этот момент пропадает питание, то нет гарантий, что страница данных запишется корректно. При записи некорретной страницы опять же есть два возможных варианта: что разработчики софта подумали о такой возможности, и что разработчики софта не упели к дедлайну подумать о такой возможности.
Вывод: так как конечный пользователь не в курсе, как работают алгоритмы во флешке — лучше делать Safety remote device, чем не делать. Это не дает никаких гарантий, но снижает вероятность как потери данных, так и окирпичивания флешки вообще.
В остальном же, никогда не следует доверять флешкам, так как вариантов сэкономить время разработки за счет потери надежности хранения данных существует превеликое множество. Лично я чаще видел, как умирают декоративные noname флешки, чем именитые.
Начнем с простого, что не стоит все списывать систему трансляции и ее нужды. Разница в емкости в первую очередь продиктована разными единицами измерения.
Гигабайт — это 1 000 000 000 байт
Гибибайт — это 1 073 741 824 байт
Да, но нет. Да — в том плане, что 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 — бред» на менее категоричное «не кажется однозначно полезной». Значит, мысль я донес. Спасибо.
О!.. Сколькоо ее масса новых ответов у меня для вас есть! )
1) NAND — штука ее на столько хитрая, чтобы уметь делать GC. Этим занимается именно контроллер флешки. Некоторые производители NAND делают линейку микросхем NAND-памяти со встроенным контроллером FTL, чтобы клиентский проц этим всем не занимался. Тем не менее, на массовом рынке экономически выгоднее крутить FTL на контроллере флешки.
2) В статье описано многое. FTL есть во всех накопителях, которые применяют NAND. Но ручаться за то, что кто-то конкретный из накопителей заморачивается на счет провееения фонового GC никак нельзя. Судя по производительности и живучести бюджетных USB-флешек, они вообще ни над чем не заморачиваются часто.
3) В случае USB-флешек аппаратная защита от записи может быть реализована массой способов. И все это на усмотрение разработчика.
4) У SD-карт памяти бегунок никак не влияет на саму карту памяти. Он просто механически сообщает хосту (хосту, Карл!), что на флешку нельзя писать. Некоторые бессоветсные хосты игнорируют этот ползунок.
5) GC после безопасного извлечения — тоже на совести разработчика. В USB есть вспециальная команда на извлечение накопителя. До флешки эта команда доходит, флешка ее видит, а что она творит — это только разработчик знает.
По поводу GC — то же самое: я не говорю, что выравниванием возрастов занимается GC, для этого есть WL.
Винда… Винда записывает файлы на флешку сразу, как только это возможно. Старается не хранить данные в КЭШ. Даже индикатор прогресса записи файлов максимально точно описывает процесс записи на диск. Пожтому, с точки зрения данных, если файлы записались, то можно выдергивать накопитель из хоста, и быть уверенным, что файлы записались.
Линукс — штука не такой. Линукс очень сильно зависит от настроек, дистрибутива и все такое. Известные мне дистрибутивы (убунту, дэбиан) старались максимально КЭШировать запись на накопитель. Прогресс записи в линуксе неадекватно показвал скорость записи до 1000 МБайт/с, при том, что реально ни одной операции записи на накопиель не производилось. Если в этот момент вытащить накопитель из хаба, то на другом компе файлов мы, конечно не увидим. Зато, как и следовало ожидать, когда нажимает «Извлечь», то линукс говорит «погодите секундочку» и без всякого прогрессбара начинает запись файлов на накопитель. Понятное дело, что запись файлов бодбшого объема занимает больше секундочки. У меня тут к линуксу претензии, птому что польшователь по незнанию может подумать что просто все зависло, устал ждать, и выдернул накопитель. Скорее всего, птом придется повозиться еще и с битой FAT.
С линуксом все понятно, давайте копнем глубже винду:
Файлы пишутся как видятся — уже хорошо. Но в чем тогда суть Safety remote device? А в том, что кроме видимой активности копирования файлов может быть еще невидимая активность фоновых процессов (например, по флешке шарится антивирус). Или, например, пользователь может банально забыть, что у него открыт файл ворда прямо с флешки. Если у пользователя есть привычка делать Safety remote device, то ОС сообщит при попытке извлечения, что флешка используется, и на том уже спасибо. Safety remote device — это, скорее, гарантия того, что после извлечения уже никакая программа не будет лазить на диск.
Чем же опасна активность флешки во время извлечения? Объясняю. Не все производители добросовестно думают о том, что будет происходить с флешкой при пропадании питания, иногда экономят банально на конденсаторах даже. Если производится операция программирования NAND-памяти, и в этот момент пропадает питание, то нет гарантий, что страница данных запишется корректно. При записи некорретной страницы опять же есть два возможных варианта: что разработчики софта подумали о такой возможности, и что разработчики софта не упели к дедлайну подумать о такой возможности.
Вывод: так как конечный пользователь не в курсе, как работают алгоритмы во флешке — лучше делать Safety remote device, чем не делать. Это не дает никаких гарантий, но снижает вероятность как потери данных, так и окирпичивания флешки вообще.
В остальном же, никогда не следует доверять флешкам, так как вариантов сэкономить время разработки за счет потери надежности хранения данных существует превеликое множество. Лично я чаще видел, как умирают декоративные noname флешки, чем именитые.
Да, но нет. Да — в том плане, что 32*10^9 байт — это действительно 29,8 ГБайта. Нет — в том плане, что мне не известны производители NAND-flash памяти, которые делали бы число байт в странице (или число страниц в блоке, или число блоков в кристалле (и сразу скажу, что с TLC — отдельный разговор)) не кратными степени двойки в меньшую сторону. Все же микросхемы на 32 Гбита содержат 32*1024*1024*1024 бит (без учета sparearea).
И да, и нет… Да — материал увидели, но… В статье вы рассмотрели одну конкретно реализацию блочного алгоритма FTL конкретного накопителя. На SSD такие алгоритмы не применяют. А там таки нет: без GC в принципе возможна такая ситуация, когда блоки свободные закончатся.
Да, да, да… Именно об этом и идет речь пунктом выше. Когда у вас апдейтами будут забиты все свободные блоки — настанет время их разгребать, раскладывать по местам, освобождая блоки для будущих применений.
Ни да, ни нет. Возможно, я просто не понял ваш вопрос. Но ответить попробую. Возраст физических блоков (он же износ) измеряется не в часах ( и даже не в годах), а в количестве проведенных стираний блока. Для долгой счастливой жизни накопителя все блоки должны изнашиваться равномерно. Для выравнивания износа мало изменить данные, нужно их перезаписать в тот блок, который менее изношенный. Для ситуации, когда данные просто долго лежали и со временем «протухли» — отдельный разговор. Есть методы контроля степени разложения данных, но это не о количестве стираний речь эт другое.
Да, почему бы и нет. Просто, эта флешка по какой-то причине не делала выравнивание блоков. Возможно, алгоритм такой… Или, возможно, ее просто не заряжали. О том и речь. ;)
Нет, нет, и снова нет. TRIM и GarbageCollection — идеологически похожи, но не пересекающиеся функционалы. Они работают на разных уровнях. TRIM — снаружи диска по логическим адресам (LBA), GC — работает на уровне физических адресов NAND. Если мы, например, клонировали диск посекторно, то TRIM вам не сообщит о том, что на самом деле у вас 80% диска свободно от данных; с точки зрения контроллера, диск будет занят на все 100%. Тем не менее, когда вы начнете виндой на этот диск писать много мелких фалов по случайным адресам (именно писать, не стирая старые), то TRIM не будет работать (потому что у него нет оснований для освобождения кластеров). А Garbage Collection все равно должен устранять фрагментацию блоков в NAND-flash памяти. Тут легко запутаться в применениях, я понимаю ваше смятение.
Ни да, ни нет. Зависит от контроллера. Не стал бы так категорично утверждать. Некоторые контроллеры при обнаружении нечитаемых страниц переходят навсегда в режим read-only, чтобы пользователь мог спасти то, что сейчас есть на флешке. А некоторые — не переходят… И что они там выдают вместо непрочитанных данных? Ну, не знаю.
Да, да, да. Ошибки в NAND чаще всего и являются причиной нарушения таблиц трансляции, так как таблицы трансляции также хранятся в NAND.
То ли да, то ли нет, не понятно. В большинстве или не в большинстве — не могу судить, но то, что деградация NAND приводит к таким эффектам — это точно. Вот, прям точно. )
О, да!.. Я рад, что после прочтения моей статьи технические специалисты меняют мнение с «заряжать USB — бред» на менее категоричное «не кажется однозначно полезной». Значит, мысль я донес. Спасибо.
1) NAND — штука ее на столько хитрая, чтобы уметь делать GC. Этим занимается именно контроллер флешки. Некоторые производители NAND делают линейку микросхем NAND-памяти со встроенным контроллером FTL, чтобы клиентский проц этим всем не занимался. Тем не менее, на массовом рынке экономически выгоднее крутить FTL на контроллере флешки.
2) В статье описано многое. FTL есть во всех накопителях, которые применяют NAND. Но ручаться за то, что кто-то конкретный из накопителей заморачивается на счет провееения фонового GC никак нельзя. Судя по производительности и живучести бюджетных USB-флешек, они вообще ни над чем не заморачиваются часто.
3) В случае USB-флешек аппаратная защита от записи может быть реализована массой способов. И все это на усмотрение разработчика.
4) У SD-карт памяти бегунок никак не влияет на саму карту памяти. Он просто механически сообщает хосту (хосту, Карл!), что на флешку нельзя писать. Некоторые бессоветсные хосты игнорируют этот ползунок.
5) GC после безопасного извлечения — тоже на совести разработчика. В USB есть вспециальная команда на извлечение накопителя. До флешки эта команда доходит, флешка ее видит, а что она творит — это только разработчик знает.