Недавно, обсуждая нюансы работы USB flash на данном ресурсе, столкнулся с тем, что основная масса технически грамотных людей в силу отсутствия литературы не имеет представления об основных принципах работы NAND контроллеров, в связи с чем появляется масса далеких от реальности заявлений об особенностях оптимизации микропрограмм устройств, либо делаются неверные выводы о причинах выхода из строя самих устройств.
Дабы немного развеять иллюзии, попробуем методами реверс-инжиниринга проанализировать алгоритмы работы NAND контроллера производства SKYMEDI SK6211 на примере готового изделия в виде USB flash 8Gb, выпущенной компанией Kingston.
рис. 1
Для полноценного анализа сначала создадим имитацию использования накопителя посредством записи большого числа файлов с последующим частичным случайным удалением и повторными записями. Следом пропишем половину LBA диапазона нулями, но кроме нулей в каждый «сектор» поместим по смещению 0x0 DWORD с его номером. Вторую половину логического диапазона пропишем паттерном 0x77 (данный паттерн относительно удобен для анализа алгоритмов зашумливания данных).
Выпаиваем обе микросхемы памяти NAND flash. В этом экземпляре они производства Samsung, маркировка K9HBG08U1M в исполнении TSOP-48. Эксплуатационные характеристики: размер страницы — 2112 байт, размер блока – 128 страниц, количество блоков в плоскости – 2048, количество плоскостей в банке – 4, количество физических банков – 2. Суммарная емкость двух микросхем 2112*128*2048*4*2*2=8 858 370 048 байт.
рис. 2
На рис. 2 показан принцип нумерации блоков (блок состоит из 128 страниц). Стоит отметить, что данная микросхема может одновременно выполнять операции программирования/стирания сразу в двух плоскостях (вариации 0,1 и 2,3). Те, кто желает более подробно изучить особенности микросхем и нюансы работы с ними могут поискать техническую документацию (datasheet), которая в данное время уже доступна широкой публике K9HBG08U1M.pdf.
Для чтения микросхем используем NAND reader входящий в состав комплекса Flash Extractor. В те времена, когда контроллер SK6211 был популярен, этот комплекс, предназначенный для восстановления данных, был практически единственным аналитическим инструментом, который был в свободной продаже.
рис. 3
Приступая к анализу алгоритмов распределения данных контроллером SK6211, узнаем о его возможностях параллельной работы с микросхемами из рекламных источников, а также о несколько отличающихся двух видах кодов коррекции ошибок (ЕСС). В данной публикации, в силу обширности темы, опустим описание особенностей работы кодов коррекции ошибок, и всю математическую составляющую, связанную с ними.
Первая задача в анализе данных установить признаки зашумливания записываемых в память данных. Для этого выполним поиск записанного нами паттерна 0x77 и попробуем обнаружить множество страниц, сплошь заполненных оным. Но результаты поиска к успеху не приводят, что позволяет сделать вывод, что данные записаны в измененном виде. При пролистывании дампов обнаруживаем большое количество страниц, заполненных значением 0x88 кроме последних 64 байт, а также большое количество страниц, заполненных сплошь 0xFF кроме 4 байт в начале каждого 512 байтного блока и последних 64 байт (в границах страницы 2112 байт). Исходя из того, какие паттерны мы записывали на USB flash, вынесем предположение, что имеет место инверсия данных. Прежде, чем выполнять инвертирование данных, проведем анализ содержимого NAND страниц для установления расположения служебных данных. В местах заполнения паттерном весьма просто отличить наше инвертированное однородное значение от служебных данных, которые не состоят сплошь из одинаковых последовательностей байт.
Рис 4.
SK6211 в используемых страницах размещает 2048 байт данных (DA) и 64 байта отводит для хранения служебных данных (SA). Хорошо прослеживаются 4 группы данных по 16 байт, что намекает на применимость их к четырем блокам по 512 содержащихся в странице.
Выведем содержимое первой 16- байтной группы из нескольких тысяч страниц.
рис. 5
На рис. 5 видно, что упорядоченными остаются первые 4 байта, и хаотичное содержимое располагается в остальных 12. Исходя из этого, можно предположить, что последние 12 байт в каждой строке содержат код коррекции ошибок. Зная, что блок, которым оперирует NAND микросхема, равен 128 страницам, произведем расчет размера блока 2112*128=270 336 (0x42000) байт. От 0x00108000 шагнем на один блок вперед, то есть к странице по адресу 0x0014a000.
рис. 6
из содержимого рис. 5 и рис. 6 очевидно, что 3-й байт играет роль номера страницы для блока NAND памяти. Это предположение не опровергается при просмотре всех непустых блоков NAND памяти.
рис. 7
В 0 и 1 байтах служебных данных в каждой странице на протяжении двух блоков неизменные значения. Можно предположить, что эта пара байт отведена для номера блока. Выведем все значения для всех блоков и обнаружим, что в младшем полубайте первого байта используются значения от 0x0 до 0x3, а в нулевом байте пробегают значения от 0x00 до 0xFF. Значения старшего полубайта в первом байте имеют более разнообразные значения. Предположим, что для нумерации используется 10 бит, которые формируются из двух младших битов первого байта служебной зоны в качестве старшей части и 8 бит из нулевого байта в качестве младшей части. Проверим достоверность предположений посредством вывода номеров для первых 0x400 блоков. Отсортировав их в порядке возрастания, заметим, что последовательно выстраивается цепочка из номеров от 0x000 до 0x3C3, что подтверждает корректность предположения. Выполнив аналогичные проверки для остальных групп по 0x400 блоков окончательно исключим вероятность ошибочной интерпретации.
Выполним инвертирование данных, за исключением служебных, и проанализируем механизм распараллеливания данных. Проверим предположение о симметричности записи в разные банки посредством анализа логических номеров в блоках в каждом дампе. В случае SK6211 предположение о симметричной записи подтверждено. Найдем блок с логическим номером 0x000, в котором каждый 512 блок данных содержит порядковый номер и нули в качестве содержимого. Опираясь на фактическое расположение записанных нами данных, построим таблицу положения данных.
Рис. 8
Согласно размещения данных можем заметить, что контроллер для данного набора микросхем реализует максимально эффективное распараллеливание для получения высокой производительности. С учетом механизма распараллеливания данных рассчитаем размер блока, которым оперирует система трансляции в микрокоде накопителя 0x42000*8=0x210000 байт. Если отбросить служебные данные, то размер блока 0x40000*8=0x200000 (2 097 152) байт.
Для дальнейшего анализа нам необходимо устранить разброс данных и собрать их в цельные блоки по 2 МБ.
рис. 9
Первый шаг – устранение распараллеливания между плоскостями посредством постраничного объединения четных блоков с нечетными.
Второй шаг – объединение с удвоенным размером страницы 0 и 1 банков каждой из микросхем NAND памяти.
Третий шаг – объединение с учетверенным размером страницы обеих микросхем NAND памяти.
При анализе содержимого блоков по 2МБ в результирующем дампе наблюдается монотонно возрастающая последовательность пронумерованных нами «секторов», что подтверждает корректность анализа алгоритма распараллеливания данных.
Далее на сборном дампе выясним порядок расположения блоков и организацию в логические банки.
Рис. 10
Произведем поиск нескольких десятков блоков и сбор по порядковому номеру. По результатам сбора удостоверяемся, что наша нумерация секторов в блоках стыкуется. И сделанное ранее предположение о том, что 10 бит из первых двух служебных байт являются номером блока, верно.
Полный размер микросхем 8 858 370 048 (0x210000000) байт размер блока в трансляторе 2 162 688 (0x210000). Всего блоков 0x210000000/0x210000=0x1000 (4096). Исходя из разрядности используемых чисел и фактической нумерации, номера блоков не могут превышать 0x400 (1024) из этого можно сделать вывод о существовании 4 логических банков в трансляции. Условно разделим результирующий дамп на 4 равные части (по 0x400 блоков), оценим в каждой части номера блоков и на основании этого предположим количество блоков, включенных в трансляцию в каждом логическом банке.
рис. 11
Обратим внимание, что размер каждого логического банка заметно меньше 0x400. Эта необходимость диктуется тем, что «лишние» блоки в некотором количестве нужны для служебных структур и, самое главное, для эффективной работы механизма выравнивания износа. Механизм реализуется по принципу, что каждый блок, в котором изменяется содержимое, будет исключен из трансляции и попадет в резервные, а его место займет блок, который до записи в него измененных данных не был включен в трансляцию и числился резервным. С учетом счетчиков записи в каждый блок механизм работает достаточно эффективно. Ахиллесовой пятой данного алгоритма будет обилие неизменяемых данных, тогда при записях в ротации будет участвовать относительно небольшое число блоков.
Данный принцип весьма наглядно подтверждается расположением блоков в дампе. Согласно рис. 10 можно заметить, насколько нелинеен разброс блоков, из которых реализуется логическое пространство. Припаяв микросхемы NAND памяти обратно и подключив USB flash к компьютеру, выполним некоторое число записей в первые 4096 «секторов», снова выпаяем и прочитаем микросхемы NAND памяти, проведем сбор и оценим порядок блоков в результирующем дампе.
рис. 12
Как можем заметить при неизменном порядке остальных блоков, блок с логическим номером 0x000 «перекочевал» в другое место. По старому адресу все страницы блока, как в области пользовательских данных, так и в области служебных сплошь заполнены 0xFF, что свидетельствует об очистке данного блока и исключении из трансляции.
Сравнивая оба результирующих дампа, кроме измененных данных в нулевом блоке будут изменения и в служебных данных, проанализировав которые мы можем установить, каким образом сформирована структура транслятора.
Подобный метод анализа позволяет получить достаточно данных об алгоритме работы USB NAND контроллера, чтобы применять их для восстановления информации из поврежденных накопителей, основанных на исследуемом контроллере, а также позволяет увидеть в действии механизмы распараллеливания данных и выравнивания износа. Также, основываясь на устройстве транслятора и анализе USB flash (дополнительные мероприятия по анализу проводим на накопителе, отформатированном в FAT32 и заполненном несколькими тысячами файлов), можно заметить, что для блоков со структурами файловой системы нет какого-либо привилегированного выделения блоков.
Следующая публикация: Восстановление данных с внешнего жесткого диска Seagate FreeAgent Go
Предыдущая публикация: Восстановление данных из поврежденного массива RAID 5 в NAS под управлением Linux
Дабы немного развеять иллюзии, попробуем методами реверс-инжиниринга проанализировать алгоритмы работы NAND контроллера производства SKYMEDI SK6211 на примере готового изделия в виде USB flash 8Gb, выпущенной компанией Kingston.
рис. 1
Для полноценного анализа сначала создадим имитацию использования накопителя посредством записи большого числа файлов с последующим частичным случайным удалением и повторными записями. Следом пропишем половину LBA диапазона нулями, но кроме нулей в каждый «сектор» поместим по смещению 0x0 DWORD с его номером. Вторую половину логического диапазона пропишем паттерном 0x77 (данный паттерн относительно удобен для анализа алгоритмов зашумливания данных).
Выпаиваем обе микросхемы памяти NAND flash. В этом экземпляре они производства Samsung, маркировка K9HBG08U1M в исполнении TSOP-48. Эксплуатационные характеристики: размер страницы — 2112 байт, размер блока – 128 страниц, количество блоков в плоскости – 2048, количество плоскостей в банке – 4, количество физических банков – 2. Суммарная емкость двух микросхем 2112*128*2048*4*2*2=8 858 370 048 байт.
рис. 2
На рис. 2 показан принцип нумерации блоков (блок состоит из 128 страниц). Стоит отметить, что данная микросхема может одновременно выполнять операции программирования/стирания сразу в двух плоскостях (вариации 0,1 и 2,3). Те, кто желает более подробно изучить особенности микросхем и нюансы работы с ними могут поискать техническую документацию (datasheet), которая в данное время уже доступна широкой публике K9HBG08U1M.pdf.
Для чтения микросхем используем NAND reader входящий в состав комплекса Flash Extractor. В те времена, когда контроллер SK6211 был популярен, этот комплекс, предназначенный для восстановления данных, был практически единственным аналитическим инструментом, который был в свободной продаже.
рис. 3
Приступая к анализу алгоритмов распределения данных контроллером SK6211, узнаем о его возможностях параллельной работы с микросхемами из рекламных источников, а также о несколько отличающихся двух видах кодов коррекции ошибок (ЕСС). В данной публикации, в силу обширности темы, опустим описание особенностей работы кодов коррекции ошибок, и всю математическую составляющую, связанную с ними.
Первая задача в анализе данных установить признаки зашумливания записываемых в память данных. Для этого выполним поиск записанного нами паттерна 0x77 и попробуем обнаружить множество страниц, сплошь заполненных оным. Но результаты поиска к успеху не приводят, что позволяет сделать вывод, что данные записаны в измененном виде. При пролистывании дампов обнаруживаем большое количество страниц, заполненных значением 0x88 кроме последних 64 байт, а также большое количество страниц, заполненных сплошь 0xFF кроме 4 байт в начале каждого 512 байтного блока и последних 64 байт (в границах страницы 2112 байт). Исходя из того, какие паттерны мы записывали на USB flash, вынесем предположение, что имеет место инверсия данных. Прежде, чем выполнять инвертирование данных, проведем анализ содержимого NAND страниц для установления расположения служебных данных. В местах заполнения паттерном весьма просто отличить наше инвертированное однородное значение от служебных данных, которые не состоят сплошь из одинаковых последовательностей байт.
Рис 4.
SK6211 в используемых страницах размещает 2048 байт данных (DA) и 64 байта отводит для хранения служебных данных (SA). Хорошо прослеживаются 4 группы данных по 16 байт, что намекает на применимость их к четырем блокам по 512 содержащихся в странице.
Выведем содержимое первой 16- байтной группы из нескольких тысяч страниц.
рис. 5
На рис. 5 видно, что упорядоченными остаются первые 4 байта, и хаотичное содержимое располагается в остальных 12. Исходя из этого, можно предположить, что последние 12 байт в каждой строке содержат код коррекции ошибок. Зная, что блок, которым оперирует NAND микросхема, равен 128 страницам, произведем расчет размера блока 2112*128=270 336 (0x42000) байт. От 0x00108000 шагнем на один блок вперед, то есть к странице по адресу 0x0014a000.
рис. 6
из содержимого рис. 5 и рис. 6 очевидно, что 3-й байт играет роль номера страницы для блока NAND памяти. Это предположение не опровергается при просмотре всех непустых блоков NAND памяти.
рис. 7
В 0 и 1 байтах служебных данных в каждой странице на протяжении двух блоков неизменные значения. Можно предположить, что эта пара байт отведена для номера блока. Выведем все значения для всех блоков и обнаружим, что в младшем полубайте первого байта используются значения от 0x0 до 0x3, а в нулевом байте пробегают значения от 0x00 до 0xFF. Значения старшего полубайта в первом байте имеют более разнообразные значения. Предположим, что для нумерации используется 10 бит, которые формируются из двух младших битов первого байта служебной зоны в качестве старшей части и 8 бит из нулевого байта в качестве младшей части. Проверим достоверность предположений посредством вывода номеров для первых 0x400 блоков. Отсортировав их в порядке возрастания, заметим, что последовательно выстраивается цепочка из номеров от 0x000 до 0x3C3, что подтверждает корректность предположения. Выполнив аналогичные проверки для остальных групп по 0x400 блоков окончательно исключим вероятность ошибочной интерпретации.
Выполним инвертирование данных, за исключением служебных, и проанализируем механизм распараллеливания данных. Проверим предположение о симметричности записи в разные банки посредством анализа логических номеров в блоках в каждом дампе. В случае SK6211 предположение о симметричной записи подтверждено. Найдем блок с логическим номером 0x000, в котором каждый 512 блок данных содержит порядковый номер и нули в качестве содержимого. Опираясь на фактическое расположение записанных нами данных, построим таблицу положения данных.
Рис. 8
Согласно размещения данных можем заметить, что контроллер для данного набора микросхем реализует максимально эффективное распараллеливание для получения высокой производительности. С учетом механизма распараллеливания данных рассчитаем размер блока, которым оперирует система трансляции в микрокоде накопителя 0x42000*8=0x210000 байт. Если отбросить служебные данные, то размер блока 0x40000*8=0x200000 (2 097 152) байт.
Для дальнейшего анализа нам необходимо устранить разброс данных и собрать их в цельные блоки по 2 МБ.
рис. 9
Первый шаг – устранение распараллеливания между плоскостями посредством постраничного объединения четных блоков с нечетными.
Второй шаг – объединение с удвоенным размером страницы 0 и 1 банков каждой из микросхем NAND памяти.
Третий шаг – объединение с учетверенным размером страницы обеих микросхем NAND памяти.
При анализе содержимого блоков по 2МБ в результирующем дампе наблюдается монотонно возрастающая последовательность пронумерованных нами «секторов», что подтверждает корректность анализа алгоритма распараллеливания данных.
Далее на сборном дампе выясним порядок расположения блоков и организацию в логические банки.
Рис. 10
Произведем поиск нескольких десятков блоков и сбор по порядковому номеру. По результатам сбора удостоверяемся, что наша нумерация секторов в блоках стыкуется. И сделанное ранее предположение о том, что 10 бит из первых двух служебных байт являются номером блока, верно.
Полный размер микросхем 8 858 370 048 (0x210000000) байт размер блока в трансляторе 2 162 688 (0x210000). Всего блоков 0x210000000/0x210000=0x1000 (4096). Исходя из разрядности используемых чисел и фактической нумерации, номера блоков не могут превышать 0x400 (1024) из этого можно сделать вывод о существовании 4 логических банков в трансляции. Условно разделим результирующий дамп на 4 равные части (по 0x400 блоков), оценим в каждой части номера блоков и на основании этого предположим количество блоков, включенных в трансляцию в каждом логическом банке.
рис. 11
Обратим внимание, что размер каждого логического банка заметно меньше 0x400. Эта необходимость диктуется тем, что «лишние» блоки в некотором количестве нужны для служебных структур и, самое главное, для эффективной работы механизма выравнивания износа. Механизм реализуется по принципу, что каждый блок, в котором изменяется содержимое, будет исключен из трансляции и попадет в резервные, а его место займет блок, который до записи в него измененных данных не был включен в трансляцию и числился резервным. С учетом счетчиков записи в каждый блок механизм работает достаточно эффективно. Ахиллесовой пятой данного алгоритма будет обилие неизменяемых данных, тогда при записях в ротации будет участвовать относительно небольшое число блоков.
Данный принцип весьма наглядно подтверждается расположением блоков в дампе. Согласно рис. 10 можно заметить, насколько нелинеен разброс блоков, из которых реализуется логическое пространство. Припаяв микросхемы NAND памяти обратно и подключив USB flash к компьютеру, выполним некоторое число записей в первые 4096 «секторов», снова выпаяем и прочитаем микросхемы NAND памяти, проведем сбор и оценим порядок блоков в результирующем дампе.
рис. 12
Как можем заметить при неизменном порядке остальных блоков, блок с логическим номером 0x000 «перекочевал» в другое место. По старому адресу все страницы блока, как в области пользовательских данных, так и в области служебных сплошь заполнены 0xFF, что свидетельствует об очистке данного блока и исключении из трансляции.
Сравнивая оба результирующих дампа, кроме измененных данных в нулевом блоке будут изменения и в служебных данных, проанализировав которые мы можем установить, каким образом сформирована структура транслятора.
Подобный метод анализа позволяет получить достаточно данных об алгоритме работы USB NAND контроллера, чтобы применять их для восстановления информации из поврежденных накопителей, основанных на исследуемом контроллере, а также позволяет увидеть в действии механизмы распараллеливания данных и выравнивания износа. Также, основываясь на устройстве транслятора и анализе USB flash (дополнительные мероприятия по анализу проводим на накопителе, отформатированном в FAT32 и заполненном несколькими тысячами файлов), можно заметить, что для блоков со структурами файловой системы нет какого-либо привилегированного выделения блоков.
Следующая публикация: Восстановление данных с внешнего жесткого диска Seagate FreeAgent Go
Предыдущая публикация: Восстановление данных из поврежденного массива RAID 5 в NAS под управлением Linux
Поделиться с друзьями
DrPass
Вы всё это проделали ради того, что с вами не согласился кто-то в ветке про баг в NTFS? O_o
hddmasters
Основная причина выполнения подобных действий — это разработка методик восстановления данных с различных устройств. А выкладка здесь — это малая толика проведенных исследований.
Публикация об анализе алгоритмов какого-либо из NAND контроллеров была в планах. А небольшой спор в комментариях даже сложно назвать подстегивающим фактором.
Если данная тематика покажется интересной читателям, то можно будет рассмотреть и другие контроллеры используемые в SSD, USB flash и картах памяти.
SADKO
Конечно интересно, лет на десять выпал из темы, интересно что новенького на плюке…
И нет ли каких тупо-контроллеров, без контроля износа и прочих радостей, дабы получить максимальную производительность на запись\чтение, никак не зависящую от заполнения носителя?
hddmasters
Нынче в моде емкие устройства с TLC памятью, а ее ресурс, если говорить очень мягко, оставляет желать лучшего. Посему алгоритмы NAND контроллеров стали только сложнее, а коды коррекции ошибок намного длиннее.
SADKO
А нет ли каких серийных, специальных устройств, для архивирования, когда устройство записывается единожды, ради последующего быстрого, произвольного доступа?
hddmasters
По моему мнению рынок не сильно заинтересован в устройствах, на которые можно что-либо записать лишь единожды. Только если стоимость этих носителей информации будет очень и очень низкой.
Кроме CD-R, DVD-R, BD-R никаких и примеров особо популярных не припоминается.
rPman
быстрый случайный доступ и низкая цена и возможность на уровне операционной системы самому решать каким может быть алгоритм контроля за целостностью носителя?
дайте много!
МНОГО, петабайтами пожалуйста
kmeaw
Бывают host-managed SMR диски.
rPman
SMR — По случайному доступу это классический HDD
И да, цена!
h31
Не проблема. Во всяких embedded-устройствах типа роутеров используется память, где за износом следит сама ФС. Интерфейс подключения — SPI или что-то своё.
Только объемы там скромные, да и скорости небольшие.
hddmasters
сами же и написали ключевой момент, который не даст возможности конкурировать подобной памяти с более емким и дешевым нандом.
Если посмотреть историю развития NOR и NAND flash памяти, то станет понятно, что и для каких ниш можно использовать. Очевидно, что пока альтернативы NAND памяти, увы, нет, которая была бы сопоставима по характеристикам в том числе и цене.
h31
Я как раз про NAND и говорю. Просто человек спрашивал про «тупой» контроллер, я ему и привел пример.
SADKO
Потому и тормозные что через SPI, можно те-же NAND напрямую подцеплять, а функции контроллера возьмёт на себя драйвер… И не то что там надо за износом следить, просто даже у новых чипов есть дефектные места и c NAND это не всегда так-же просто отрабатывается как с NOR, а с некоторыми MLC бывает нужен рефрэшь ибо чтение способно повредить уже записанные данные некоторым образом…
… но не смотря на все эти страхи и ужасы, в конкретных кейсах можно было получить профит если начать городить свой велосипед… Мне например бывало нужно записать очень быстрый поток данных, который в последствии считывался лишь пару раз, а потом стирания и опять запись. (сменные накопители для цифрового кино, в разных его проявлениях)
Это конечно самый простой кейс, но те-же прошивки на многих платформах делают по тупому, и ничего страшного не происходит, и в принципе с учётом того, что в IT хозяйстве бэкапы всё равно куда-то делаются, даже лютые глюки MLC можно и потерпеть, превращая её в эдакий кэш, ради скорости и произвольного доступа.
h31
Мне кажется, на такие велосипеды уйдет столько времени, сил и денег, что в итоге будет дешевле сделать RAID из SSD-шек.
А вы пробовали PCI-E SSD? Или вам нужно ещё быстрее?
SADKO
А вы представьте на дворе 2006 год, мне хочется цифрового кино, а один состоятельный заказчик хочет устройство для записи гигабитного потока данных, при том выдерживающего вибрации и перегрузки полностью исключающие применение какой-либо механики…
… задачи, очень близкие, но максимум что можно было купить за деньги восемь гиг SLC, или в два раза больше MLC но без каких-либо гарантий, это я про чипы говорю, готовые накопители стоили как «тот самолёт», и были слишком плохо предсказуемы, ну а любовь к кинематографу заставила меня освоиться с FPGA ибо взаимдействие с иными сенсорами была та ещё жесть, например одна большая DALSA по сути была четырьмя одинаковыми и независимыми сенсорами на одном кристалле, всё это надо было синхронно считать, склеить, подкорректировать, сжать и записать, так-что взаимодействие с MLC казалось тривиальным, а оно таковым и было в моей задаче…
VT100
Неподходящий пример и неверный вывод.
Насколько я знаю, в SPI-Flash, как правило, хранится небольшой загрузчик, сжатый образ ФС (ПО прибора) и параметры устройства (эмуляция EEPROM). При старте образ разворачивается в DRAM и обмен по SPI сводится к минимуму. А обновление ПО производится достаточно редко, что-бы наплевать на пропускную способность SPI (и даже QSPI).
h31
Специально решил посмотреть, как оно организовано в OpenWRT.
Тут ничего не сказано, копируется или нет. Ядро — да, копируется, а про ФС ничего не сказано.
Тут есть примеры устройств, у некоторых объем флеша равен объему ОЗУ. Я очень сомневаюсь, что в них копируется rootfs в память.
[ 0.605896] 5 tp-link partitions found on MTD device spi0.0
[ 0.611597] Creating 5 MTD partitions on "spi0.0":
[ 0.616463] 0x000000000000-0x000000020000 : "u-boot"
[ 0.622909] 0x000000020000-0x000000152dc0 : "kernel"
[ 0.629481] 0x000000152dc0-0x0000007f0000 : "rootfs"
[ 0.636128] mtd: device 2 (rootfs) set to be root filesystem
Jef239
И только на вопросы, нужные для восстановления данных ваш анализ и отвечает. Все остальное вы даже и не пытались анализировать.
Вот неполный список вопросов, на которые у вас нету ответов:
И так далее… и так далее…
Чтобы нормально разобраться в том, дает ли алгоритм контроллера преимущества FAT, реверс-инжиниринга мало. Нужно дизассемблировать прошивку контроллера, а потом сделать мат-моделирование полученного алгоритма.
Того, что у вас сделано — хватает лишь для восстановления данных.
hddmasters
Вы снова фантазируете. Не все опубликовано.
в рамках логического банка могут существовать блоки, которые никогда не будут включены в трансляцию. В структурах транслятора. Список формируется на этапе заливки микропрограммы и первичного тестирования памяти. Может быть дополнен в зависимости от возможностей микропрограммы. С контроллером подобным SK6211 из-за одной битой страницы (которая не может хранить данные, которые можно скорректировать посредством ЕСС) будет исключаться целиком блок.
блоки строго по 2Мб. В трансляторе указывается порядок их использования при построение логического пространства, с которым работает ОС.
легко посчитать. Емкость каждого логического банка по 0x400 блоков. Количество включенных в трансляцию на рис. 11. Остальное это резервные, служебные и дефектные. Естественно при каждой перезаписи какой-то из блоков «перейдет» в резервные, а какой то из резервных станет, либо блоком с данными, либо блоком со структурой транслятора.
согласно счетчиков количества записей в структуре транслятора.
в микропрограмме SK6211, нет даже намека на анализ данных передаваемых в пакетах. Как бы Вам не хотелось бы найти подтверждение Вашей фантазии, что чуть ли не все usb flash оптимизированы под FAT, но увы анализом это не подкрепляется.
Дизассемблируйте, проверьте мои утверждения. Этот этап для меня имеет коммерческую ценность и выкладываться мной не будет.
чуточку больше, чем для восстановления данных.
Jef239
Не нужны мне ваши тайны. Но то, что опубликовано — не имеет отношения к нашему спору.
Так все-таки, список хранится в ПЗУ контролера или частично во флэш? Список bad-блоков пополняется во время работы? У меня такое впечатление, что вы этот уровень не дизассемблировали и просто гадаете.
Вы даже вопрос не поняли. ОС делает две логические записи в 516ый и 517 сектор флэшки подряд, с интервалом 2 микросекунды. Будет ли флэшка дважды писать физическйи блок? Или сумеет объединить дев логические передачи данных по USB в одну физическую запись?
Вот как раз посекторная запись — может быть настоящей причиной сильного износа на ext2. Насколько я помню, винчестеры умеют в таких ситуациях объединять логические записи в одну физическую. А флэшка?
Не фантазируйте, номер логического блока в любом случае анализируется транслятором. Ну просто для понимания в какой физический блок и с каким смещением писать данные. Это не анализ данных, это анализ адреса данных и он все равно выполняется.
Ну такое уж у вас качество анализа. Воспроизведите прошивку контроллера и сделайте моделирование. И вы увидите что параметры оптимизированы не под сферическую лошадь в вакууме, а под самый частый случай использования — то есть под FAT. Ибо так сделает каждый разумный инженер. А неразумные… увы, они разоряются.
Пока что вы меня убедили лишь в том, что «в подавляющем случае они не занимаются анализом данных». Но собственно этого я и не утверждал. Для оптимизации под FAT достаточно более простых вещей, чем анализ данных.
Например (и на это вы не ответили) на вышедшей с завода флэш можно держать почти все блоки в списке резервных. И это будет отлично работать именно для FAT. Например, при заполненном наполовину банке это даст 2 тысячи блоков для ротации вместо 60-70 блоков при заполненном банке.
hddmasters
имеет, отчасти многие выводы можно построить на основании данного анализа.
В трансляторе. Транслятор в блоках, которые выделены под служебные нужды.
однозначно можно сказать, что далеко не все USB flash будут обслуживать очередь команд. Чаще будет последовательное исполнение.
Микропрограмма USB NAND контроллера при запросе чтения/записи расчитает номер логического блока посредством деления с остатком номера LBA на размер блока. Остаток внутриблочное смещение. И для этой позиции «посмотрит» в трансляторе номер физического блока.
Трансляторы чаще выглядит по принципу:
0x0: WORD — номер физического блока в котором содержится 0 логический.
0x2: WORD — номер физического блока в котором содержится 1 логический
Естественно разрядность величин и наличие иной, кроме номера блока может иметь место. Тут уже свобода творчества разработчика, который решил или сделать много разных таблиц, или все в одной.
я уже Вам писал, что делать оптимизации строго под FAT неэффективное решение. Масса пользователей работает с файлами находящимися на USB flash и при редактировании из размер зачастую меняется весьма незначительно. И куда больше записей произойдет в блок с директорией и блок с файлом, при этом таблицы FAT останутся неизменными. Отсюда и направление в оптимизации паразитных нагрузок, посредством «блок апдейтов», о которых я Вам написал в другой теме.
по факту имеем, что в подавляющем большинстве USB flash блоки с FAT таблицами располагаются с иными данными на равным правах.
Да при изначально пустой USB flash для ротации куда большее раздолье. Но это не оптимизация под FAT — это реализация выравнивания износа, которая лучше работает при использовании FAT. До появления TRIM аналогичный механизм выравнивания износа был в SSD. C TRIM NAND контроллер более эффективно реализует механизм выравнивания износа.
Jef239
Очередь команд с выбором порядка исполнения — это сложно. А вот подождать до 0.01-10мс, не придет ли команда записи в тот же физический блок — это сильно проще.
Я вам уж писал в соседнем топике, что последние 30 лет очень редко файлы перезаписываются по месту. Создает новый файл, потом идет переименование.
Да хоть
синхрофазотроннымгоршком назовите, только вядернуюпечку не ставьте. Одной этой оптимизации хватает для объяснения результатов моих экспериментов. Собственно на этом спор можно прекратить. Причина, почему FAT работает лучше — найдена.hddmasters
к сожалению не так редко, как хотелось бы.
Результат Ваших экспериментов это некоторое число зависших USB flash. Без всякого анализа Вы сделали вывод, который был удобен для Вашего понимания.
Jef239
Вы можете и дальше упорствовать, что 4 — это сильно больше, чем 4. И что оптимизация, которую вам пришлось признать — это вовсе не оптимизация. И в общем можете думать все, что вы хотите.
Но только без меня, пожалуйста. Хорошо?
hddmasters
будто бы я заставляю Вас спорить и плодить утверждения без подкрепления фактами..
Я лишь попросил Вас аргументированно ответить на Ваши первоначальные утверждения.
Вы конечно можете простой уйти из обеих тем, а можете признать, что некоторые Ваши слова не соответствуют действительности.
Jef239
Ну что ж. Вы имеете право привести ссылку на документ, показывающий частоту записи FSInfo. Либо исследовать этот вопрос.
Общие соображения такие. Смысл FSinfo — это дать подсказку, какой кластер таблицы FAT читать при записи. Возьмем данные из вашего поста. «раздел 8GiB кластер 4KiB», «8MiB размер одной копии таблицы FAT32», то есть 2048 кластеров в таблице FAT и 1024 записи в одном кластере таблицы FAT32.
В рассматриваемой мной модели (разархивация или копирование множества мелких файлов на флэшку) просто нет смысла записывать FSInfo чаще, чем оно станет указывать на другой кластер FAT. То есть 1 запись FSuinfo на мелких 1024 файла (4096 дисковых операций). Таким образом, имеем 4097 операций записи вместо 4096, то есть записью FSinfo можно пренеберечь. Вдобавок даже эта запись может кэшироваться.
Ну и ещё одна запись FSInfo — при завершении работы. Собственно это отгадка того эффекта, о котором писал Am0ralist.
Все это не так для фотоаппарата, работающего по модели включили, записали фото и выключили. Вот у фотика в таком режиме — действительно будет 5 записей на диск.
============================
Какие факты вам нужны? Можно конкретно? Про то, что разные RK05F были несовместимы по юстировке? Или про что? про то, что у меня читается разделы ext3 и ext4?
Вы напишите, какие факты вам подтвердить — я подтвержу.
При растаривании корневой файловой системы линукса у нас гибнет больше половины USB-флэшек. А вот MicroSD 1.1 — не гибнут. Это экспериментальный факт. Можете его проверить. Структура диска — вначале FAT, в конце — гигабайт на корневую систему с множеством мелких файлов.
Единственный тонкий момент — и там и там я использовал ext3, а из наших с вами обсуждений вышло, что ext3 — намного хуже, чем ext2 или FAT.
Со своей стороны, я ещё раз прошу объяснить, почему вы считаете, что 4 записи на файл на ext2 — это большая нагрузка, чем те же 4 записи на файл на FAT. Возможно, что дело в меньшем размере кластера на ext2, но явно не в том. что 4 больше, чем 4. :-)
Пока что мы с вами нашли оптимизацию (особенность алгоритма), дающую преимущества FAT. Речь о том, что никогда не писавшиеся блоки считаются резервными и участвуют в замене. А таких блоков — сильно больше на FAT, чем на ext2.
В целом оптимизация на FAT происходит из-за того, что все алгоритмы моделируются для типичных условий использования. А это в 99.5% — означает FAT.
Jef239
Понимаете в чем дело. Вы исходите из того, что производитель моделирует (отлаживает) свои алгоритмы на абсолютно случайно смеси записей и чтений, не имеющих отношение ни к одной файловой системе.
А я исхожу из того, что все моделирование для USB-флэш идет для типичного случая, то есть для FAT (99.5% использования).
А если мы моделируем и настраиваем алгоритм для каких-то условий, то волей не волей он оказывается оптимизирован именно для этих условий.
Это принципиальное отличие между HDD и USB-флэш. Многие тесты HDD идут без учета файловой системы. А вот тесты USB-флэш — основаны на файловой системе.
Если хотите опровергнуть — то приведите пример программы для тестирования USB-флэш, которая не использовала бы файловую систему.
VBKesha
Спасибо за статью!
Интересно было узнать как оно там.
hddmasters
Пожалуйста. Если хотите, что-то еще узнать, то предлагайте темы для будущих публикаций. По мере возможностей будет рассмотрена возможность написания.
VBKesha
Тут ситуация, пока не прочтёшь как оно там внутри никогда бы не подумал что оно так интересно.
hddmasters
Чем дальше в лес…
VJean
..., тем злее волки.
mkc
Расскажите про подключение и работу с мк для микро-сд флешек)
hddmasters
Снятие лака со стороны контактов. Работа с логическим анализатором (в некоторых случаях потребуются рентгеновские снимки). После распайка на монтажный адаптер, а в остальном все тоже самое. Посмотрим при наличии возможности и этот материал попробую показать. Но пока на очереди другие заметки.
VJean
Да простят меня за линк на конкурентов.
Восстановление данных с флешек монолит
roma1141
Очень грамотное описание, на мой взгляд! Спасибо!
Spewow
В microsd контролёры такие же эффективные по части коррекции ошибок и распределению износа памяти или в силу уменьшения размеров что-то упрощается?
hddmasters
Аналогичные алгоритмы выравнивания износа. Аналогичное распараллеливание исходя из количества банков. Контроллеры по большому счету аналогичные.
Но как и у любых современных массовых USB flash и различных карт памяти, качество NAND flash оставляет желать лучшего. Ресурс совсем не радует.