Комментарии 282
Можно просто оставлять флешку, вставленной в порт, а в биос включить режим зарядки от USB при выключенном ПК.
Я так однажды воткнул мелкоформатную флешку в порт для зарядки телефонов у ноутбука и не вынимал. Потом долго удивлялся с чего это у выключенного ноутбука за ночь уходит 60-70% заряда батареи. Думал, что батареи хана и надо заказывать новую.
Имея некоторый опыт работы с NAND памятью и реверс-инжинирингом алгоритма контроллеров хотел бы задать вопросы автору и внести некоторые уточнения, так как некоторые утверждения автора весьма спорные.
Начнем с простого, что не стоит все списывать систему трансляции и ее нужды. Разница в емкости в первую очередь продиктована разными единицами измерения.
Гигабайт — это 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) при мелких дополнениях некоторые фирмвари не спешат переписывать большие объемы данных и формируют блоки-блоки апдейты, которые отдельными страницами накладывают на логическую трансляцию (т.е. точечные подмены при трансляции для страниц разных блоков)
Конечно можно делать различные предположения о выравнивании износа и перезаписях старых блоков. Но есть много «НО», которые дадут поле для размышления.
В флешках нет элемента питания и нет внутренних «часов», контроллер не имеет представления были данные записаны год назад или вчера. Через протоколы передачи данных с хостом не предусмотрен запрос времени и даты у компьютера. Поэтому реализовать просто перезапись «старых данных» в принципе не представляется возможным.
Основное выравнивание износа по факту происходит при изменении данных, что достаточно неплохо видно по материалам моей публикации. Отсюда зачастую и наблюдаем, что убитые накопители с NAND flash были заполнены статичными данными, а активное изменение шло в небольшой области, что привело к тому, что не так много блоков участвовало в ротации (имеется в виду, те что включены в трансляцию и подвергались изменению и блоки вне трансляции)
Алгоритмы «сбора мусора» — это попытка найти блоки с малым заполнением в NAND накопителях, чтобы сформировать блоки со смешанным содержимым (блок-апдейты), которые странично или группами страниц накладываются в трансляцию. Но для реализации этого алгоритма контроллеру нужна обратная связь с ОС. т.е. при удалении должны сообщаться LBA диапазоны, которые микропрограмма оттранслирует к конкретным блокам. Технология например для SSD и SMR HDD существует и называется TRIM. А много ли вы сможете найти USB flash с поддержкой TRIM?
Для начала стоит отметить, что если страница не прочиталась, то в принципе контроллер не отдаст каких либо данных. При нечитаемой странице вы получите ошибку чтения и пустой буфер, а не искаженные данные в нем. Всякие половинчатые фотографии это чаще следствие ошибок файловой системы, перекрестные записи, искажение данных при в буферном ОЗУ микроконтроллера, а также различные ошибки в трансляции, когда вместо данных транслируется мусор. Но эти явления в большинстве своем не связаны с естественной деградацией самой NAND памяти и ее содержимого.
Процедуры перестроения трансляции при простое могут быть реализованы в некоторых микропрограмма USB flash, но исходя из вопросов выше вряд ли они такие, как себе представляет автор. Также наличие процедур оффлайн сканирования во многих микропрограммах USB flash опять же под большим вопросом. В итоге рекомендация включать USB flash с поданными на них постоянными 5В не кажется однозначно полезной.
Когда школьник покупает флешку 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 — бред» на менее категоричное «не кажется однозначно полезной». Значит, мысль я донес. Спасибо.
Звучит как маразм, оставлять флешку на ночь что бы она «что-то» поделала.
Даже если всё звучит как автор описал, минут 15 простоя, должно ей хватить что бы сделать все дела. ПО крайней мере выглядит как обычный TRIM
Даже если всё звучит как автор описал, минут 15 простоя, должно ей хватить что бы сделать все дела. ПО крайней мере выглядит как обычный TRIM
Не увидел ответа на напрашивающийся прямой вопрос: так будет ли всё-таки этот самый «сборщик мусора» работать, если воткнуть флешку не в компьютер, а в зарядник?
Воткнул свою флешку с лампочкой-индикатором в зарядный порт своего USB-хаба — лампочка моргнула и потухла. Как мне это интерпретировать?)
По идее, для работы процессора в флешке не нужен обмен данными с компьютером, так что работать будет. Всё-таки, этим занимается процессор самостоятельно, а не операционная система на компьютере. А "лампочка" обычно показывает, что в данный момент происходит передача данных.
«Идеи» это конечно хорошо, но они совсем не обязательно совпадают с практикой) Вдруг этот самый процессор вообще даже не запускается, пока сигнал от компьютера не придёт? Я хочу знать подробности
Я пришел сюда с этим же вопросом!
Ну, для того, чтобы компьютер "увидел" флешку, кто-то должен инициировать USB хендшейк и, скорее всего, это тот же процессор.
Хотя да, это всё ещё не факт, да и не хватает исследования, насколько быстро и эффективно работают все эти алгоритмы, описанные в статье. Может, они отрабатывают достаточно быстро для того чтобы не было такой необходимости давать им больше времени.
Ну, процессор может не дождаться сигнала компьютера и уйти в спящий режим, например. Мало ли чего)
Касательно лампочки на моей флешке — она при бездействии горит всегда, а при передаче данных мигает, специально такую флешку для теста взял. Но при подключении к заряднику она не мигает и не горит, а тухнет совсем, так что я боюсь, что процессор на ней всё-таки выключается
Собственно, он должен так сделать, т.к. без хендшейка он не может потреблять большую мощность.
А нужна ли вообще флешке большая мощность? Даже всякие USB-вентиляторы, которые суть два проводочка да моторчик, бодро крутятся без всяких процессоров
По стандарту вы можете 50 (или 100, тут забыл) миллиампер с порта получить, пока девайс не представится системе и не выдаст дескриптор, в котором указан запрашиваемый ток. Для USB 2.0 это 500мА максимум. Тот факт, что вентиляторы и прочее на это плевали, не даёт гарантии, что какая-нибудь материнская плата, которая полностью следует стандарту, не погасит порт по питанию с overcurrent-ом. Случаи USB DCP и 3.х с его Power Delivery не рассматриваем.
Надо понимать, что в USB стандарте «без всяких процессоров» невозможно. Любое USB устройство обладает процессором, иначе оно не сможет взаимодействовать с зарядником и запрашивать нужную мощность. Иногда эти процессоры реализованы внутри кабеля, но они есть.
Ну вообще-то устройство без процессора вполне может получать питание от USB — примером чего могут быть всякие китайские и самодельные вентиляторы и светодиодные светильнички. Ведь на USB-порт напряжение подается даже если никакого устройства в него не воткнуто.
Кроме того, бывают USB-кабели «только для зарядки», в которых нет линий данных.
Ну и сколько я разбирал дешевых телефонных зарядок — тоже на выход идут только два провода питания.
То есть стандарт стандартом, но зачастую разработчики забивают на некоторые положения стандарта, которые кажутся им некритичными. Например, не включают режим Suspend (в частности, библиотека V-USB его не умеет).
Да, запросить повышенную мощность у хоста не получится, но если укладываться в минимальный порог (до 100 мА), то и запрашивать ничего не надо.
Кроме того, бывают USB-кабели «только для зарядки», в которых нет линий данных.
Еще любопытный пример из опыта
У моей мамы в планшете как-то разболтался разъём до потери контактов — перестал заряжаться, сначала контакт восстанавливался при поджиме штекера, а потом и это уже не срабатывало. Он отнесла его в мастерскую — там разъём перепаяли, зарядка восстановиласью. Но как-то она пришла ко мне чтобы перекинуть файлы. А планшет не обнаруживается. Но заряжается. Я полез внутрь — ремонтники оказалсь халтурщиками, помимо ужасного качества пайки, они еще и напрочь оборвали дорожки данных.
Но и при этом обрыве планшет таки заряжался от компа.
Но и при этом обрыве планшет таки заряжался от компа.
Ну и сколько я разбирал дешевых телефонных зарядок — тоже на выход идут только два провода питания.
То есть стандарт стандартом, но зачастую разработчики забивают на некоторые положения стандарта, которые кажутся им некритичными. Например, не включают режим Suspend (в частности, библиотека V-USB его не умеет).
Да, запросить повышенную мощность у хоста не получится, но если укладываться в минимальный порог (до 100 мА), то и запрашивать ничего не надо.
Возможно DATA оборвались вместе разъемом. И восстановить невозможно — линии уходят сразу в слои. У меня так на портативном радиоприемнике/Mp3 плеере произошло. С DATA он еще работал как кардридер и звуковая карта.
Ну, возможно, начальная трещинка и при расшатывании появилась. Но отсутствие участка дорожки на длине нескольких мм — это уже только при неаккуратной отпайке возможно.
И я ж восстановил в итоге. Линии там не сразу внутрь уходят, по той же стороне идут достаточное расстояние до via (к которым я в итоге проволочки и прокинул от ножек разъёма).
И я ж восстановил в итоге. Линии там не сразу внутрь уходят, по той же стороне идут достаточное расстояние до via (к которым я в итоге проволочки и прокинул от ножек разъёма).
Я так с большим трудом нашел Data-кабель type-c <> type-c, 99.999% вариантов на маркетплейсах - это зарядники, а мне нужны были и данные в usb стандарте 3.2. Даже шнурки по 1000 руб такого типа в большинстве случаев - только для зарядки, сейчас передача данных по кабелю, как будто стала мене актуальна.
Неверно. USB BC1.1 определяет порт типа DCP, который не требует никакой цифровой коммуникации. Вы или выдумываете, или сами не знаете, на какой «стандарт» ссылаетесь.
Не знаю, как в 3.0, а в 1.1 и 2.0 FS и LS устройства хаб обнаруживает подключение устройства по уровням напряжения на линиях D+ и D–:
— при отключенном устройстве на линиях D+ и D- уровни сигнала низкие (состояние SE0), что обусловлено резисторами Rd1 и Rd2 хаба;
— при подключении LS-устройства повышается уровень сигнала D- за счет резистора Rul в устройстве (переход в состояние LS-Idle);
— при подключении FS/HS-устройства повышается уровень сигнала D+ за счет резистора Rul в устройстве (переход в состояние FS-Idle).
И только после этого хост инициирует обмен данными.
Если на шине нет активности более чем 3.0 мс, устройство переходит в Suspend Mode. В течение следующих 7 мс устройство должно отключиться, и не потреблять ток больше, чем заданный ток suspend. Таким образом, через 10 мс после прекращения активности шины ток потребления от неё не должен превышать suspend current.
— при отключенном устройстве на линиях D+ и D- уровни сигнала низкие (состояние SE0), что обусловлено резисторами Rd1 и Rd2 хаба;
— при подключении LS-устройства повышается уровень сигнала D- за счет резистора Rul в устройстве (переход в состояние LS-Idle);
— при подключении FS/HS-устройства повышается уровень сигнала D+ за счет резистора Rul в устройстве (переход в состояние FS-Idle).
Иллюстрация
И только после этого хост инициирует обмен данными.
Если на шине нет активности более чем 3.0 мс, устройство переходит в Suspend Mode. В течение следующих 7 мс устройство должно отключиться, и не потреблять ток больше, чем заданный ток suspend. Таким образом, через 10 мс после прекращения активности шины ток потребления от неё не должен превышать suspend current.
Там вопрос не в быстродействии алгоритма, а в быстродействии памяти и объёме данных, которые надо между блоками перераспределить. Если у вас несколько гигабайт равномерно размазаны по флэшке, занимая каждый блок частично, то чтобы их консолидировать, понадобится несколько проходов. Задача даже более сложная, чем старая добрая дефрагментация.
Вот почему бы производителям не сделать отдельный светодиод для индикации всех этих операций? Ах да, тогда ведь флешки меньше будут выходить из строя.
Честно ответьте, беря в руки очередную флешку (свою, приятелей, родственников) сначала ознакамливаетесь с ее инструкцией и значением индикации? По-моему сейчас у большинства пользователей единственное еще оставшееся соблюдаемое правило — не выдергивай, пока окошко копирования не закрылось.
А то что флешка горячая как сковорода ни о чём не говорит?.. У меня сандиск 64г металлический, просто стоял воткнутым в хаб и грелся дико…
Не будет.
Хотелось бы увидеть числа: допустим, мы записали на флешку 5 гигов файлов, отнесли на другой комп, прочитали, стёрли. Сколько времени типичной флешке надо, чтобы "прийти в себя"?
ноль если вы писали на чистую свежеформатированную флешку.
вопросы возникают когда вы значала записали на флешку 100500 файликов потом через один их постирали и записали один фильм на 5 гиг, потом его стерли и начали пытаться записать новый фильм. тогда и у флешек и у ссд скорость с 150-200 мегабайт в сек записи падает до 20-30. например моему самсунгу 65 гиговому ссд на «прийти в чувство» надо полтора часа после таких издивательств. Patriot hellfire только через пол часа простоя начинает «чухаться» и собирать мусор и длится это до 3-х часов. по нагреву радиатора видно.
вопросы возникают когда вы значала записали на флешку 100500 файликов потом через один их постирали и записали один фильм на 5 гиг, потом его стерли и начали пытаться записать новый фильм. тогда и у флешек и у ссд скорость с 150-200 мегабайт в сек записи падает до 20-30. например моему самсунгу 65 гиговому ссд на «прийти в чувство» надо полтора часа после таких издивательств. Patriot hellfire только через пол часа простоя начинает «чухаться» и собирать мусор и длится это до 3-х часов. по нагреву радиатора видно.
Значит ли это, что достаточно всякий раз просто форматировать флешки, служащие для быстрого переноса файлов?
Скорее всего нет, так как без специальных TRIM-команд флешка просто не знает, что её отформатировали
В винде в окне форматирования есть галочка, называется вроде "полное форматирование" или что-то в этом духе. Вот при таком форматировании память реально форматируется и это ни разу не быстро. По умолчанию же просто стирается раздел файловой системы и всё, то есть сама физическая память не стирается, а стираться она начинает только перед записью.
Так что нету смысла форматировать флешки таким способом, а стирать полностью долго.
Естественно, речь только о полном форматировании. Его длительность ведь зависит от объёма флешки? Для сравнительно небольших «флешек-переносчиков» такое форматирование может оказаться удачной альтернативой «заряжанию» флешки неопределённо длительное время. Нет?
Тем более, что мы не знаем правильный ли у нас контроллер (см. ниже).
Тем более, что мы не знаем правильный ли у нас контроллер (см. ниже).
От объёма и скорости памяти, а по моим наблюдениям ещё и от свободного места. Но свободного в том смысле, что если отформатировать флешку и потом сразу записать например 100-500 мб, то отформатируется быстрее чем если на флешку до этого было записано не известно сколько данных и не известно сколько раз, так сказать время форматирования зависит от состояния самой памяти, чем больше ячеек уже стёрто, тем быстрее отформатируется.
А «правильный контроллер» скорее всего есть только в каких-то топовых флешках, которые уже на уровне ssd по скорости, во всех обычных же 99% что будет контроллер который почти ничего не может.
А «правильный контроллер» скорее всего есть только в каких-то топовых флешках, которые уже на уровне ssd по скорости, во всех обычных же 99% что будет контроллер который почти ничего не может.
Потому, что умные контроллеры (все современные SSD?) ноли не пишут, а помечают сектор, как не неиспользуемый (аналог TRIM). Некоторый ещё и убеждаются, что сектор физически стёрт. После этого запись может идти быстрее, так как не нужно сдирать сектора и выполнять ротацию. Во флэшках этого не было, хотя последние контроллеры могут и иметь такую фичу. Проверяется просто — записываем большой блок нолей на флэшку. При этом запись нолей, должна выполняться в два раза быстрее чем ненолей, т.к. выполняется (если выполняется) только стирание секторов (без последующей записи). А последующая запись нолей в то же место должна выполняться почти мгновенно. Очень хорошо видно на всяких SSD от SunDisk, которые показывают чудеса скорости в тестах при записи нолей (сейчас научились и при заполнении любым одним значением так делать — хранят байт значения в таблице перемещения секторов), но при этом на порядок медленнее на случайных данных.
«память реально форматируется» — тоже вроде не совсем верно…
Так-то там блоки в логическом разделе вроде как должны помечаться как удалённые, но «реальной» перезаписи байт таки и не происходит.
Так-то там блоки в логическом разделе вроде как должны помечаться как удалённые, но «реальной» перезаписи байт таки и не происходит.
Так помечаются как удалённые же при обычном форматировании, в чём тогда разница то? Что-то же он там делает по 30-60 минут.
Так помечаются как удалённые же при обычном форматировании, в чём тогда разница то? Что-то же он там делает по 30-60 минут.
Если вы формтирует флешку быстрым форматированием, то будет небольшое число операций записи/чтения по созданию чистой файловой системы. Никакого массового высвобождения блоков без TRIM не случится. Все как было включено в трансляцию так и останется. По мере записи новых данных будет происходить запись в те же или новые блоки. При записи в новые блоки старые будут исключаться из трансляции и очищаться. Такой механизм не очень хорошо выравнивает износ, но при отсутствии TRIM хоть так.
В случае «полного» форматирования в Windows будет еще чтение всего логического диапазона (проверка на его доступность) в остальном все будет тоже самое.
из всего этого важно понять, что форматирование средствами ОС, не приводит к сбросу содержимого NAND накопителей без TRIM.
А как тогда получается что после быстрого форматирования данные можно востановить пока они не затёрлись, а после полного на моей флешке не восстанавливается ничего?
Так же скорость чтения с флешки около 35 мб/с, а по USB 3.0 около 100 мб/с, даже с 35 мб/с флешка на 16гб у меня читается за примерно 7.5 минут, а «полностью» форматируется она даже дольше чем если её записывать полностью данными, так-как скорость записи 20-25 мб/с.
Что же там за чтение такое происходит, что оно медленнее чем запись?
Так же скорость чтения с флешки около 35 мб/с, а по USB 3.0 около 100 мб/с, даже с 35 мб/с флешка на 16гб у меня читается за примерно 7.5 минут, а «полностью» форматируется она даже дольше чем если её записывать полностью данными, так-как скорость записи 20-25 мб/с.
Что же там за чтение такое происходит, что оно медленнее чем запись?
При быстром форматировании создаётся новая таблица файлов, сами же файлы не затираются. Полное форматирование перезаписывает весь раздел нулями или мусором и уже после этого создаёт файловую систему. Но, как всегда, есть одно но: на накопителях, поддерживающих TRIM, после быстрого форматирования система может дать контроллеру знать, что пространство уже чисто и контроллер накопителя эти блоки может использовать по своему усмотрению
Не помечаются они удалённые при обычном форматировании. Нужно TRIM делать. Некоторые контроллеры делают TRIMM при заполнении нолями, но не все и нужно выбирать полное форматирование.
А 60 минут он там тупо мусор на диск пишет, например. Только ресурс уменьшает.
А 60 минут он там тупо мусор на диск пишет, например. Только ресурс уменьшает.
Мне вот другое интересно. Заряд из ячеек потихоньку утекает и со временем флешка просто потеряет данные. Достаточно ли просто подключать её к компу, чтобы ячейки перезаписывались по мере необходимости?
В статье сказано, что "правильный" контроллер будет этим заниматься самостоятельно. Так что вопрос только в том, какие контроллеры "правильные" и насколько часто они встречаются.
Как раз тому что у меня ещё остались те медленные(но быстрые,) usb-2.0 флешки в которых вроде как нет проблем с "вытеканием" электронов и через 3 года неиспользования они читаются без проблем :)
А как контроллер флешки, делая все эти внутренние операции, решает проблему того, что ее в любой момент могут выдернуть в середине процесса? На зарядке же нет кнопки "безопасного извлечения".
Ну это скорее всего не так уж и сложно. Например, может быть конденсатор, которого гарантированно хватит на обработку одного блока. При потере питания последний блок обрабатывается и обработка останавливается.
Только там нет такого конденсатора — это хорошо видно.
Современные керамические конденсаторы удивляют размером при приличных ёмкостях. А вообще достаточно перемещать данные в другой блок и метить транзакцию завершённой только после успешной записи самих данных, см. любую журналируемую ФС.
Я такую штуку сам делал недавно. Нужно порядка 150 мкФ если нет кэша записи и, минимум, порядка 330 мкФ, если есть кэш записи и всё равно куча ухищрений нужна. А никаких сотен микрофарад в ширпотребных флэшках нет.
Чтобы пометить транзакцию нужно опять же полностью переписать какую-то страницу на флешке. Что случится при вынимании флешки на середине этого процесса?
Представляется немного странным хранить таблицу распределения блоков NAND в этом же самом NAND. Там нужно-то всего ничего, достаточно совсем небольшого кусочка отдельного флеша для этого, буквально единицы--десятки килобайт, причём это будет память без блоков конского размера, и нужно будет обеспечить наличие питания на, грубо говоря, запись пары байт. Да, журнал должен быть быстрым, надёжным, с гарантированной записью и без кеша. Альтернатива — soft updates, как во FreeBSD'шной UFS. Было весьма удобно: ФС была некорректно отмонтирована, однако при следующем монтировании спокойно продолжала работать дальше, запустив в бекграунде сборщик мусора.
Можете открыть любую флэшку и убедиться, что «отдельного флэша» там нет.
А «десятов килобайт» не хватит, т.к. ресурс страницы флэш очень мал, а это самая нагруженная область, без чередования секторов эта область протрётся до дыр сказочно быстро. Нужно хотя бы стократный резерв для организации ротации таблиц. Не говоря уже о том, что это не решает проблемы — что будет, если питание пропадёт в момент записи этого «другого флэша»?
А «десятов килобайт» не хватит, т.к. ресурс страницы флэш очень мал, а это самая нагруженная область, без чередования секторов эта область протрётся до дыр сказочно быстро. Нужно хотя бы стократный резерв для организации ротации таблиц. Не говоря уже о том, что это не решает проблемы — что будет, если питание пропадёт в момент записи этого «другого флэша»?
Я не могу открыть микросхему контроллера, чтобы убедиться, что там действительно нет небольшого участка SLC-флеша. Да даже если у него и 50000 P/E, можно сделать область побольше (не 10, а целых 1024 кБ!) и разделить её на тысячу ротируемых таблиц размещения блоков в основном флеше. Сначала стираем подлежащую записи область таблицы размещения, потом пишем в определённое место бит «запись не завершена», пишем новую таблицу размещения блоков, потом ставим бит «запись завершена».
Нет там такой области. Там максимум небольшой «обычный» флэш для хранения прошивки контроллера стоит, который для данной функции никак не подходит — запись страницы порядка 10 мс, ресурс порядка 1000..10'000 перезаписей и объём не более мегабайта.
1. Чтобы флэш записать, его нужно сначала стереть.
2. Стирание производится страницами. Размер страницы бывает разный — от 256 байт, до 64 килобайт. Обычно — от 4 килобайт.
3. Запись тоже производится страницами, но во многих случаях можно «дописывать данные» некоторыми блоками — от 8 до 256 байт в блоке (т.к. контрольные суммы считаются и хранятся для блоков, а функции перезаписи нет). Т.к. если страница была стёрта запись и данные в этот конкретно в этот блок не писались, то можно записать те же данные, что уже были на этой странице, плюс, новые данные (кратные размеру блока).
Кстати, именно так и только так возможно регенерация данные во FLASH. Само по себе там ничего не восстанавливается — нужно в каждую страницу ещё раз, без стирания, записать уже хранимые там данные.
В какой такое «определённое место» вы собрались биты писать? Нельзя биты писать — только блоки и только в стёртые страницы.
А если питание пропадёт в момент стирания «подлежащей записи области таблицы размещения»?
А если питание пропадёт при записи бита «запись не завершена»?
А если питание пропадёт при записи новой таблицы? Что после включения делать?
А если питание пропадёт при записи бита «запись завершена»?
Но ещё раз — некуда вам биты писать.
1. Чтобы флэш записать, его нужно сначала стереть.
2. Стирание производится страницами. Размер страницы бывает разный — от 256 байт, до 64 килобайт. Обычно — от 4 килобайт.
3. Запись тоже производится страницами, но во многих случаях можно «дописывать данные» некоторыми блоками — от 8 до 256 байт в блоке (т.к. контрольные суммы считаются и хранятся для блоков, а функции перезаписи нет). Т.к. если страница была стёрта запись и данные в этот конкретно в этот блок не писались, то можно записать те же данные, что уже были на этой странице, плюс, новые данные (кратные размеру блока).
Кстати, именно так и только так возможно регенерация данные во FLASH. Само по себе там ничего не восстанавливается — нужно в каждую страницу ещё раз, без стирания, записать уже хранимые там данные.
В какой такое «определённое место» вы собрались биты писать? Нельзя биты писать — только блоки и только в стёртые страницы.
А если питание пропадёт в момент стирания «подлежащей записи области таблицы размещения»?
А если питание пропадёт при записи бита «запись не завершена»?
А если питание пропадёт при записи новой таблицы? Что после включения делать?
А если питание пропадёт при записи бита «запись завершена»?
Но ещё раз — некуда вам биты писать.
И как же, в свете всего этого, на самом деле реализована транзакционность работы с блоками?
Страницами и реализована, с версионированием. Есть набор страниц для хранения, например, таблицы соответствия логических секторов диска страницам флэша. Что-то вроде циклического буфера страниц. При необходимости внести изменения записывается новая страница целиком. Страница содержит увеличивающийся номер версии и контрольную сумму. При включении находится страница с максимальным номером версии и корректной контрольной суммой.
Поверх этого, опять же, на страницах, можно сгородить что-то вроде версионирования метаданных, чтобы при пропадании питания всё оставалось хоть во сколько-либо целостном состоянии. Это сложно и требует реально больших конденсаторов, которых во флэшках нет. Поэтому флэшки иногда физически мрут при проблемах с питанием — нарушается целостность таблицы соответствия секторов.
И для обновления данных нужно перезаписывать все страницы тем же самым содержимым. Это сложно и энергоёмко — нужно же последовательно все обновлять, начиная со старых, а это может часы занимать. Т.е. нужно иметь счётчики того, что уже обновлено, чтобы при пропадании питания не начинать всё сначала. А со счётчиками та же проблема — где хранить и как гарантировать целостность.
На сколько я знаю, никаких «обычные» флэшки ничего этого не делают. У SSD есть, где на самые разные ухищрения идут — там и конденсаторы, и отдельные микросхемы памяти для организации транзакций, и огромные резерв памяти для организации ротации. И то, гложут смутные сомнения по поводу китайских SSD и их ресурса. Аналогичные сомнения гложут по поводу наличия и правильности реализации обновления хранимых данных и всяких нонейм-SSD.
А у SD/USB-флэшек не у всех даже есть механизм ротации секторов, из-за чего при интенсивной работы флэшки и SD-карты быстро изнашиваются в часто-используемых областях (а такие есть у всех «обычных» файловых систем). У некоторых же флэшек реализованы только простейшие алгоритмы ротации секторов, например, только вначале и конце — там, где у FAT наиболее критичная к записи область. Такие флэшки хорошо работают с FAT, но очень медленно с другими файловыми системам, и мрут на других файловых системах тоже быстро. Например, у меня есть несколько нонейм флэшэк, которые при нестандартном форматировании ext4 с переносом переносом суперблоков (есть такой лайф-хак) в начало диска показывают в разы большую производительность на запись.
А вообще для любителей пускать линуксы с флэшек есть специальные файловые системы вроде JFFS, UBIFS, F2FS и т.п., которые умеют делать ротацию секторов на уровне файловой системы, плюс, правильные настройки, уменьшающие износ диска — с ними условная «малинка на SD-карте» будет жить долго и счастливо.
Поверх этого, опять же, на страницах, можно сгородить что-то вроде версионирования метаданных, чтобы при пропадании питания всё оставалось хоть во сколько-либо целостном состоянии. Это сложно и требует реально больших конденсаторов, которых во флэшках нет. Поэтому флэшки иногда физически мрут при проблемах с питанием — нарушается целостность таблицы соответствия секторов.
И для обновления данных нужно перезаписывать все страницы тем же самым содержимым. Это сложно и энергоёмко — нужно же последовательно все обновлять, начиная со старых, а это может часы занимать. Т.е. нужно иметь счётчики того, что уже обновлено, чтобы при пропадании питания не начинать всё сначала. А со счётчиками та же проблема — где хранить и как гарантировать целостность.
На сколько я знаю, никаких «обычные» флэшки ничего этого не делают. У SSD есть, где на самые разные ухищрения идут — там и конденсаторы, и отдельные микросхемы памяти для организации транзакций, и огромные резерв памяти для организации ротации. И то, гложут смутные сомнения по поводу китайских SSD и их ресурса. Аналогичные сомнения гложут по поводу наличия и правильности реализации обновления хранимых данных и всяких нонейм-SSD.
А у SD/USB-флэшек не у всех даже есть механизм ротации секторов, из-за чего при интенсивной работы флэшки и SD-карты быстро изнашиваются в часто-используемых областях (а такие есть у всех «обычных» файловых систем). У некоторых же флэшек реализованы только простейшие алгоритмы ротации секторов, например, только вначале и конце — там, где у FAT наиболее критичная к записи область. Такие флэшки хорошо работают с FAT, но очень медленно с другими файловыми системам, и мрут на других файловых системах тоже быстро. Например, у меня есть несколько нонейм флэшэк, которые при нестандартном форматировании ext4 с переносом переносом суперблоков (есть такой лайф-хак) в начало диска показывают в разы большую производительность на запись.
А вообще для любителей пускать линуксы с флэшек есть специальные файловые системы вроде JFFS, UBIFS, F2FS и т.п., которые умеют делать ротацию секторов на уровне файловой системы, плюс, правильные настройки, уменьшающие износ диска — с ними условная «малинка на SD-карте» будет жить долго и счастливо.
Журналирование и версилнность могут быть обеспечены вообще без стирания путём присвоения следующего идентификатора который можно писать в конец блока по некоторым правилам, чтобы обеспечить возможность "удостоверится" что прочитали мы в очередной раз именно идентификатор блока а не какой-то шум...
Чтобы что-то записать, сначала нужно стереть. И нет смысла писать в конец блока, если запись всё равно страницами идёт.
Там и делают — версия страницы, плюс CRC, чтобы убедиться, что это не мусор. Но тогда начальная инициализация требует чтения всех страниц, что на больших объёмах (десятки-сотни гигабайт) может занимать недопустимое время.
Там и делают — версия страницы, плюс CRC, чтобы убедиться, что это не мусор. Но тогда начальная инициализация требует чтения всех страниц, что на больших объёмах (десятки-сотни гигабайт) может занимать недопустимое время.
Я программировал устройство с устойчивой к потере питания системой журналирования, при перезаписи блока он считался корректным только при наличии в этом блоке контрольной суммы. Сбойно записанный блок при чтении сразу распознавался. При сбое в использование шла информация из предыдущего по времени журналирования блока. Т.е. либо корректный блок есть и своим наличием перекрывает предыдущий, либо считается что используется предыдущая версия.
Он может быть вообще внутри чипа
Думаю, механизм транзакций или вроде того. Интересно было бы почитать подробнее об этих контроллерах от их производителей.
А также как и SSD — потребительские почти никак (можете ремонтников, которые данные восстанавливают поспрашивать, у них наверняка прилично таких пациентов было), всякий industrial — куча конденсаторов.
У микросхем NAND флешей есть команды клонирования страниц, возможно контроллер сначала клонирует страничку, и если все хорошо и контрольная сумма новой страницы сошлась, то освобождает исходную.
А оно надо? Ни разу не встречал ситуации, что бы флешка умерла от выдергивания. Возможно есть механизм защиты в случае пропадания уровней D+ и D-. Конструкция USB-A вполне позволяет это сделать (сначала отключаются сигнальные линии, и лишь потом питание).
Если вы не встречали — это не означает, что никто не встречал. «Ошибка выжившего» же, из серии «я никогда еще не попадал под машину, переходя на красный свет».
С другой стороны, отзывы типа «у меня флешка умерла после такого выдёргивания» тоже не особо доказательны, ведь «после этого — еще не значит вследствие этого».
Но случаи «после» встречаются, например flashboot.ru/forum/index.php?topic=4624.0
С другой стороны, отзывы типа «у меня флешка умерла после такого выдёргивания» тоже не особо доказательны, ведь «после этого — еще не значит вследствие этого».
Но случаи «после» встречаются, например flashboot.ru/forum/index.php?topic=4624.0
+1. Весьма вероятно, что без связи с хостом, который может сказать флешке "готовься к извлечению", её процессор к работе приступать не будет.
У USB-разъёма контакты питания длиннее, чем контакты данных. Поэтому, если выдернуть флешку, то контроллер может обнаружить отсоединение передачи данных, при этом ещё какое-то короткое время будет поступать питание.
Copy on Write? Финализировать изменения после подтверждения фактического перемещения файла\блока\etc.
Сколько же новых вопросов появилось:
1. GC находится внутри USB-NAND контроллера или внутри самой микросхема NAND памяти?
2. Происходит ли описанное в статье в других флешках: SD, CF, eMMC?
3. На некоторых USB-флешках есть аппаратная защита от записи. Останавливает ли она GC или нет?
4. На SD-флешках тоже есть защита от записи, но она влияет на USB-SD контроллер, а не SD-NAND, в этом случае GC работает всегда?
5. Продолжает ли работать GC после безопасного извлечения/umaunt'а?
1. GC находится внутри USB-NAND контроллера или внутри самой микросхема NAND памяти?
2. Происходит ли описанное в статье в других флешках: SD, CF, eMMC?
3. На некоторых USB-флешках есть аппаратная защита от записи. Останавливает ли она GC или нет?
4. На SD-флешках тоже есть защита от записи, но она влияет на USB-SD контроллер, а не SD-NAND, в этом случае GC работает всегда?
5. Продолжает ли работать GC после безопасного извлечения/umaunt'а?
4. В SD-флешках защита от записи реализована как и в дискетах, задвижка lock ни к чему не подключена в карте и ее положение считывается отдельным контактом кард-ридера.
1) Внутри контроллера, сам NAND весьма тупой.
2) Потеря заряда — везде происходит. SD чисто в теории должно как-то делать wear leveling, CF — хехехе, не делает, проверено на куче всего, установку Gentoo переживали только Industrial Grade SLC CF Card всякие. Потребительские не доживали до окончания компиляции ядра даже. eMMC — считайте, что оно аналог обычного SSD
3-4-5) Известно только производителю контроллера
2) Потеря заряда — везде происходит. SD чисто в теории должно как-то делать wear leveling, CF — хехехе, не делает, проверено на куче всего, установку Gentoo переживали только Industrial Grade SLC CF Card всякие. Потребительские не доживали до окончания компиляции ядра даже. eMMC — считайте, что оно аналог обычного SSD
3-4-5) Известно только производителю контроллера
О!.. Сколькоо ее масса новых ответов у меня для вас есть! )
1) NAND — штука ее на столько хитрая, чтобы уметь делать GC. Этим занимается именно контроллер флешки. Некоторые производители NAND делают линейку микросхем NAND-памяти со встроенным контроллером FTL, чтобы клиентский проц этим всем не занимался. Тем не менее, на массовом рынке экономически выгоднее крутить FTL на контроллере флешки.
2) В статье описано многое. FTL есть во всех накопителях, которые применяют NAND. Но ручаться за то, что кто-то конкретный из накопителей заморачивается на счет провееения фонового GC никак нельзя. Судя по производительности и живучести бюджетных USB-флешек, они вообще ни над чем не заморачиваются часто.
3) В случае USB-флешек аппаратная защита от записи может быть реализована массой способов. И все это на усмотрение разработчика.
4) У SD-карт памяти бегунок никак не влияет на саму карту памяти. Он просто механически сообщает хосту (хосту, Карл!), что на флешку нельзя писать. Некоторые бессоветсные хосты игнорируют этот ползунок.
5) GC после безопасного извлечения — тоже на совести разработчика. В USB есть вспециальная команда на извлечение накопителя. До флешки эта команда доходит, флешка ее видит, а что она творит — это только разработчик знает.
1) NAND — штука ее на столько хитрая, чтобы уметь делать GC. Этим занимается именно контроллер флешки. Некоторые производители NAND делают линейку микросхем NAND-памяти со встроенным контроллером FTL, чтобы клиентский проц этим всем не занимался. Тем не менее, на массовом рынке экономически выгоднее крутить FTL на контроллере флешки.
2) В статье описано многое. FTL есть во всех накопителях, которые применяют NAND. Но ручаться за то, что кто-то конкретный из накопителей заморачивается на счет провееения фонового GC никак нельзя. Судя по производительности и живучести бюджетных USB-флешек, они вообще ни над чем не заморачиваются часто.
3) В случае USB-флешек аппаратная защита от записи может быть реализована массой способов. И все это на усмотрение разработчика.
4) У SD-карт памяти бегунок никак не влияет на саму карту памяти. Он просто механически сообщает хосту (хосту, Карл!), что на флешку нельзя писать. Некоторые бессоветсные хосты игнорируют этот ползунок.
5) GC после безопасного извлечения — тоже на совести разработчика. В USB есть вспециальная команда на извлечение накопителя. До флешки эта команда доходит, флешка ее видит, а что она творит — это только разработчик знает.
Некоторые бессоветсные хосты игнорируют этот ползунок.Ну прям бессовестные, утилита CHDK для камер Canon использует этот хак в очень полезных целях :).
Да, вещь интересная, этот chdk. Несколько лет назад искал себе картридер для sd, и оказалось, половина из них или игнорирует защелку или через раз срабатывает. А мне как раз с зашитой и надо было, чтоб к любым компам с вирусами свою флешку подключать. В итоге нашëл, и прямо внутрь картридера сделал переключатель, ибо защелки на sd картах произвольно могут перескочить.
Точно не через драйвер. Защёлка всего лишь на картридере замыкает-размыкает контакты, а уже сам картридер, в зависимости от положения, возвращает ОС информацию, что read-only. Проверял и на виндах всяких, и под линуксом, и под досом так же всё работает. Но надеяться нельзя на картридеры — они легко могут просто игнорировать положение защёлки, и всегда будут позволять записывать. Именно поэтому я пользуюсь своим, проверенным, если в подозрительные чужие компы подключать надо. Ибо несколько раз нарывался, что вирус портил содержимое, и свои экземпляры ещё туда записывал. И пару раз получалось, что включал флешку в передний USB, где полярность перепутали при сборке ПК, и флешка сгорала от переполюсовки питания. При картридере сгорает картридер, а SD карта остаётся целой (чаще всего). А уж потом я доработал его, добавил защиту от переполюсовки. Писал как-то давно про это статью на Intel IT Galaxy.
(сайта уже нет с 2015 года, но интернет кое-что помнит) Жаль, дальше нет данных, чтобы полностью посмотреть… или я не умею там искать.
(сайта уже нет с 2015 года, но интернет кое-что помнит) Жаль, дальше нет данных, чтобы полностью посмотреть… или я не умею там искать.
2. От перемены внешнего интерфейса внутренняя суть работы накопителя не меняется.
3. защита от записи во флешках организована программно, переключатель обычно подключен на gpio ножку проца, а софт внутри него смотрит за состояние переклбчателя. Ножка разрешения записи есть и на самих нандах, но она не применяется для этого.
4. Защита чисто механическая, которую читает картридер и он уже сам решает писать или не писать. На уборку мусора контроллером это не влияет.
5. Я думаю продолжет, при том ему даже легче этим заниматься, никто не отвлекает глупыми запросами. Опять же unmount и безопасное извлечение это разные вещи. Возможно при безопасном флешка и отключается.
3. защита от записи во флешках организована программно, переключатель обычно подключен на gpio ножку проца, а софт внутри него смотрит за состояние переклбчателя. Ножка разрешения записи есть и на самих нандах, но она не применяется для этого.
4. Защита чисто механическая, которую читает картридер и он уже сам решает писать или не писать. На уборку мусора контроллером это не влияет.
5. Я думаю продолжет, при том ему даже легче этим заниматься, никто не отвлекает глупыми запросами. Опять же unmount и безопасное извлечение это разные вещи. Возможно при безопасном флешка и отключается.
По поводу пункта 2 есть исключения. Раньше были флешки формата XD. Вот там наружу смотрит голый нанд, и вся адресация, исключение битых страниц и тд ложится на плечи картридера.
Я так и не понял-это такой научно-технический стеб по типу «DVD Rewinder» или реально?
Проскакивала когда-то статья: Отключённый промышленный твердотельник может потерять данные за неделю. В ней было некое количество контринтуитивных, но, вроде, логичных, утверждений: например, ситуация "хранить диск придётся при повышенной температуре — так хоть при записи пожалею, охлажу" на самом деле самая неблагоприятная. Так что стёбом здесь выглядит разве что термин "заряжать флешку". Хотя выше уже закономерно интересуются, будет ли это всё отрабатывать, если подать только питание.
Не, механизмы в статье описаны правильные, но ещё вопрос, работают ли эти механизмы на USB-флешках?
Беда в том, что только производитель контроллера может сказать, как у него сделан wear-leveling/refresh charge/и прочее.
По идее какое-то представление можно получить «за дёшево» просто понаблюдав (осциллографом или ЛА) за активностью на шине контроллер-память. Даже ничего не декодировать, просто есть/нет.
Достаточно понаблюдать USB тестером за шиной питания. Запись/стирание NAND энергозатратная операция.
Цена деления USB тестера: 10мА
Разница между токами покоя и стирания у навскидку выбранного «середнячка» NAND: 22мА (это по 3.3В, т.е. в переводе к 5В будет ещё чуть ниже)
Время стирания сектора: 3.8мс
Нужна довольно активная работа, чтобы было заметно.
Разница между токами покоя и стирания у навскидку выбранного «середнячка» NAND: 22мА (это по 3.3В, т.е. в переводе к 5В будет ещё чуть ниже)
Время стирания сектора: 3.8мс
Нужна довольно активная работа, чтобы было заметно.
Есть разные USB тестеры, есть те что показывают 1mA
p.s. Вставил три разного возраста флешки, не увидел никакой реакции, то есть ровно 0 потребления, светодиоды доступа не горят.
p.s. Вставил три разного возраста флешки, не увидел никакой реакции, то есть ровно 0 потребления, светодиоды доступа не горят.
может подождать?
или вся описанная тема если и есть, то работает между/около времени обмена, так что мне тоже кажется что врядли бы производители так рисковали
или вся описанная тема если и есть, то работает между/около времени обмена, так что мне тоже кажется что врядли бы производители так рисковали
подключил к юсб тестеру флешку, тестер к зарядке, показывает потребление 0.02 ампера
прошло пол часа, потребление не изменилось, флешка немного нагрелась. светодиода у нее нет вообще.
прошло пол часа, потребление не изменилось, флешка немного нагрелась. светодиода у нее нет вообще.
Автор выдает желаемое за действительное.
Действительно было бы хорошо, если бы контроллер занимался всем желаемым, но 99.9% USB флешек этого не поддерживают.
Умирание 0го блока на sd картах (регулярного при fat32) подсказывает что контроллеры оных не умеют даже в подсчёт циклов использования, хотя может это мне не повезло (3 micro-sd карты не пишутся только блоки в начале) ...
Всё серьёзно и технически правильно.
Это крутой контроллер, если он умеет всё вышеперечисленное делать, такому место скорее в SSD. Для предотвращения потери данных при записи такому контроллеру ещё нужен будет SLC-кэш, всё это удорожает флэшку.
По факту есть TLC SSD, который «стёк» за полгода, так что если китайцы не думают об обновлении записанных ячеек, то у флэшки лучше вовсе не рассчитывать.
По факту есть TLC SSD, который «стёк» за полгода, так что если китайцы не думают об обновлении записанных ячеек, то у флэшки лучше вовсе не рассчитывать.
А что за модель?
Потерял SSD где-то. По истории поиска — Kingdian S280 240G, контроллер SM2256K AB. Был включён в питание, но не был виден из Windows в течение этого полугода.
Kingdian, насколько помню, это один из самых дешевых ssd с aliexpress. У него в SMART нет никаких данных, позволяющих оценить уровень износа диска. У него нет температурного датчика, вместо этого он всегда сообщает 40 градусов.
У меня был магазинский Silicon Power — так он имеет ещё меньше smart-данных и умер всего через пару лет работы, в то время как Kingdian с алиэкспресса до сих пор жив-здоров уже года три, хоть и испытывает постоянную нагрузку от виртуалок и обновлений арча (хотя температура действительно одинаковые 40)
Звучит так всё хорошо и приятно, только терзают сомнения: флешки (товар недорогой) делаются братьями-китайцами, притом контроллеры там не всегда сильно брендовые. Есть подозрение, что в китайских поделках хорошо если само собой ничего не ухудшится, будут запитанным, но не используемым — не то что чтобы что-то улучшалось.
Это, конечно, не научно доказанное подозрение, но в то, что китайцы грамотно реализуют GC, я бы не особо верил. Его и в некоторых брендовых SSD не всегда хорошо делали, а тут…
В общем, если бы речь шла про внешний жесткий диск с породистой SSD-хой внутри, статье бы верилось. А что недорогая флешка из ларька сама себя (как кошка) еще иоблизывать обслуживать будет — слабо верится.
Это, конечно, не научно доказанное подозрение, но в то, что китайцы грамотно реализуют GC, я бы не особо верил. Его и в некоторых брендовых SSD не всегда хорошо делали, а тут…
В общем, если бы речь шла про внешний жесткий диск с породистой SSD-хой внутри, статье бы верилось. А что недорогая флешка из ларька сама себя (как кошка) еще и
сама себя (как кошка)
Вы мне упоротую идею подкинули!
Что, если использовать хорошо дрессируемых и умных животных — собак, или, например, свиней — как носитель даных с ассоциативной памятью? Сколько байт в них влезет и какова надёжность будет?
Ну как «влезет». Данные не просто «засовывают», их полезно «передавать», а с этим — засада.
Животные ведь как — они же к хакингу неустойчивы. Стоит на пути следования набора из отдельных элементов хранения (группы кошек, проще говоря) разместить несколько пустых коробок, как — БАЦ! — и данные уже не следуют дальше! Причем размер коробки обычно значения не имеет:
С собаками еще проще: колбаса!
И только черепахи вас порадуют, их от цели путешествия еще никому не удавалось отвлечь, но и данные наружу черепаха не отдает (точнее, никто их не может принять).
В общем, предлагаю (в случае черепах) просто флешку клеить к панцирю скотчем!
Животные ведь как — они же к хакингу неустойчивы. Стоит на пути следования набора из отдельных элементов хранения (группы кошек, проще говоря) разместить несколько пустых коробок, как — БАЦ! — и данные уже не следуют дальше! Причем размер коробки обычно значения не имеет:
С собаками еще проще: колбаса!
И только черепахи вас порадуют, их от цели путешествия еще никому не удавалось отвлечь, но и данные наружу черепаха не отдает (точнее, никто их не может принять).
В общем, предлагаю (в случае черепах) просто флешку клеить к панцирю скотчем!
флешку клеить к панцирю скотчем
Да это ничем принципиально от почтовых голубей отличаться не будет тогда.
Идея-то в том, чтобы обойтись без внешних носителей, а использовать для хранения данных именно МНУ животного.
Вот например, банально учим собак n команд: сал, бен, йон, рош, дур, буп, дам, хрям… Часть собак учим на «сал» поднимать левую лапу, часть — правую. Часть собак учим на «бен» вилять хвостом, часть — делать перекат. Вот уже два бита. И так далее...
Тут, кстати, возникает закономерный вопрос: сколько разных команд можно замапить на одно и то же действие, ведь количество разных хорошо различимых выполнимых собакой трюков ограничено? Не запутается ли в них собака? Ибо тогда получаем ту же проблему, что во флешках: плотность записи обратно пропорциональна надёжности.
А где пруфы насчёт наличия GC во флешках? Или это чисто домыслы автора статьи?
Есть они там, у некоторых производителей типа сандиска они ещё и мегапродвинутые, состоящие из 3х стадийного конвеера, slc кеша и тд.
Вот уж это не знаю где в открытую про это почитать. Я узнал из документаций на комплексы и конференций acelab.
Действительно хорошая быстрая флешка — это М.2 или msata в usb адаптере. Лучше — чтобы устройство ещё и теплоотвод имело на корпус адаптера.
Я думаю не ошибетесь если возьмете флэшку самсунга.
Выше правильно сказали что надо брать внешний ssd. Например, samsung t5.
Не специалист, но Вам, кажется, нужно искать флешку с поддержкой TRIM, по типу JetFlash 910. Сам тоже к ней присматриваюсь, есть светодиод, но он спрятан за креплением для ремешка. Из минусов — объём немного меньше заявленного (250Гб вместе 256, например) и колпачек, который потерять только так
А у меня макбук про 2016 около года без зарядки пролежал. Аккумулятор-то без проблем откачался, а вот SSD пришлось менять, не определялся напрочь. Хорошо он был ещё сменным в этой модели.
ХЗ отсутствие питания ли повлияло или как, но до простоя все работало без проблем.
А еще в зеркалке использовал флешку на 128GB. Но там я устраивал фотосессию на ~2-5GB, потом все фотки скидывал на комп, очищал флешку, и по-кругу. В итоге, в один прекрасный момент, фотки в «начале» флешки оказались битыми. После форматирования забил на всякий случай первые 15GB всяким хламом. Пока что полет нормальный…
А что касается статьи, то как и у многих, возникает вопрос когда включается этот loop сбора и сортировки данных? Ели есть питание == loop крутится, то наверное стоит иногда оставлять флешку подключенной к компьютеру.
ЗЫ в электронике я полный нуль, но все же (от незнания теории, в том числе) на уровне подсознания крутится недоверие и беспокойство от того, что зарядник может внезапно выдать флешке все свои 2-3А, что, мне кажется, не очень здорово. Ибо там максимальные токи больше чем у компутерного порта USB.
ХЗ отсутствие питания ли повлияло или как, но до простоя все работало без проблем.
А еще в зеркалке использовал флешку на 128GB. Но там я устраивал фотосессию на ~2-5GB, потом все фотки скидывал на комп, очищал флешку, и по-кругу. В итоге, в один прекрасный момент, фотки в «начале» флешки оказались битыми. После форматирования забил на всякий случай первые 15GB всяким хламом. Пока что полет нормальный…
А что касается статьи, то как и у многих, возникает вопрос когда включается этот loop сбора и сортировки данных? Ели есть питание == loop крутится, то наверное стоит иногда оставлять флешку подключенной к компьютеру.
ЗЫ в электронике я полный нуль, но все же (от незнания теории, в том числе) на уровне подсознания крутится недоверие и беспокойство от того, что зарядник может внезапно выдать флешке все свои 2-3А, что, мне кажется, не очень здорово. Ибо там максимальные токи больше чем у компутерного порта USB.
I=U/R
Напряжением рулит зарядник, сопротивлением — флешка. Зарядник при всём желании насильно флешке не сможет дать больше того, что она будет жрать. Случай, когда зарядник от дяди Сунь Кунь Чань за 10 центов и обожает выдавать 220 на выход, не рассматриваем.
Напряжением рулит зарядник, сопротивлением — флешка. Зарядник при всём желании насильно флешке не сможет дать больше того, что она будет жрать. Случай, когда зарядник от дяди Сунь Кунь Чань за 10 центов и обожает выдавать 220 на выход, не рассматриваем.
У меня тоже есть смутные подозрения, что карту памяти в фото/видеокамере не надо чистить после каждой съемки. Пока есть достаточно свободного места, пусть старье лежит, чтоб не писалось в одни и те же страницы. Хотя неизвестно, файловая система переписывает свои данные после каждого снятого кадра, или только при выключении камеры.
После прочтения этой статьи вы тоже начнете заряжать свои флешки.Слишком желто.
Учитывая все вышеизложенное, нет, не начну. Нет ни одного аргумента, что моя флешка всем этим занимается, скорее наоборот.
Почти по классике: «Знакомая сисопа, некто Клава, суёт разъем питания в COM-порт...»
Так.
1)USB(F)-PS/2(M)
2)PS/2(F)-COM(F)
3)COM(М)-LPT(M)
4)LPT(F)-LPT(M) ?!?!?!
1)USB(F)-PS/2(M)
2)PS/2(F)-COM(F)
3)COM(М)-LPT(M)
4)LPT(F)-LPT(M) ?!?!?!
4) это скорее всего HASP
3)COM(М)-LPT(M)
Скорее уж COM(9pin)-COM(25pin)
4)LPT(F)-LPT(M) ?!?!?!
А что вас так удивляет? Были и такие переходники. Хотя в варианте для LPT их смысл от меня тоже ускользает. Для RS-232 — перекрестное подключение прямого кабеля (что отражено в надписи Null Modem девайса по второй ссылке).
Давайте призовем в тему тех, кто реально этим занимается, и может спросить разработчиков. Kingston_Technology — подскажете, есть ли смысл ваши накопители «заряжать»?
PS: Ставлю на то, что смысла нет:
— флешки разрабатываются, исходя из сценария «воткнул-передал-выдернул», и не откладывают самосервис на потом;
— операции выравнивания занимают не так много времени, чтобы надо было оставлять флешку на часы, хватит и тех минут, что флешка стоит в разъеме в ожидании операций.
PS: Ставлю на то, что смысла нет:
— флешки разрабатываются, исходя из сценария «воткнул-передал-выдернул», и не откладывают самосервис на потом;
— операции выравнивания занимают не так много времени, чтобы надо было оставлять флешку на часы, хватит и тех минут, что флешка стоит в разъеме в ожидании операций.
Самый дельный комментарий, отмечусь тут тоже, чтобы уведомление об ответе получить.
не сработало, надо было демонологию качать
Тогда попробуем по-другому…
Если наши требования не будут удовлетворены, Kingston_Technology — мы берем заложника, и будем пытать его до последнего процента S.M.A.R.T. health!
Если наши требования не будут удовлетворены, Kingston_Technology — мы берем заложника, и будем пытать его до последнего процента S.M.A.R.T. health!
Подозреваю, что не имеет смысла — у меня сейчас лежат на столе две флешки Kingston_Technology DTSE9 16GB и DTS9 G2 USB3.0 32GB — скоропостижно скончались в молодом возрасте.
Господа делаем ставки, статья уже в работе — подробно осветим вопрос, дадим ответ и расскажем откуда ноги растут.
Кстати, а есть на винду какое-то решение, чтобы отдать флешке ATA-команду Secure Erase, тем самым пометив все блоки свободными?
На линухе через hdparm можно так дёрнуть.
Или при форматировании оно само как-то скажет флешке сбросить все блоки?
А то дома уже целая коробка флешек валяется, и у всех на чтение под сотню мегабит, а на запись от силы один, при этом самая новая из них куплена полгода назад :/
USB Mass Storage Device Class в общем случае не поддерживает, и не обязан поддерживать ATA-команды, там афаик SCSI-команды. Причем довольно усеченный набор, и чего-то типа Secure Erase там нет и не было. Поэтому в случае необходимости выпустить self-encryption, производители колхозят своё плюс фирменный софт, который обычно только под винду.
Хм, я руководствовался вот этой статьёй, но ещё не попробовал — https://blog.oxplot.com/make-usb-flash-write-fast-again/
Судя по статье, у чувака USB 3.0 флэшка. Гугл подсказывает, что 3.0 флэшки следуют протоколу USB attached SCSI (UAS), и hdparm, вероятно, умеет в SCSI-specific стирание.
В случае если у вас 2.0 флэшка/ридер/адаптер HDD — вы не можете рассчитывать на поддержку secure erase. В случае, если 3.0 флэшка подключена к 2.0 порту — вероятно, тоже.
В случае если у вас 2.0 флэшка/ридер/адаптер HDD — вы не можете рассчитывать на поддержку secure erase. В случае, если 3.0 флэшка подключена к 2.0 порту — вероятно, тоже.
У меня тоже 3.0, сейчас буду пробовать
Ну что сказать, попробовал. Ноль на массу, флешка даже пункт про сесуриту не выводит в hdparm.
Попробовал форматнуть быстро из винды и gparted — ожидаемо, ничего не поменялось. Попробовал форматнуть долго — за ночь 3%. Флешка при этом раскалилась, руками держать невозможно.
Могу разве что сказать одно — флешки Сандиск Ультра на 128 гигов брать можно только на пару раз. Пойду мучать их с гарантией...
Слышал, что контроллер обычной флешки или карточки памяти много проще, чем у SSD. Сборка мусора в свободное время это, вроде бы, характерно для SSD, а дешёвенькая флешка этим не занимается. Всё, что делается, делается в момент чтения-записи, в частности, потому, что выдернуть могут в любой момент.
Когда школьник покупает флешку 32ГБайта, а обнаруживает, что на ней только 29 ГБайт, школьник еще не знает, что недостающее место не китайцы на фабрике украли, а разработчики алгоритма FTL.
Что-то меня терзают смутные сомнения. Мне всегда казалось, что это маркетинг и хитрость обозначений. 32 GB = 32*10^9 B = 29.8*2^30 B = 29.8 GiB.
Эта хитрость для HDD, для SSD и флешек как я понимаю, используют «лишние» байты на служебные цели. Просто потому, что память для них делают всё-таки «круглого» двоичного размера.
Интересно. Я много где читал, что в SSD надо оставлять свободной часть памяти (10-20%) как раз для целей «буфера» при перестройке блоков. Зачем тогда это нужно, если и так 10% объема отъедается?
Потому что как и дефрагментация в винде. Плохо работает, если мало свободного места. Т.е. контроллеру негде разгуляться для выравнивания. При этом стоит понимать, что эти советы очень эвристические, в зависимости от модели SSD числа могут быть совершенно разные.
Кроме того, не ясно что делает контроллер с резервированным местом. Варианты могут быть следующие:
1. Использует для информации об адресации. Т.е. фактически место занято служебными данными
2. Использует для SLC кеша (который делается не отдельным кешем а просто использованием MLC/TLC ячеек для хранения одного бита).
3. Просто холодные блоки в резерв. Которые подменяются, когда другие начинают плохо себя вести
4. Просто холодные блоки для компенсации брака. Т.е. производится SSD с запасом, но из не очень качественных чипов. При начальном тестировании бракованные просто отключаются. Если все оказались живы, то лишние блоки лежат просто мёртвым грузом (ну не выпускать же одинаковые модели с ёмкостями 240, 250, 256GB). Но думаю, всё-таки по факту пункт 3 используется, хотя от китайцев всего можно ожидать.
Кроме того, не ясно что делает контроллер с резервированным местом. Варианты могут быть следующие:
1. Использует для информации об адресации. Т.е. фактически место занято служебными данными
2. Использует для SLC кеша (который делается не отдельным кешем а просто использованием MLC/TLC ячеек для хранения одного бита).
3. Просто холодные блоки в резерв. Которые подменяются, когда другие начинают плохо себя вести
4. Просто холодные блоки для компенсации брака. Т.е. производится SSD с запасом, но из не очень качественных чипов. При начальном тестировании бракованные просто отключаются. Если все оказались живы, то лишние блоки лежат просто мёртвым грузом (ну не выпускать же одинаковые модели с ёмкостями 240, 250, 256GB). Но думаю, всё-таки по факту пункт 3 используется, хотя от китайцев всего можно ожидать.
Это особенность исторического развития. В некоторых дисках служебная область выделялась производителем, в некоторых — нет. Соответственно, для последних было критично выдерживать запас свободного места. Для части SSD был даже софт от производителя, который позволял настроить, какая часть места должна быть зарезервирована под нужды накопителя.
У нормальных производителей ничего не отъедается. Те же Samsung заявляют 240Гб, и пользователю доступны реальных 240 000 000 000 байт. Сколько там задействовано в резерве — конечного пользователя не очень интересует. Так же возможно оставить свободное место и оно тоже будет использоваться для служебных нужд. А вот Transcend в своих новых накопителях умудряются на упаковке писать 256Гб с доступными для пользователя 250Гб
Эта хитрость для HDD, для SSD и флешек как я понимаю, используют «лишние» байты на служебные цели.
Это не хитрость, это просто использование нормальных (для непрограммистов) единиц измерения объемов любых носителей информации, о чём они честно пишут в спецификациях. Все SSD накопители, все флешки, даже те которые в принципе не умеют в дефрагментацию (хинт — большинство флешек, особенно китайских дешевых, не умеет, хоть навечно их подключайте к зарядке) — указывают объем в единицах SI, даже объемы переданной/передавамой информации в этих же единицах, исключение делают только для RAM, где 1GB = 1GiB = 2^30 байт.
"лишние" байты, если он и есть, как правило не учитываются в объеме заявленном пользователю, то есть если у нас есть SSD (или флешка) на 32GB, то это (как указано выше) 29.8GiB и точка — просто потому что 32GB, а не 32GiB, и любой резерв (коли таковой используется вообще) будет сверх этого объема (о чём тоже иногда пишут в спецификациях).
"Это не хитрость, это просто использование нормальных (для непрограммистов) единиц измерения объемов любых носителей информации, о чём они честно пишут в спецификациях. "
Угу и переход был именно когда это стало приносить ощутимый маркетинговый эффект, а пока были 10ки мегабайт всех производителей устраивали степени 2-ки
Как человек, тоже занимающийся SSD, хочу выразить огромную благодарность автору за статью. Сам уже больше года собираюсь написать про базовые вещи FTL, которые опровергают много мифов, но с моей дислексией и отсутствием времени появилось только несколько картинок… Теперь хочу немного пройтись по комментариям и ответить на вопросы.
1. GC. Без него не будет работать ни один nand-flash накопитель. Будь то серверный или самая дешевая китайская TFка;
2. Будет ли FTL «крутиться» без связи с хостом, одному разработчику FW известно. Штука чисто программная. Если у кого есть флешка, осциллограф и прямые ручки (у меня последнего не хватает такую мелочь паять), можете припаять проводок на ногу CS и посмотреть, дергается ли сигнал без хоста… На шину данные/команды паять крайне не рекомендую, так как она работает в DDR и подключение осцила, даже низкоемкостным щупом, почти гарантированно «испортит связь». Но, снова же — это для отдельного устройства будет.
3. Да, данные могут протухать. И достаточно быстро.
4. Не стоит выдергивать флешки и карты памяти без предварительного размонтирования. Там нет никаких конденсаторов, но есть алгоритм восстановления после пропадания питания, а на сколько он хорош — одному разработчику известно.
Теперь немного дополню и обнаглею.
По поводу падения скорости. Многие флешки-диски пишут данные вначале в область SLC, а потом, в фоне, переписывают их в MLC/TLC. Так как SLC операции — самые быстрые, то видна резкая просадка производительности после заполнения SLC кэша. Теперь наглость. Хотелось бы следующую статью, про trim, различие между накопителями с DDR и без, про «полезность» дефрагментации SSD средствами ОС… Видно, автор отлично разбирается в теме! А я, увы, грамотно и читабельно писать не умею:(
1. GC. Без него не будет работать ни один nand-flash накопитель. Будь то серверный или самая дешевая китайская TFка;
2. Будет ли FTL «крутиться» без связи с хостом, одному разработчику FW известно. Штука чисто программная. Если у кого есть флешка, осциллограф и прямые ручки (у меня последнего не хватает такую мелочь паять), можете припаять проводок на ногу CS и посмотреть, дергается ли сигнал без хоста… На шину данные/команды паять крайне не рекомендую, так как она работает в DDR и подключение осцила, даже низкоемкостным щупом, почти гарантированно «испортит связь». Но, снова же — это для отдельного устройства будет.
3. Да, данные могут протухать. И достаточно быстро.
4. Не стоит выдергивать флешки и карты памяти без предварительного размонтирования. Там нет никаких конденсаторов, но есть алгоритм восстановления после пропадания питания, а на сколько он хорош — одному разработчику известно.
Теперь немного дополню и обнаглею.
По поводу падения скорости. Многие флешки-диски пишут данные вначале в область SLC, а потом, в фоне, переписывают их в MLC/TLC. Так как SLC операции — самые быстрые, то видна резкая просадка производительности после заполнения SLC кэша. Теперь наглость. Хотелось бы следующую статью, про trim, различие между накопителями с DDR и без, про «полезность» дефрагментации SSD средствами ОС… Видно, автор отлично разбирается в теме! А я, увы, грамотно и читабельно писать не умею:(
По-моему у вас занижена самооценка, всё что вы написали, изложено внятно и понятно. Пишите статью.
По поводу писательского таланта — к сожалению, нет. По родному русскому всегда на уровне с тройки на двойку балансировал. А за 30 лет изучения английского еле еле достиг уровня Preintermidet, при этом, последние 2 года, каждый день переписываюсь с американскими коллегами. Через я.транслит, в основном:( В заготовках есть штук 5 статей на разные темы, но, перечитав, понимаю, что это не для публикации… Пару статей опубликовал, но на них, как мухи на говно пчелы на сахар слетелись граммарнаци, все желание отбили что то еще публиковать…
Возьмите в соавторы девушку с пятеркой по рус. яз. В принципе статьи хабра-формата не особо объемные — отредактировать статью должно быть не особо турдно/времяёмко. Я как-то помогал иностранцам готовить тексты на русском — вот это была песня. Даже так — песТня.
Да боже мой! Никто не пишет статьи за один присест. План, факт чекинг, воды налить, вычитать через пару дней и всё. Я вот не за пушкинским слогом сюда хожу и предпочитаю своеобразные, но содержательные тексты этим вот новым обзорам / переводам / графомании.
Пишите и публикуйте, если есть че :)
- GC. Без него не будет работать ни один nand-flash накопитель. Будь то серверный или самая дешевая китайская TFка
Тут вы ошибаетесь. Возьмите самую дешевую китайскуй флешку и перезапишите файл размером в пару килобайт пару тысяч раз (тольчо честно — с sync после каждой записи) — с вероятностью 90% она умрёт ещё на первой тысяче, чего не должно случатся при наличии хоть какого-то GC.
1. GC. Без него не будет работать ни один nand-flash накопитель. Будь то серверный или самая дешевая китайская TFка;
Будут работать накопители и без GC и прекрасно работали. Естественно алгоритмы ротации при большом заполнении статически данных становились менее эффективным. С учетом многократного падения надежности NAND памяти c переходом от SLC к MLC, TLC, QLC начали разработки микропрограмм которые могли бы более эффективно размещать данные, дабы большее число блоков участвовало в ротации, ради того, чтобы емкие устройства с дешевой памятью жили несколько больше. Так как микропрограммы контроллеров понятия не имеют в подавляющем большинстве о файловых системах используемых на накопителях, то взаимосвязь с хостом организована посредством TRIM, где контроллер NAND накопителя от хоста получает информацию об LBA диапазоне из логического пространства, который стал свободным от данных (как именно можно прочесть в АТА стандарте на t13.org). Далее эти места транслируются нулями, а микропрограмма контроллера ведет уже анализ какие блоки можно очистить целиком и можно ли собрать из блоков с малым заполнением какой-либо один блок-апдейт для трансляции. В случае конкретно USB flash и карт памяти речи о TRIM не шло и соответственно алгоритмы GC в принципе не закладывались в микрокод, в отличие от SSD.
2. Будет ли FTL «крутиться» без связи с хостом, одному разработчику FW известно.
Вся трансляция, что в картах памяти, что в USB flash, что в SSD работает без участие ОС. ОС компьютера в принципе не имеет представление о том с каким контроллером она работает и сколько микросхем NAND памяти у контроллера, как организован интерлив между ними, синхронный ли он, какого размера блоком оперирует контроллер и т.п. Для ПК это просто накопитель с которым можно работать по определенному протоколу с использованием команд описанных в стандарте. Для ПК доступен лишь LBA диапазон реализуемый устройством, и вся работа ПК с носителем сводится на уровне RW операций. С появлением TRIM лишь чуть-чуть добавилось передаваемых параметров, но ОС так и не получила какой-либо взаимосвязи с алгоритмами NAND контроллеров.
Если подразумевалось именно активность микропрограммы накопителя только лишь при подачи питания и отсутствия коммуникации с хост-контроллером, то в случае USB flash в подавляющем случае ждать попросту нечего по очевидным причинам. Вряд ли кто-то будет писать микропрограмму со сложным анализом расположения данных, когда эффективность этих алгоритмов без того же TRIM будет сводиться к почти нулю. Так как микропрограмма устройства в принципе ничего не знает о файловой системе на нем и лишь обслуживает RW операции. И без сообщения мест которые стали чистыми ей попросту неизвестно, что можно подчищать.
3. Да, данные могут протухать. И достаточно быстро.
При исправной не изношенной NAND памяти сносного качества не так и быстры процессы естественной деградации. Хватает в запасе NAND микросхем, которые уже хранятся не один год и при перечитывании в ридерах PC3000flash или Nand Reader (софт-центр) отдают дампы в которых можно скорректировать битовые ошибки. Но надо отметить, что с каждым годом хранения количество ошибок растет. Многие уже без Read Retry и манипуляций с напряжением нереально прочесть с приемлемым качеством дампа. В условиях живых USB flash мы как правило наблюдаем, что флешка пролежавшая несколько лет читается заметно медленнее и при чтении даже линейно расположенных данных наблюдаем провалы в скорости (из-за того, что контроллеру приходится проводить больше процедур перечитки микросхем и выше накладные расходы на коррекцию битовых ошибок) В случае флешки, где есть изношенные участки памяти (и они включены в трансляцию) такое проявление мы заметим намного быстрее. А если блоки со служебными данными (с тем же транслятором) попадут на изношенный блок, то и вовсе есть риски, что флешка может и не стартануть.
про «полезность» дефрагментации SSD средствами ОС…
учитывая, что ОС не имеет представления о фактическом расположении данных в NAND микросхемах, то дефрагментация ее средствами во многих случаях не будет полезной, а скорее будет просто множеством пустых RW операций сокращающих срок жизни устройства.
Блин, ну Вы одним своим комментарием перечеркнули всю ценность статьи, которую я пишу уже несколько месяцев. Единственное, не понял про GC (в Вашей интерпретации). Возможно, я под ним понимаю более широкий набор алгоритмов. Вплоть до переписывания валидных данных из блока, подготовленного к стиранию. Немного не понял, что Вы подразумеваете под алгоритмом ротации. Все равно надо искать кандидата на erase хотя бы по 2м параметрам: наименьшее количество валидных данных и изношенности. Или в самом простом случае можно обойтись без поиска, взяв самый «старый» блок? Работать, конечно будет, но медленно…
По второму пункту — почти со всем полностью согласен. Единственное, добавлю про многострадальный Trim (не для Вас, а других читателей). Он просто экономит ресурсы при освобождении блока, сообщая, что данные не валидны уже в самой ОС и их не надо переписывать при подготовке блока к стиранию. Но какая страница в блоке валидна, а какая — нет, относительно LBA, уже знает сам контроллер. И вот будет ли FTL «шушрать» в фоне, собирая данные, если мы подали только питание или размонтировали флешку — чисто программная штука.
По пункту 3. А что за память? SLC вообще не протухает, по крайней мере в обозримое время. MLC — хуже, а вот с TLC беда. Знаю несколько человек, у которых диски помирали через полгода-год простоя. QLC — так пока там гарантированное время хранения уже неделями исчисляется, хотя, это данные годичной давности, может что улучшили. А вот что флешка медленней читается после длительного простоя, думаю тут не только в ретраях дело, но еще и в «спасении» данных, то есть, прочитали на ретраях, перезаписали. Снова же, это только мои догадки, а что там творит FW — одному разработчику известно…
По поводу дефрагментации — полностью согласен, но слишком сильно этот миф укоренился в народных массах…
Спасибо за комментарий, было приятно прочитать. Сразу видно, что Вы или в индустрии или очень близко к ней.
По второму пункту — почти со всем полностью согласен. Единственное, добавлю про многострадальный Trim (не для Вас, а других читателей). Он просто экономит ресурсы при освобождении блока, сообщая, что данные не валидны уже в самой ОС и их не надо переписывать при подготовке блока к стиранию. Но какая страница в блоке валидна, а какая — нет, относительно LBA, уже знает сам контроллер. И вот будет ли FTL «шушрать» в фоне, собирая данные, если мы подали только питание или размонтировали флешку — чисто программная штука.
По пункту 3. А что за память? SLC вообще не протухает, по крайней мере в обозримое время. MLC — хуже, а вот с TLC беда. Знаю несколько человек, у которых диски помирали через полгода-год простоя. QLC — так пока там гарантированное время хранения уже неделями исчисляется, хотя, это данные годичной давности, может что улучшили. А вот что флешка медленней читается после длительного простоя, думаю тут не только в ретраях дело, но еще и в «спасении» данных, то есть, прочитали на ретраях, перезаписали. Снова же, это только мои догадки, а что там творит FW — одному разработчику известно…
По поводу дефрагментации — полностью согласен, но слишком сильно этот миф укоренился в народных массах…
Спасибо за комментарий, было приятно прочитать. Сразу видно, что Вы или в индустрии или очень близко к ней.
Единственное, не понял про GC (в Вашей интерпретации). Возможно, я под ним понимаю более широкий набор алгоритмов. Вплоть до переписывания валидных данных из блока, подготовленного к стиранию. Немного не понял, что Вы подразумеваете под алгоритмом ротации. Все равно надо искать кандидата на erase хотя бы по 2м параметрам: наименьшее количество валидных данных и изношенности. Или в самом простом случае можно обойтись без поиска, взяв самый «старый» блок? Работать, конечно будет, но медленно…
Сейчас будем говорить применительно к USB Flash. Давайте копнем немного работу ОС с носителем c файловой системой FAT32. На котором пусть будет крупный файл (например видео).
При удалении этого файла ОС удалит цепочку занимаемых кластеров из обеих копий таблиц, в директории, где была файловая запись проставит 0xE5 вместо первого байта имени файла. Непосредственно сами данные эта процедура не тронет.
Для NAND контроллера сначала поступит запрос на чтение группы секторов содержащий таблицы FAT и директорию (как правило это весьма небольшое количество блоков).
Следом поступят запросы на перезапись подобного или чуть меньшего объема (зависит от того как именно реализован драйвер, нормальный драйвер не будет предлагать переписывать содержимое таблиц, которое не изменилось).
После этой операции микропрограмма NAND контроллера USB Flash даже не подозревает о том, что огромное количество блоков занимаемых удаленным файлом теперь стали свободными (в случае SSD именно TRIM информирует об освобожденных LBA диапазонах). Эти блоки остаются включенными в трансляцию и по прежнему предоставляют те данные, которое они содержат.
Это утверждение легко проверить. Запишите на USB flash файл, сделайте с помощью WinHex образ. После удалите и опять сделайте образ. И сравните двай файла. Изменения будут только в элементах файловой системы, а в области данных никакой очистки не будет в накопителе без TRIM.
Так вот в случае накопителей, где нет обратной связи с ОС в принципе нет «мусора» (большого количества блоком с очень маленьким заполнением, который бы можно было срастить в одиночный, для более эффективной работы механизма выравнивания износа.)
Как я уже писал в одном комментарии, то можно взглянуть на одну из моих публикаций, где немного описан алгоритм NAND контроллера в USB flash
Знаю несколько человек, у которых диски помирали через полгода-год простоя. QLC — так пока там гарантированное время хранения уже неделями исчисляется, хотя, это данные годичной давности, может что улучшили.
обратите внимание, что я комментировал и указал про исправную память с малым износом. Для того, чтобы SSD или USB flash для пользователя превратились в кирпич достаточно, чтобы транслятор, который записан в тот же NAND перестал читаться. Вероятность попадания транслятора на изношенный блок достаточно высока, так как он постоянно модифицируемый в процессе работы накопителя. Но если в таком умершем накопителе выпаять NAND память, получить дампы, то как правило выясняется, что реальных потерь данных не так уж и много, разумеется если произвести корректную сборку с учетом многих нюансов алгоритмов.
А вот что флешка медленней читается после длительного простоя, думаю тут не только в ретраях дело, но еще и в «спасении» данных, то есть, прочитали на ретраях, перезаписали.
Как бы после чтения «медленных» файлов при второй попытке получите такие же результаты чтения.
Правда существенное торможение еще может быть при чтении неустойчиво читающихся кусках транслятора (не забываем о том, что MCU весьма скромный размер ОЗУ и в некоторых случаях держать полный транслятор недопустимая роскошь). И вот в этом случае, если по какой-то причине микропрограмма перепишет заново транслятор или его проблемную часть можно ожидать оживления накопителя.
Спасибо, я уже читал Вашу статью, что касается электроники — не пропускаю, по крайней мере стараюсь не пропустить ни одной статьи на Хабре. Но вернемся к GC.
Еще в середине 90х мне попалась книга Питера Нортона про устройство IBM совместимых компьютеров и был доступ «Поиску» у друга и в школе заменили советские Агаты на 386sx. Так что многие эксперименты над дискетами, которые можно было сделать, уже тогда сделал. Соответственно, как работает FAT — прекрасно понимаю. Но мы разошлись в терминологии. Вы понимаете под «мусором» те записи, которые не актуальны для ОС, а разработчики твердотельных накопителей понимают под «мусором» повторно перезаписанный LBA. Попытаюсь объяснить. Допустим, ОС модифицирует таблицу размещения файлов, допустим, восемнадцатый LBA. Ну и 10 раз его переписала. В текущем блоке NAND мы получили 10 записанных страниц, ассоциированных с 18 LBA. Соответственно, актуальной будет последняя запись, что будет отражено в «трансляторе», по нашему — L2P, таблица соответствий LBA и физического адреса в NAND. Так вот, когда блок будет подготавливаться к стиранию, будет переписана только последняя копия 18 LBA, остальное — мусор. Я под GC понимаю именно этот алгоритм. По большому количеству параметров выбирается кандидат для стирания. Один из них — количество валидных записей. Но валидных именно в «понимании» nand контроллера. Последняя копия, актуальная в L2P. Понятное дело, если Вы случайно попутали ссылки и скачали альбом рэп исполнителя, но тут же его удалили, весь этот трешак будет кочевать из блока в блок, пока на свободные, с точки зрения ОС LBA не будет произведена повторная запись. Но если мы «затримим» эти LBA со стороны ОС, в L2P они будут помечены как невалидные и не будут перемещены в новый блок, что экономит как время так и ресурс памяти… Надеюсь, под GC мы пришли к общему знаменателю!
По поводу «транслятора». Я не могу много написать из за соглашения о неразглашении, но некоторые вещи, размещенные в общем доступе, могу озвучить. Ну во первых, сама L2P очень даже не маленькая. Ее размер легко прикинуть по простой формуле. Делим объем накопителя на 1000 и получаем размер L2P. Для небольших накопителей коэффициент может быть больше просто из за меньшей разрядности физического адреса NAND, например, 1500. Но все равно — для накопителя в 1Gb надо иметь таблицу в 1Mb. Соответственно, никто столько ОЗУ в контроллер не положит. 1Gb — это уже позавчерашний день, на 8-16-32 уже копейки стоит. Так что L2P кешируется небольшими частями и «размазана» по всей памяти. И утрата одной из частей — не катастрофа. Скажу так, я смогу восстановить всю таблицу, даже если она будет полностью утеряна. Конечно, на своем железе со своими алгоритмами. Вот тут и проявляется разница. Даже если контроллер и память одинаковые, накопитель от известного бренда будет гораздо надежней, чем нонейм.
Надеюсь, и на последний пункт я ответил. L2P постоянно переписывается, не вся, а то, что изменилось. Но если даже будет утрачен кусок, в качественных накопителях он будет восстановлен и перезаписан.
Еще в середине 90х мне попалась книга Питера Нортона про устройство IBM совместимых компьютеров и был доступ «Поиску» у друга и в школе заменили советские Агаты на 386sx. Так что многие эксперименты над дискетами, которые можно было сделать, уже тогда сделал. Соответственно, как работает FAT — прекрасно понимаю. Но мы разошлись в терминологии. Вы понимаете под «мусором» те записи, которые не актуальны для ОС, а разработчики твердотельных накопителей понимают под «мусором» повторно перезаписанный LBA. Попытаюсь объяснить. Допустим, ОС модифицирует таблицу размещения файлов, допустим, восемнадцатый LBA. Ну и 10 раз его переписала. В текущем блоке NAND мы получили 10 записанных страниц, ассоциированных с 18 LBA. Соответственно, актуальной будет последняя запись, что будет отражено в «трансляторе», по нашему — L2P, таблица соответствий LBA и физического адреса в NAND. Так вот, когда блок будет подготавливаться к стиранию, будет переписана только последняя копия 18 LBA, остальное — мусор. Я под GC понимаю именно этот алгоритм. По большому количеству параметров выбирается кандидат для стирания. Один из них — количество валидных записей. Но валидных именно в «понимании» nand контроллера. Последняя копия, актуальная в L2P. Понятное дело, если Вы случайно попутали ссылки и скачали альбом рэп исполнителя, но тут же его удалили, весь этот трешак будет кочевать из блока в блок, пока на свободные, с точки зрения ОС LBA не будет произведена повторная запись. Но если мы «затримим» эти LBA со стороны ОС, в L2P они будут помечены как невалидные и не будут перемещены в новый блок, что экономит как время так и ресурс памяти… Надеюсь, под GC мы пришли к общему знаменателю!
По поводу «транслятора». Я не могу много написать из за соглашения о неразглашении, но некоторые вещи, размещенные в общем доступе, могу озвучить. Ну во первых, сама L2P очень даже не маленькая. Ее размер легко прикинуть по простой формуле. Делим объем накопителя на 1000 и получаем размер L2P. Для небольших накопителей коэффициент может быть больше просто из за меньшей разрядности физического адреса NAND, например, 1500. Но все равно — для накопителя в 1Gb надо иметь таблицу в 1Mb. Соответственно, никто столько ОЗУ в контроллер не положит. 1Gb — это уже позавчерашний день, на 8-16-32 уже копейки стоит. Так что L2P кешируется небольшими частями и «размазана» по всей памяти. И утрата одной из частей — не катастрофа. Скажу так, я смогу восстановить всю таблицу, даже если она будет полностью утеряна. Конечно, на своем железе со своими алгоритмами. Вот тут и проявляется разница. Даже если контроллер и память одинаковые, накопитель от известного бренда будет гораздо надежней, чем нонейм.
Надеюсь, и на последний пункт я ответил. L2P постоянно переписывается, не вся, а то, что изменилось. Но если даже будет утрачен кусок, в качественных накопителях он будет восстановлен и перезаписан.
а разработчики твердотельных накопителей понимают под «мусором» повторно перезаписанный LBA. Попытаюсь объяснить. Допустим, ОС модифицирует таблицу размещения файлов, допустим, восемнадцатый LBA. Ну и 10 раз его переписала. В текущем блоке NAND мы получили 10 записанных страниц, ассоциированных с 18 LBA.
Дело в том, что во многих алгоритмах флешек транслятор в сравнении с SSD сильно упрощен. Многие каждую попытку записи в тот же FAT будут отрабатывать так:
1) Чтение целиком блока (группы страниц).
2) Очистка прочитанного блока в NAND.
3) Внесение незначительного изменению в одну из страничек.
4) Выбор оптимального блока для записи и запись.
На таких флешках получаем колоссальный провал в скорости записи на мелких файлах.
Как правило более новые алгоритмы уже не спешат трогать оригинальный блок и просто формируют блок-апдейт в котором содержатся группа модифицированных страниц которые включаются в разные места в трансляции.
Блоки-апдейты используются как точечные наложения на трансляцию. Но в ограниченных условиях USB flash их количество не бывает особо большим. Микропрограммы использующие блоки-апдейты во многих флешках весьма просты. Некоторые из них «подглядывают» в юзерзону и определяю положение таблиц FAT или применяют данный метод для первых блоков в трансляции и для них используют методы писания исключительно блоками-апдейтам. У таких флешек есть некоторое подобие «уборки мусора», но оно обычно весьма быстротечно и обычно достаточно нескольких секунд после окончания копирования, чтобы флешках завершила процессы с этим «мусором».
По поводу «транслятора». Я не могу много написать из за соглашения о неразглашении, но некоторые вещи, размещенные в общем доступе, могу озвучить. Ну во первых, сама L2P очень даже не маленькая. Ее размер легко прикинуть по простой формуле. Делим объем накопителя на 1000 и получаем размер L2P. Для небольших накопителей коэффициент может быть больше просто из за меньшей разрядности физического адреса NAND, например, 1500. Но все равно — для накопителя в 1Gb надо иметь таблицу в 1Mb. Соответственно, никто столько ОЗУ в контроллер не положит.
Для современных носителей коэффициент похожий. Для старых коэффициент поболее.
Например флешка 1Гб, размер блока 0x21000 байт (128кб полезных данных), страница 2112 байт, размер данных в ней 2048.
Для блочной трансляции нужно 8192 блоков, чтобы сформировать полный гигабайт. Для описания очередности использования часто применялись двухбайтовые записи с порядковым номером физического блока в логическом банке. Т.е для описания L2P нужно 16 384 байта. Добавим к этому еще дополнительные таблицы похожего размера и в принципе получим реальный размер транслятора. В такой маленькой старой флешке он не превысит 64-128кб в сумме. Округлим до 128кб и это даст соотношение 1 к 8192.
Разумеется даже в таких флешках правило имело место деление на логические банки и у каждого банка была своя табличка трансляции.
Скажу так, я смогу восстановить всю таблицу, даже если она будет полностью утеряна. Конечно, на своем железе со своими алгоритмами.
многие разработчики в страницы кроме пользовательских данных и ECC отводят место для номера блока/страницы (не везде конечно), различных флажков и т.п. И знаю, где и что значат байты, биты в служебке несложно реконструировать актуальные таблицы трансляции. Или провести сборку образа зная как интерпретировать служебные данные.
Так что L2P кешируется небольшими частями и «размазана» по всей памяти. И утрата одной из частей — не катастрофа.Для пользователя это таки обычно катастрофа так как в большинстве простых фирмварей нет в помине каких-либо процедур для реконструкции транслятора.
Даже если контроллер и память одинаковые, накопитель от известного бренда будет гораздо надежней, чем нонейм.С большими оговорками. Например в случае USB flash, где подобные наборы одинаковых микросхем друг от дружки отличает только текстовая строчка с названием в паспорте устройства и пластик корпуса вряд ли можно назвать справедливым.
Не буду спорить о том, чего не видел. Возможно, в старых флешках так и работало, когда память — SLC а размеры блока исчисляются десятками килобайт. Но вот у меня на столе лежит россыпь нанды, уже относительно старой (пару лет назад выпущенной), так там размер блока — более 10 мегабайт. А гарантированное количество стираний — меньше 1000. Так что «фокус» с переписыванием блока — однозначно не пройдет, а алгоритмы работы современных флешек скорее ближе к SSD, чем к тому, о чем Вы писали (снова же, по моему скромному мнению и имеющийся информации, за всех производителей отвечать не буду). Но мне пришла мысль, что я — Колобок. Поскребся по сусекам и нашел следующее:
1. Современную TF. От известного производителя, была подарком при покупке смартфона от того же производителя (32G).
2. Современную TF. От неизвестного производителя, была положена в комплект 3D принтера добрыми китайцами (8G).
3. USB флешка от не самого известного производителя, куплена лет 8 назад, на тот момент — одна из «топовых», «корпус» из натуральной кожи, похоже даже не молодого дерматина, так как до сих пор имеет товарный вид, хромированная фурнитура. На тот момент — одна из самых емких по еще приличной цене (16G).
4. USB флешка от нонейма, хоть на ней и гордо красуется «Texas Instruments», это рекламная раздаточная продукция с семинара, который посещал лет 10 назад. Честно, даже забыл, где мне ее «вручили». (256M)
Ну и решил их потестить. Понимаю, что методика теста — сродни определения направления и силы ветра указательным пальцем, но тенденцию можно проследить. Использовал Гном Диск, точнее, его тест производительности. К сожалению, минимальный объем чанка — 1М, По этому я тестировал на 10М и 1М и некоторые — на 100М. Да, это не мелкие файлы, но снова же, тенденцию уловить можно. Итак, результаты получились интересные.
— Первая TFка что на большом, что на малом чанке показала почти одинаковую среднюю производительность. Но на больших кусках был явно виден меандр, а на малых — такой шум, что производительность скакала от средней на +-30%, но итоговая отличалась на проценты. ~7.6Мб/с против ~7.2Мб/с. Очень похоже, что используется SLC кеширование. Но кэш достаточно скромный.
— Вторая TFка так же показала почти одинаковую производительность на больших и малых кусках, только «шум» был почти незаметен. Провал по скорости относительно «фирмы» — 1Мб/с. Но на ней как то странно выглядело чтение. Если на всех остальных экземплярах — график скорости чтения был почти прямой, 10/12Мб/с, то на этой иногда проваливался до 3х.
— А вот дорогущая USB повела себя странно. На больших кусках чуть больше 5Мб/с, а вот на малых — иногда опускался меньше 3х. И эти малые куски — не такие уж и малые. Похоже, какой то переходной вариант, память уже более менее современная, скорее всего MLC, а алгоритмы не доработанные. Да и без теста, когда ей активно пользовался, по ощущениям запись была очень медленная.
— USB флешка от Ti. Блин, интересная штука. Выиграла по скорости записи больших кусков почти у всех экземпляров, поделив первое место с фирменной TFкой, А вот на маленьких — упала с 7.6 до 5.3… Относительно маленьких. Но все равно обгоняет USB на 16 Гб. Похоже, там как раз используется алгоритм, описанный Вами. К сожалению не могу задать совсем маленький кусок, чтоб еще сильнее продемонстрировать разницу. К тому же — по скорости чтения она обогнала всех! 15Мб/с. Вот что SLC животворящий делает даже при примитивных алгоритмах. Хотел посмотреть, что там за чип и нанд, но нехороший производитель затер все маркировки.
Какой вывод сделал лично я для себя — современные флешки ближе к SSD по алгоритмам управления памятью. А вот реальную пользу от «зарядки» я так и не понял, это надо брать современный, накопитель, раздраконивать и тыкать осциллоскопом.
1. Современную TF. От известного производителя, была подарком при покупке смартфона от того же производителя (32G).
2. Современную TF. От неизвестного производителя, была положена в комплект 3D принтера добрыми китайцами (8G).
3. USB флешка от не самого известного производителя, куплена лет 8 назад, на тот момент — одна из «топовых», «корпус» из натуральной кожи, похоже даже не молодого дерматина, так как до сих пор имеет товарный вид, хромированная фурнитура. На тот момент — одна из самых емких по еще приличной цене (16G).
4. USB флешка от нонейма, хоть на ней и гордо красуется «Texas Instruments», это рекламная раздаточная продукция с семинара, который посещал лет 10 назад. Честно, даже забыл, где мне ее «вручили». (256M)
Ну и решил их потестить. Понимаю, что методика теста — сродни определения направления и силы ветра указательным пальцем, но тенденцию можно проследить. Использовал Гном Диск, точнее, его тест производительности. К сожалению, минимальный объем чанка — 1М, По этому я тестировал на 10М и 1М и некоторые — на 100М. Да, это не мелкие файлы, но снова же, тенденцию уловить можно. Итак, результаты получились интересные.
— Первая TFка что на большом, что на малом чанке показала почти одинаковую среднюю производительность. Но на больших кусках был явно виден меандр, а на малых — такой шум, что производительность скакала от средней на +-30%, но итоговая отличалась на проценты. ~7.6Мб/с против ~7.2Мб/с. Очень похоже, что используется SLC кеширование. Но кэш достаточно скромный.
— Вторая TFка так же показала почти одинаковую производительность на больших и малых кусках, только «шум» был почти незаметен. Провал по скорости относительно «фирмы» — 1Мб/с. Но на ней как то странно выглядело чтение. Если на всех остальных экземплярах — график скорости чтения был почти прямой, 10/12Мб/с, то на этой иногда проваливался до 3х.
— А вот дорогущая USB повела себя странно. На больших кусках чуть больше 5Мб/с, а вот на малых — иногда опускался меньше 3х. И эти малые куски — не такие уж и малые. Похоже, какой то переходной вариант, память уже более менее современная, скорее всего MLC, а алгоритмы не доработанные. Да и без теста, когда ей активно пользовался, по ощущениям запись была очень медленная.
— USB флешка от Ti. Блин, интересная штука. Выиграла по скорости записи больших кусков почти у всех экземпляров, поделив первое место с фирменной TFкой, А вот на маленьких — упала с 7.6 до 5.3… Относительно маленьких. Но все равно обгоняет USB на 16 Гб. Похоже, там как раз используется алгоритм, описанный Вами. К сожалению не могу задать совсем маленький кусок, чтоб еще сильнее продемонстрировать разницу. К тому же — по скорости чтения она обогнала всех! 15Мб/с. Вот что SLC животворящий делает даже при примитивных алгоритмах. Хотел посмотреть, что там за чип и нанд, но нехороший производитель затер все маркировки.
Какой вывод сделал лично я для себя — современные флешки ближе к SSD по алгоритмам управления памятью. А вот реальную пользу от «зарядки» я так и не понял, это надо брать современный, накопитель, раздраконивать и тыкать осциллоскопом.
Сейчас (у меня, по крайней мере) флешки свалены в ящик или на столе раскиданы.
А вот был бы такой «банк»-зарядник флешек, чтобы стоял на столе, и флешки не разбрасывать везде, а втыкать их туда, как на обычное хранение. А эта штуковина периодически подавала на воткнутые флешки питание. Наверное, ей самой можно было бы питаться или от батареек или от своего аккумулятора, ну сколько флешкам тока нужно, если запитывать их только изредка…
И форм-фактор в виде маленького шкафчика с дверкой (чтобы случайно не махнуть рукой и не выломать все торчащие флешки с корнем).
Фактически это переносной аккумулятор, как просто для подзарядки телефонов, только чуточку умнее, чтобы раз в неделю на сутки сам подавал питание на свои USB-порты по расписанию.
А вот был бы такой «банк»-зарядник флешек, чтобы стоял на столе, и флешки не разбрасывать везде, а втыкать их туда, как на обычное хранение. А эта штуковина периодически подавала на воткнутые флешки питание. Наверное, ей самой можно было бы питаться или от батареек или от своего аккумулятора, ну сколько флешкам тока нужно, если запитывать их только изредка…
И форм-фактор в виде маленького шкафчика с дверкой (чтобы случайно не махнуть рукой и не выломать все торчащие флешки с корнем).
Фактически это переносной аккумулятор, как просто для подзарядки телефонов, только чуточку умнее, чтобы раз в неделю на сутки сам подавал питание на свои USB-порты по расписанию.
Выглядит, как идея для стартапа! Только батарейное питание — излишне. Пусть всегда к компу подключен, а у каждой флешки — кнопка, чтоб по ее нажатию она к хосту соединялась. Патентуйте, а то китайцы уже выпуск наладят!
На мой взгляд, это будет очень полезная вещь, сравнимая разве что со знаменитым перемотчиком DVD. :)
У меня дома в столе валяется около 20 флешек, от первой приобретенной (на 128 МБ, USB1)
до современных. Данные не терялись частично ни разу, флешки либо дохли целиком, либо уходили в ридонли безвозвратно.
У меня дома в столе валяется около 20 флешек, от первой приобретенной (на 128 МБ, USB1)
до современных. Данные не терялись частично ни разу, флешки либо дохли целиком, либо уходили в ридонли безвозвратно.
Всё уже украдено до нас)
Например, на 24 порта
Как скучно я живу то…
Кхм, статья не раскрыта полностью.
1) я согласен что контроллеру флешки «возможно» нужно время на оптимизацию работы с памятью флешки.
2) нет описания того, как поведет себя флешка если её тыкать в зарядник для телефона/планшета.
Насколько я знаю, телефоны/планшеты и т.д. современные гаджеты всё чаще используют быструю зарядку с помощью импульсной зарядки (даже моя старая нокия испульсником заряжалась). Отсюда вопрос: насколько корректно флешку, рассчитанную на работу с постоянным током, тыкать в зарядку с импульсной подачей питания, и умеет ли последняя определять что устройству нужен постоянный ток? И как это работает. Вот этот вопрос осветить бы.
Я читал статью про USB 3.1+ и целый веер технологий быстрой зарядки по USB с дикими токами и даже поднятием вольтажа! Но там везде умные контроллеры, которые определяют устройство и возможную максимальную подачу питания. К сожалению почти каждый производитель такой технологии уже сверх-быстрого заряжания лепить своё виденье со своими контроллерами и кардебалетом, отчего часто они не совместимы у разных производителей.
1) я согласен что контроллеру флешки «возможно» нужно время на оптимизацию работы с памятью флешки.
2) нет описания того, как поведет себя флешка если её тыкать в зарядник для телефона/планшета.
Насколько я знаю, телефоны/планшеты и т.д. современные гаджеты всё чаще используют быструю зарядку с помощью импульсной зарядки (даже моя старая нокия испульсником заряжалась). Отсюда вопрос: насколько корректно флешку, рассчитанную на работу с постоянным током, тыкать в зарядку с импульсной подачей питания, и умеет ли последняя определять что устройству нужен постоянный ток? И как это работает. Вот этот вопрос осветить бы.
Я читал статью про USB 3.1+ и целый веер технологий быстрой зарядки по USB с дикими токами и даже поднятием вольтажа! Но там везде умные контроллеры, которые определяют устройство и возможную максимальную подачу питания. К сожалению почти каждый производитель такой технологии уже сверх-быстрого заряжания лепить своё виденье со своими контроллерами и кардебалетом, отчего часто они не совместимы у разных производителей.
Ничего страшного с флешкой не произойдет. Импульсный — это всего лишь тип AC/DC преобразователя. Сейчас почти все источники — импульсные, линейных уже давно не встречал. На выходе — все те же постоянные 5В. По умолчанию, любая зарядка на выходе гарантирует 5В и не менее 500мА, по подтяжкам D+ D- устройство может распознать, что зарядка может выдать 2А и включить быстрый режим (USB 2.0). Что касается не стандарта, типа повышенного напряжения, то это устройства уже сами должны «договориться». Так что флешку спалить — не получится.
О каких нестандартных контактах идёт речь? Если это Redmi Note 9 Pro на квалкоме (судя по 30 Вт зарядке), то там Quick Charge 4 и он работает через обычные провода. Этот стандарт также совместим с PD, но при использовании истояника питания с PD не получится использовать быструю зарядку на всю катушку, потому что PD даёт меньше свободы в выборе напряжений, чем QC 4. Конкретный результат будет зависеть от того какой именно источник питания с PD вы взяли и какие наборы напряжений он способен выдавать.
Недавно изучал тему больших SSD для хранения архивов (хотел тихий, быстрый и компактный), прочитал про вот такие потенциальные проблемы и решил пока купить HDD на 10Тб за ту же цену, что самый дешевый SSD на 2. Доволен выбором. Кстати, ни разу не встречал проблемы старения данных на HDD, разве что если он был посыпавшимся. С исправного все прекрасно читается через многие годы.
Заклинить-то может. И они еще к ударам и падениям плохо относятся. Но все же нет такой проблемы, чтобы оно протухало со временем :-) К тому же, всегда держу 2 копии — одна рабочая в постоянном доступе, а вторая в офлайне, включается только для синхронизации раз в 2-3 месяца. Фотки и документы вообще на 3-х отдельных устройствах, код на гитхабе в приватном репо. Остальное не так критично.
всегда держу 2 копии
На прошлой неделе я, наводя порядок на таком офлайн-диске, случайно сделал rm -rf не в той папке и стёр бэкапы. Повторное создание бэкапов я решил отложить на следующий день (ибо было некогда), но уже через несколько часов после удаления скоропостижно скончался основной диск без предупреждения (ещё за день до этого показатели smart были в полном порядке), и в итоге я лишился всех своих фоточек за последние десять лет. В общем, лучше держать третью копию в облаке)
на 3-х отдельных устройствах
Их стоит географически разделить, а то мало ли чего
Эх, сочувствую… Но вообще, результат rm -rf вполне себе обратно восстановим, если не записывали ничего после. Я очень аккуратно синхронизирую с бэкапом, все в ручном режиме через FreeFileSync. Давно пора про него статейку написать, настолько он удобен. А операции с файлам предпочитаю делать через 2-панельные менеджеры типа FAR. Даже в линуксе не переучился на консоль, продолжаю пользоваться Midnight Commander.
Но 3 бэкапа важной информации, конечно, актуальны.
Но 3 бэкапа важной информации, конечно, актуальны.
через FreeFileSync. Давно пора про него статейку написатьhabr.com/ru/post/486532
Вы не пользовались случаем SyncToy от MS? Я уже лет десять ей пользуюсь, но есть один минус: нет опции автоматической синхронизации по втыканию накопителя, а руками каждый раз настраивать по событию лень. Я к чему: если у вас есть опыт разных синхронизаторов, может сделаете обзорчик?
Раньше пользовался SyncToy, но у него есть «фатальный недостаток» (тм), хотя этот термин, по иронии судьбы, принадлежит самой майкрософт. SyncToy не умеет показывать и резолвить конфликты. Если на обеих сторонах файл поменялся, то он просто молча предложит взять более новый, а не покажет конфликт. И это очень критично для инструмента такого типа. Еще у него были какие-то глюки, но я подзабыл. FFS, на мой взгляд, значительно удобнее. Он, кстати, умеет синхронизировать все что угодно: ftp, mtp (телефон) и т.д. Ну и есть командная строка — пока не пользуюсь ей, люблю предварительно посмотреть, что он пытается синхронизировать.
Другими инструментами пока не пользовался. Народ еще любит rsync, он очень гибок.
Другими инструментами пока не пользовался. Народ еще любит rsync, он очень гибок.
А что значит "не покажет конфликт"? ST вполне показывает список планируемых добавлений/замен/удалений, если ему заказать превью перед прогоном, и нужные действия можно отменить. А FFS может в сами файлы заглядывать, аппендить например документы офиса?
В rsync тоже посмотрю, спасибо за упоминание.
Есть разница между авто-заменой файла при обновлении и показом конфликта с ручным его разрешением. Попробуйте следующее:
— синхронизировать 2 папки
— сначала поменять какой-то файл слева
— потом поменять его же справа
— попытаться снова синхронизировать
ST просто предложит затереть файл слева версией справа, так как она более новая. И я боюсь, что вы уже не раз таким образом затирали какие-то изменения, когда успели поменять файлы на обеих сторонах. FFS скажет, что оба файла поменялись с момента предыдущей синхронизации и не будет ничего синхронизировать, пока вы не выберете, что делать: скопировать слева направо, справа налево или разрешить конфликт вручную, а затем уже скопировать новую версию в обе папки. FFS не умеет показывать diff, насколько я знаю. Я пользуюсь внешней программой для этого (любым сравнивателем). Если вам надо сравнивать бинарные файлы типа офисных, то тут нужны правильные компарилки. Они есть, но не универсальные.
Для часто изменяемых файлов гораздо проще пользоваться облаком для синхронизации.
— синхронизировать 2 папки
— сначала поменять какой-то файл слева
— потом поменять его же справа
— попытаться снова синхронизировать
ST просто предложит затереть файл слева версией справа, так как она более новая. И я боюсь, что вы уже не раз таким образом затирали какие-то изменения, когда успели поменять файлы на обеих сторонах. FFS скажет, что оба файла поменялись с момента предыдущей синхронизации и не будет ничего синхронизировать, пока вы не выберете, что делать: скопировать слева направо, справа налево или разрешить конфликт вручную, а затем уже скопировать новую версию в обе папки. FFS не умеет показывать diff, насколько я знаю. Я пользуюсь внешней программой для этого (любым сравнивателем). Если вам надо сравнивать бинарные файлы типа офисных, то тут нужны правильные компарилки. Они есть, но не универсальные.
Для часто изменяемых файлов гораздо проще пользоваться облаком для синхронизации.
Попробуйте следующее:
Попробовал
Можно отменить синхронизацию, можно открыть обе папки и посмотреть в файлы, и всё такое. Изображения можно посмотреть в полном размере
Можно отменить синхронизацию, можно открыть обе папки и посмотреть в файлы, и всё такое. Изображения можно посмотреть в полном размере
ST просто предложит затереть файл слева версией справа, так как она более новая. И я боюсь, что вы уже не раз таким образом затирали какие-то изменения, когда успели поменять файлы на обеих сторонах. FFS скажет, что оба файла поменялись с момента предыдущей синхронизации и не будет ничего синхронизировать, пока вы не выберете, что делать: скопировать слева направо, справа налево или разрешить конфликт вручную, а затем уже скопировать новую версию в обе папки.Ноты предвзятости вижу я, избежать которых пытался, и разгадать не могу истинную причину: преданность ли открытому, на светлую сторону ведущая, или ненависть к тёмной стороне, которая сама на тёмную сторону незаметно заберёт.
Не бойтесь за меня, я за многие годы ничего никуда не перезаписал, у меня всё со зрением и внимательностью в порядке :)
В общем, я прочёл мануал по FFS, в целом он может всё то же самое ±лапоть, но по всяким допфичам он для меня оверкилл, копаний не стòящий; по скриншотам визуально тоже перебор. Только вот автосинхронизация по подключению устройства манит очень, этого у ST не будет скорее всего никогда.
Для часто изменяемых файлов гораздо проще пользоваться облаком для синхронизации.Поддерживаю, так и делаю. Но, тем не менее, FFS умеет синхронизировать в реальном времени, у него служба есть.
Есть разница между Overwrite и Conflict. Я на Overwrite в FFS теперь не смотрю, а в ST приходилось каждый файл проверять. Теперь проверяю только конфликтные файлы, которых обычно 1-2 от силы, тогда как Overwrite сотнями накапливаются за неделю.
А, госпаде, вы об этом. У меня-то конфликтов вообще не бывает, я только с одним носителем работаю, совсем изредка влезая в другой, когда лень сходить за основным, иначе, если править одни и те же файлы в обоих, а потом солвить конфликты индивидуально, то это не работа и бэкап, а фигня какая-то. Мне бы было тоскливо мёрджить фотошопные маски с настройками или выискивать где я навертел какие объекты в модели.
В общем ещё раз спасибо за информацию, FFS для меня функционально перебор.
В общем ещё раз спасибо за информацию, FFS для меня функционально перебор.
Amazon S3 Glacier Deep Archive. Думаю, это надёжнее, чем хранить самостоятельно. Да, не бесплатно. Но 0,00099 USD за гигабайт — это немного. Даже с учётом того, что отдельно оплачивается извлечение данных (0,0025 USD за гигабайт). Не так и часто нужно извлекать.
Пойду заряжу мышку. Ну, на всякий…
Кроме шуток, у меня мышь с программируемыми кнопками после длительного бездействия забывает переназначения кнопок и приходится заново прогружать конфиг в мышь.
У нас одно время в конторе были беспроводные на аккумуляторах, заряжались естественно через USB шнурок. В пятницу вечером не воткнул на зарядку — в понедельник работаешь на проводной
Да, это феерично. Более того: даже если умудриться расположить её так, чтобы хоть как-то ездить по поверхности – работать не будет. Почему-то в клавиатуре они осилили зарядку во время работы, а в мышке нет (и разъём сбоку не осилили).
В статье желаемое выдаётся за действительное, я тоже мечтаю, чтобы технологии SSD пришли в USB-флешки. Но это лишь мечты.
Если бы контроллеры флешек занимались сбором мусора, производители первыми бы разрекламировали такую фичу ибо это серьёзное конкурентное преимущество. Значит рекламировать нечего.
Когда в SSD появились сборщики мусора тут же возникла необходимость TRIM, о чем одномоментно узнали все пользователи и о чем много написано выше. До этого trim не был нужен, полагаю неспроста.
Если бы контроллеры флешек занимались сбором мусора, производители первыми бы разрекламировали такую фичу ибо это серьёзное конкурентное преимущество. Значит рекламировать нечего.
Когда в SSD появились сборщики мусора тут же возникла необходимость TRIM, о чем одномоментно узнали все пользователи и о чем много написано выше. До этого trim не был нужен, полагаю неспроста.
А если вспомнить историю с 840 evo (samsung!), где только во второй (!) версии исправления появилась периодическая фоновая перезапись…
А с другой стороны лет этой истории уже дофига.
А с другой стороны лет этой истории уже дофига.
www.cnews.ru/news/top/prichinoj_poteri_dannyh_v_nakopitelyah
Правда там PRO упоминается.
Правда там PRO упоминается.
840 evo — одна из ранних моделей на tlc (2d, 19nm). Блоки данных, к которым долго (месяцами) не обращались, начинают читаться на пониженных скоростях (видел порядка 30 МБ/с). Про патч — https://habr.com/ru/post/378575/
подробности
Первые сообщения https://www.anandtech.com/show/8550/samsung-acknowledges-the-ssd-840-evo-read-performance-bug-fix-is-on-the-way + https://www.overclock.net/forum/355-ssd/1507897-samsung-840-evo-read-speed-drops-old-written-data-drive.html
Первый патч, 2014 https://www.anandtech.com/show/8617/samsung-releases-firmware-update-to-fix-the-ssd-840-evo-read-performance-bug (https://habr.com/ru/post/362647/) и пояснение физики процесса — в tlc ячейке есть 8 уровней заряда (для хранения 3 бит), электроны из fg flash постепенно утекают. В контроллере есть алгоритм, учитывающий и моделирующий утечку заряда, и для старых ячеек он мог выдавать неверные уровни напряжений — процесс считывания многократно повторялся контроллером для получения достаточно качественных блоков данных (чтобы ecc сработал).
Второй патч 2015-04 https://www.anandtech.com/show/9196/samsung-releases-second-840-evo-fix (https://habr.com/ru/post/378575/) — прошивка начинает периодически перезаписывать старые данные (в другие блоки) "time installing a firmware that periodically refreshes old data rather than the one-off refresh of the performance restoration tool.", оценки журналистов "our own calculations even 5 years of refreshes at 1/week would only be 26% of the drive’s rated 1000 cycle lifetime.".
У меня есть диск из этого семейства с OEM прошивкой. Патченную прошивку от самсунга их софт поставить не может; оем производитель патч к своей версии прошивки не применил. Уже несколько раз делал бэкап + https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase для сброса всего диска; после erase (trim) производительность в целом восстанавливается.
Говорят эти диски вполне часто мрут — часть прошивки и служебные таблицы лежат в nand flash массиве и если блоки с ними не читаются (после многомесячного хранения диска в выключенном состоянии) — то накопитель погибает — https://blog.elcomsoft.ru/2018/12/pochemu-ssd-vyihodyat-iz-stroya-kto-vinovat-i-chto-delat/. Есть неоконченное мегаисследование диска — http://www2.futureware.at/~philipp/ssd/TheMissingManual.pdf
Пример сдвига напряжений для qlc, полгода при 40 градусах и высоком износе, модель https://www.flashmemorysummit.com/English/Collaterals/Proceedings/2017/20170809_FF21_Miladinovic.pdf#page=7
Теоретические подробности в целом для флэш-памяти — https://arxiv.org/pdf/1706.08642.pdf Read disturb errors, Retention errors, P/E cycling errors, Program errors, Cell-to-cell interference errors; 5 Error mitigation — refresh mechanisms (2й патч 840evo), read retry (медленное чтение), voltage optimisation, ...
Формально, TRIM не нужен пока есть свободное место — просто GC будет намного более медленным и печальным (чем меньше места — тем печальней). Современные SSD, особенно энтерпрайзные, прекрасно обходятся без него (потому что многие железные RAID контроллеры его просто не поддерживают).
Шикарные картинки!
Ну и за ликбез спасибо!
Ну и за ликбез спасибо!
Знаю я тут одну флешку, тоже заряжается перед работой)))
Контент огонь) Спасибо
А SD-карты, что с ними?
А они всё равно сдохнут быстрее, чем заполнятся.
Шутка конечно, однако надёжность там околонулевая — в разы меньше, чем у флешек. Мне попадались флешки, которые прожили более 10 лет, но ни разу не приходилось видеть MicroSD-карточку, которая при более-менее активном использовании (внутри RPi, к примеру) прожила бы хотя бы два года.
3.5" дискетки по ощущениям надёжнее и живучее, чем эти карточки.
Шутка конечно, однако надёжность там околонулевая — в разы меньше, чем у флешек. Мне попадались флешки, которые прожили более 10 лет, но ни разу не приходилось видеть MicroSD-карточку, которая при более-менее активном использовании (внутри RPi, к примеру) прожила бы хотя бы два года.
3.5" дискетки по ощущениям надёжнее и живучее, чем эти карточки.
Юзайте правильную файловую систему.
> прожила бы хотя бы два года.
Ну у меня таких несколько. Начиная от «больших» SD на 32G, несколько микро на 64 и одна на 256. Причем большая SD работала как накопитель для торрент-клиента года 3-4.
По поводу RPi — там свои заморочки, и я в общем то не удивлен. Часто слышал что в них карточки убиваются буквально за полгода.
Ну у меня таких несколько. Начиная от «больших» SD на 32G, несколько микро на 64 и одна на 256. Причем большая SD работала как накопитель для торрент-клиента года 3-4.
По поводу RPi — там свои заморочки, и я в общем то не удивлен. Часто слышал что в них карточки убиваются буквально за полгода.
Какими-то странными вы флешками пользуетесь. У меня MicroSD на 32 Гб уже в третий телефон кочует, это больше 6 лет. Работает, кушать не просит :)
Не нагнетайте, я вам горсть таких показать могу, например таких, которые отпахали в регистраторах и продолжают. Самый живучий экземпляр — 8 Гб, 8 лет в фотоаппарате, причём половину этого времени на ней помимо фоток болтался кэш виндового ReadyBoost от нетбука, на который снимки и видео с этой камеры и скидывались. До сих пор пашет, я её даже менять не вижу особого смысла. Если это не надёжность, то что?
Автор, задумайтесь — а как SSD/флэшка должны узнать, что пора начинать обновлять информацию в «старых» секторах?
Часов с батарейкой там нет и после включения они не знают — прошло 5 минут с момента выключения или 10 лет.
Непрерывно обновлять? А как же тогда режим пониженного потребления организован? Измерения тока вам отлично покажут, что флэшка потребляет на порядок меньше, чем при записи. Вы даже просто пальцами можете убедиться, что при активной работе (даже на чтение) флэшка потребляет значительно меньше, чем при неактивности.
Часов с батарейкой там нет и после включения они не знают — прошло 5 минут с момента выключения или 10 лет.
Непрерывно обновлять? А как же тогда режим пониженного потребления организован? Измерения тока вам отлично покажут, что флэшка потребляет на порядок меньше, чем при записи. Вы даже просто пальцами можете убедиться, что при активной работе (даже на чтение) флэшка потребляет значительно меньше, чем при неактивности.
Ну например как тут рекламируется: en.siliconmotion.com/EW_Pages/PCIE_FERRISSD_PB_EN.pdf как полезет восстановление по ECC, которое сделано с запасом, так и надо попробовать обновить.
В общем, полез почитал даташиты.
Никакие флэшки и SSD (кроме последних поколений) ничего с хранимыми данными сами не делают — сам никто ничего не обновляет никогда. При чтении памяти некоторые продвинутые SSD могут перезаписывать страницы FLASH, которые читаются неуверенно (если в контроллере и памяти предусмотрена коррекция ошибок). Так что читать данные на хороших SSD полезно.
Производители современных MLC NAND FLASH чипов гарантируют примерно 3000 циклов стирания и JESD47G, что соответствует не менее 5 или 9 лет (в зависимости назначения устройства) работы при 55'C. Правда, износ памяти круто влияет на время хранения и допустимые температуры — не протирайте FLASH до дыр.
Так что, большей частью — урбан леджендс, господа.
Никакие флэшки и SSD (кроме последних поколений) ничего с хранимыми данными сами не делают — сам никто ничего не обновляет никогда. При чтении памяти некоторые продвинутые SSD могут перезаписывать страницы FLASH, которые читаются неуверенно (если в контроллере и памяти предусмотрена коррекция ошибок). Так что читать данные на хороших SSD полезно.
Производители современных MLC NAND FLASH чипов гарантируют примерно 3000 циклов стирания и JESD47G, что соответствует не менее 5 или 9 лет (в зависимости назначения устройства) работы при 55'C. Правда, износ памяти круто влияет на время хранения и допустимые температуры — не протирайте FLASH до дыр.
Так что, большей частью — урбан леджендс, господа.
Да и последние поколения бывают разные. Если нет конденсаторов, мощных процессоров и мусорных блоков, то никакой фоновой работы производиться не будет. Заряжать бессмысленно, а вот регулярно использовать есть смысл.
И вот вы сказали про MLC. Такие вещи ещё практически не выпускаются. В основном TLC и QLC. А у них время хранения будет ещё меньше.
И вот вы сказали про MLC. Такие вещи ещё практически не выпускаются. В основном TLC и QLC. А у них время хранения будет ещё меньше.
Двухуровневые MLC чипы отлично производится и применяются аж до ёмкостей в 2 Tb (256 GB) на чип. Правда «industrial grade» возможен только до ёмкостей 64 GB на чип.
Если используется TLC/QLC память, то обязательно нужна и есть регенерация данных при чтении — когда вам скучно, то читайте свои данные, господа!
Сейчас посмотрел, сколько-либо брендовые флэшки (начиная с SunDisk) 256 GB и меньше — даже USB 3.1 — используют максимум MLC и никакой автоматической регенерации. Регенерация при чтении зависит от прошивки (некоторые прошивки для того же ширпотребного PS2251 точно делают регенерацию при чтении). Отсюда мораль — не заряжать флэшки надо, а читать.
Если используется TLC/QLC память, то обязательно нужна и есть регенерация данных при чтении — когда вам скучно, то читайте свои данные, господа!
Сейчас посмотрел, сколько-либо брендовые флэшки (начиная с SunDisk) 256 GB и меньше — даже USB 3.1 — используют максимум MLC и никакой автоматической регенерации. Регенерация при чтении зависит от прошивки (некоторые прошивки для того же ширпотребного PS2251 точно делают регенерацию при чтении). Отсюда мораль — не заряжать флэшки надо, а читать.
В общем, полез почитал даташиты.
Никакие флэшки и SSD (кроме последних поколений)
не поделитесь, что за даташиты вы читали? я не находил даташиты на контроллеры ssd
Я уже и забыл. Просто посидел погуглил. На самом деле общие описания на уровне общих алгоритмов без описаний самих чипов вполне находились.
И почитал даташиты на сами чипы памяти — там указываются характеристики надёжности хранения данных и при каких условиях они достигаются. Кроме того, там иногда даются рекомендации о том, нужны ли какие-то специальные программные алгоритмы повышения надёжности хранения данных при работе с этими чипами.
И почитал даташиты на сами чипы памяти — там указываются характеристики надёжности хранения данных и при каких условиях они достигаются. Кроме того, там иногда даются рекомендации о том, нужны ли какие-то специальные программные алгоритмы повышения надёжности хранения данных при работе с этими чипами.
А нельзя ли добавить хоть капельку конкретной информации? Например список флешек, которые указанные действия выполняют.
Никогда не видел чтобы скорость восстанавливалась сама собой — некоторые флешки медленные сразу, некоторые изначально быстрые, но скорость падает после полного заполнения и восстанавливается только после форматирования служебными утилитами.
Никогда не видел чтобы скорость восстанавливалась сама собой — некоторые флешки медленные сразу, некоторые изначально быстрые, но скорость падает после полного заполнения и восстанавливается только после форматирования служебными утилитами.
Как можно убедиться, что флешке надо время для «напудривания носика» и она уже его напудрила?
Почему на флешках не делают второй индикатор, который показывает, что она уже навела у себя порядок и можно ее убрать на месяцок другой?
Еще я думаю, что время, за которое она успеет навести порядок исчисляется в милисекундах, и достаточно просто оставить на пару минут флешку в компе, когда вы ее поюзали. Хотя если объем флешки большой, и она давно не прибиралась, то может и пары секунд не хватить.
Почему на флешках не делают второй индикатор, который показывает, что она уже навела у себя порядок и можно ее убрать на месяцок другой?
Еще я думаю, что время, за которое она успеет навести порядок исчисляется в милисекундах, и достаточно просто оставить на пару минут флешку в компе, когда вы ее поюзали. Хотя если объем флешки большой, и она давно не прибиралась, то может и пары секунд не хватить.
Может быть для простого обывателя будет достаточно следующего алгоритма? Сливаем все с флешки на компьютер, очищаем, заполняем под завязку большим файлом, стираем, возвращаем данные на место.
Можно руками, можно програмку написать.
Я хочу добиться полного заполнения блоков страницами. Набивая накопитель под завязку мы вынуждаем его путем потери скорости записи в данном цикле производить оптимизацию. Зато в конце в каждом блоке окажутся страницы принадлежащие только одному файлу. При его удалении они все должны освободиться.
Это не самый эффективный способ оптимизации, но если он сработает, почему бы и нет?
Я пытаюсь вникнуть в теорию. Разве при забивке накопителя одним единственным файлом не произойдет занятие всех блоков со 100% заполнением? И после удаления этого файла актуальные данные уже должны ложиться дефрагментированно. Мне кажется тут никакой поддержки по оптимизации со стороны накопителя не требуется. Понятно, что к самому концу записи скорость сильно упадет, т.к. останутся только фрагментированные блоки. Зато после этой долгой операции флешка снова вернет свою скорость на какое-то время.
Это какая-то «фантастика» прям, если флешка при наличии питания начинает процесс оптимизации памяти, то где есть гарантии, что пользователь её не выдернет в этот самый процесс, что повлечет за собой утерю данных?
Если бы оно так работало, то скорость записи флешки была бы всегда линейная, но по факту мы видим, кеш устройства (на несколько мегабайт), а затем когда он заканчивается, видим реальную скорость работу устройства (флешки).
Скорее всего — это заложено в алгоритм работы контроллера (когда пишет, сразу на перёд что-то потирает/очищает), сама флешка ничего не делает в простое.
И такой механизм во всех флешках?
Если бы оно так работало, то скорость записи флешки была бы всегда линейная, но по факту мы видим, кеш устройства (на несколько мегабайт), а затем когда он заканчивается, видим реальную скорость работу устройства (флешки).
Скорее всего — это заложено в алгоритм работы контроллера (когда пишет, сразу на перёд что-то потирает/очищает), сама флешка ничего не делает в простое.
И такой механизм во всех флешках?
Технически это не выглядит невозможным: 1)скопировать консолидированные данные в новый блок/страницу или что там, 2)записать в ссылках на данные новые адреса блоков, 3) стереть старые блоки — тут никакое пропадание электричества не повредит данные.
Но… врядли это реализовано потому что это производителям (особенно производителям контроллеров) не нужно, флешки купят и так, а кому нужны быстрые — купят быстрые флешки подороже.
Годится как идея для стартапа (сделать чуть быстрее флешки на медленных дешевых чипах), но не более того.
Но… врядли это реализовано потому что это производителям (особенно производителям контроллеров) не нужно, флешки купят и так, а кому нужны быстрые — купят быстрые флешки подороже.
Годится как идея для стартапа (сделать чуть быстрее флешки на медленных дешевых чипах), но не более того.
На самом деле, тема эта, видимо, для многих стала интересной,
P.S. Написал Кингстону в соцсетях и в личку; может, через некоторое время ответят на комментарий YMA habr.com/ru/post/512886/#comment_21900570 про влияние зарядки на флэшки с точки зрения производителя.
даже видеоролик по ней сняли.
P.S. Написал Кингстону в соцсетях и в личку; может, через некоторое время ответят на комментарий YMA habr.com/ru/post/512886/#comment_21900570 про влияние зарядки на флэшки с точки зрения производителя.
В далёком 2013-ом я всё это «предвидел»… vk.com/wall48392_1995
У меня вот иной сценарий использования флешек — они зачастую не выключаются вовсе. Например, служат как дополнительное хранилище данных с Малинкой в тандеме. И вот с этим почему-то проблемы, в отличии от внешних HDD — со временем читаемость флешки прекращается, вплоть до перезагрузки. Несколько флешек подключенных к камере видеонаблюдения и вовсе умерли, но там хотя-бы имела место быть циклическая перезапись постоянная.
У меня и на шлешке очень многолетней давности всё прекрасно хранится без каких-либо проблем.
chechestor А как обстоят дела с «Safely remove device» или как там его? Я уже столько выдергивая убил флешек (хороших и не очень), что как параноик всегда делаю этот сейф ремув. Можно ли выдергивать флешку с зарядки и если нельзя то как понять когда можно? Вдруг контроллер что-то делает, а я такой хрясь и все поломалось.
Safety remote device — штука интересная. На винде и на линуксе работает по-разному, потому что:
Винда… Винда записывает файлы на флешку сразу, как только это возможно. Старается не хранить данные в КЭШ. Даже индикатор прогресса записи файлов максимально точно описывает процесс записи на диск. Пожтому, с точки зрения данных, если файлы записались, то можно выдергивать накопитель из хоста, и быть уверенным, что файлы записались.
Линукс — штука не такой. Линукс очень сильно зависит от настроек, дистрибутива и все такое. Известные мне дистрибутивы (убунту, дэбиан) старались максимально КЭШировать запись на накопитель. Прогресс записи в линуксе неадекватно показвал скорость записи до 1000 МБайт/с, при том, что реально ни одной операции записи на накопиель не производилось. Если в этот момент вытащить накопитель из хаба, то на другом компе файлов мы, конечно не увидим. Зато, как и следовало ожидать, когда нажимает «Извлечь», то линукс говорит «погодите секундочку» и без всякого прогрессбара начинает запись файлов на накопитель. Понятное дело, что запись файлов бодбшого объема занимает больше секундочки. У меня тут к линуксу претензии, птому что польшователь по незнанию может подумать что просто все зависло, устал ждать, и выдернул накопитель. Скорее всего, птом придется повозиться еще и с битой FAT.
С линуксом все понятно, давайте копнем глубже винду:
Файлы пишутся как видятся — уже хорошо. Но в чем тогда суть Safety remote device? А в том, что кроме видимой активности копирования файлов может быть еще невидимая активность фоновых процессов (например, по флешке шарится антивирус). Или, например, пользователь может банально забыть, что у него открыт файл ворда прямо с флешки. Если у пользователя есть привычка делать Safety remote device, то ОС сообщит при попытке извлечения, что флешка используется, и на том уже спасибо. Safety remote device — это, скорее, гарантия того, что после извлечения уже никакая программа не будет лазить на диск.
Чем же опасна активность флешки во время извлечения? Объясняю. Не все производители добросовестно думают о том, что будет происходить с флешкой при пропадании питания, иногда экономят банально на конденсаторах даже. Если производится операция программирования NAND-памяти, и в этот момент пропадает питание, то нет гарантий, что страница данных запишется корректно. При записи некорретной страницы опять же есть два возможных варианта: что разработчики софта подумали о такой возможности, и что разработчики софта не упели к дедлайну подумать о такой возможности.
Вывод: так как конечный пользователь не в курсе, как работают алгоритмы во флешке — лучше делать Safety remote device, чем не делать. Это не дает никаких гарантий, но снижает вероятность как потери данных, так и окирпичивания флешки вообще.
В остальном же, никогда не следует доверять флешкам, так как вариантов сэкономить время разработки за счет потери надежности хранения данных существует превеликое множество. Лично я чаще видел, как умирают декоративные noname флешки, чем именитые.
Винда… Винда записывает файлы на флешку сразу, как только это возможно. Старается не хранить данные в КЭШ. Даже индикатор прогресса записи файлов максимально точно описывает процесс записи на диск. Пожтому, с точки зрения данных, если файлы записались, то можно выдергивать накопитель из хоста, и быть уверенным, что файлы записались.
Линукс — штука не такой. Линукс очень сильно зависит от настроек, дистрибутива и все такое. Известные мне дистрибутивы (убунту, дэбиан) старались максимально КЭШировать запись на накопитель. Прогресс записи в линуксе неадекватно показвал скорость записи до 1000 МБайт/с, при том, что реально ни одной операции записи на накопиель не производилось. Если в этот момент вытащить накопитель из хаба, то на другом компе файлов мы, конечно не увидим. Зато, как и следовало ожидать, когда нажимает «Извлечь», то линукс говорит «погодите секундочку» и без всякого прогрессбара начинает запись файлов на накопитель. Понятное дело, что запись файлов бодбшого объема занимает больше секундочки. У меня тут к линуксу претензии, птому что польшователь по незнанию может подумать что просто все зависло, устал ждать, и выдернул накопитель. Скорее всего, птом придется повозиться еще и с битой FAT.
С линуксом все понятно, давайте копнем глубже винду:
Файлы пишутся как видятся — уже хорошо. Но в чем тогда суть Safety remote device? А в том, что кроме видимой активности копирования файлов может быть еще невидимая активность фоновых процессов (например, по флешке шарится антивирус). Или, например, пользователь может банально забыть, что у него открыт файл ворда прямо с флешки. Если у пользователя есть привычка делать Safety remote device, то ОС сообщит при попытке извлечения, что флешка используется, и на том уже спасибо. Safety remote device — это, скорее, гарантия того, что после извлечения уже никакая программа не будет лазить на диск.
Чем же опасна активность флешки во время извлечения? Объясняю. Не все производители добросовестно думают о том, что будет происходить с флешкой при пропадании питания, иногда экономят банально на конденсаторах даже. Если производится операция программирования NAND-памяти, и в этот момент пропадает питание, то нет гарантий, что страница данных запишется корректно. При записи некорретной страницы опять же есть два возможных варианта: что разработчики софта подумали о такой возможности, и что разработчики софта не упели к дедлайну подумать о такой возможности.
Вывод: так как конечный пользователь не в курсе, как работают алгоритмы во флешке — лучше делать Safety remote device, чем не делать. Это не дает никаких гарантий, но снижает вероятность как потери данных, так и окирпичивания флешки вообще.
В остальном же, никогда не следует доверять флешкам, так как вариантов сэкономить время разработки за счет потери надежности хранения данных существует превеликое множество. Лично я чаще видел, как умирают декоративные noname флешки, чем именитые.
Первая половина вашего комментария в духе «флешки не могут умирать, потому что они не живые»… То, что вы описали — да, это все так и есть, я о том и говорю. Просто не вдавался во внутреннюю кухню этого процесса.
По поводу GC — то же самое: я не говорю, что выравниванием возрастов занимается GC, для этого есть WL.
По поводу GC — то же самое: я не говорю, что выравниванием возрастов занимается GC, для этого есть WL.
Есть же простой эксперимент, чтобы проверить, живет оно там своей жизнью, или нет:
1) втыкаем флешку в комп с линуксом
2) не монтируя, делаем
3) пару дней «втыкаем-вытыкаем», по-прежнему не монтируя, и повторяем п.2
1) втыкаем флешку в комп с линуксом
2) не монтируя, делаем
dd if=/dev/sdb bs=1024 | md5sum > $(date "+%Y-%m-%d.md5")3) пару дней «втыкаем-вытыкаем», по-прежнему не монтируя, и повторяем п.2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
USB-флешки: заряжать нельзя игнорировать