Комментарии 41
Вы всё это проделали ради того, что с вами не согласился кто-то в ветке про баг в NTFS? O_o
Основная причина выполнения подобных действий — это разработка методик восстановления данных с различных устройств. А выкладка здесь — это малая толика проведенных исследований.
Публикация об анализе алгоритмов какого-либо из NAND контроллеров была в планах. А небольшой спор в комментариях даже сложно назвать подстегивающим фактором.
Если данная тематика покажется интересной читателям, то можно будет рассмотреть и другие контроллеры используемые в SSD, USB flash и картах памяти.
Публикация об анализе алгоритмов какого-либо из NAND контроллеров была в планах. А небольшой спор в комментариях даже сложно назвать подстегивающим фактором.
Если данная тематика покажется интересной читателям, то можно будет рассмотреть и другие контроллеры используемые в SSD, USB flash и картах памяти.
Конечно интересно, лет на десять выпал из темы, интересно что новенького на плюке…
И нет ли каких тупо-контроллеров, без контроля износа и прочих радостей, дабы получить максимальную производительность на запись\чтение, никак не зависящую от заполнения носителя?
И нет ли каких тупо-контроллеров, без контроля износа и прочих радостей, дабы получить максимальную производительность на запись\чтение, никак не зависящую от заполнения носителя?
Нынче в моде емкие устройства с TLC памятью, а ее ресурс, если говорить очень мягко, оставляет желать лучшего. Посему алгоритмы NAND контроллеров стали только сложнее, а коды коррекции ошибок намного длиннее.
А нет ли каких серийных, специальных устройств, для архивирования, когда устройство записывается единожды, ради последующего быстрого, произвольного доступа?
По моему мнению рынок не сильно заинтересован в устройствах, на которые можно что-либо записать лишь единожды. Только если стоимость этих носителей информации будет очень и очень низкой.
Кроме CD-R, DVD-R, BD-R никаких и примеров особо популярных не припоминается.
Кроме CD-R, DVD-R, BD-R никаких и примеров особо популярных не припоминается.
быстрый случайный доступ и низкая цена и возможность на уровне операционной системы самому решать каким может быть алгоритм контроля за целостностью носителя?
дайте много!
МНОГО, петабайтами пожалуйста
дайте много!
МНОГО, петабайтами пожалуйста
Бывают host-managed SMR диски.
Не проблема. Во всяких embedded-устройствах типа роутеров используется память, где за износом следит сама ФС. Интерфейс подключения — SPI или что-то своё.
Только объемы там скромные, да и скорости небольшие.
Не проблема. Во всяких embedded-устройствах типа роутеров используется память, где за износом следит сама ФС. Интерфейс подключения — SPI или что-то своё.
Только объемы там скромные, да и скорости небольшие.
сами же и написали ключевой момент, который не даст возможности конкурировать подобной памяти с более емким и дешевым нандом.
Если посмотреть историю развития NOR и NAND flash памяти, то станет понятно, что и для каких ниш можно использовать. Очевидно, что пока альтернативы NAND памяти, увы, нет, которая была бы сопоставима по характеристикам в том числе и цене.
Потому и тормозные что через SPI, можно те-же NAND напрямую подцеплять, а функции контроллера возьмёт на себя драйвер… И не то что там надо за износом следить, просто даже у новых чипов есть дефектные места и c NAND это не всегда так-же просто отрабатывается как с NOR, а с некоторыми MLC бывает нужен рефрэшь ибо чтение способно повредить уже записанные данные некоторым образом…
… но не смотря на все эти страхи и ужасы, в конкретных кейсах можно было получить профит если начать городить свой велосипед… Мне например бывало нужно записать очень быстрый поток данных, который в последствии считывался лишь пару раз, а потом стирания и опять запись. (сменные накопители для цифрового кино, в разных его проявлениях)
Это конечно самый простой кейс, но те-же прошивки на многих платформах делают по тупому, и ничего страшного не происходит, и в принципе с учётом того, что в IT хозяйстве бэкапы всё равно куда-то делаются, даже лютые глюки MLC можно и потерпеть, превращая её в эдакий кэш, ради скорости и произвольного доступа.
… но не смотря на все эти страхи и ужасы, в конкретных кейсах можно было получить профит если начать городить свой велосипед… Мне например бывало нужно записать очень быстрый поток данных, который в последствии считывался лишь пару раз, а потом стирания и опять запись. (сменные накопители для цифрового кино, в разных его проявлениях)
Это конечно самый простой кейс, но те-же прошивки на многих платформах делают по тупому, и ничего страшного не происходит, и в принципе с учётом того, что в IT хозяйстве бэкапы всё равно куда-то делаются, даже лютые глюки MLC можно и потерпеть, превращая её в эдакий кэш, ради скорости и произвольного доступа.
… но не смотря на все эти страхи и ужасы, в конкретных кейсах можно было получить профит если начать городить свой велосипед…
Мне кажется, на такие велосипеды уйдет столько времени, сил и денег, что в итоге будет дешевле сделать RAID из SSD-шек.
А вы пробовали PCI-E SSD? Или вам нужно ещё быстрее?
А вы представьте на дворе 2006 год, мне хочется цифрового кино, а один состоятельный заказчик хочет устройство для записи гигабитного потока данных, при том выдерживающего вибрации и перегрузки полностью исключающие применение какой-либо механики…
… задачи, очень близкие, но максимум что можно было купить за деньги восемь гиг SLC, или в два раза больше MLC но без каких-либо гарантий, это я про чипы говорю, готовые накопители стоили как «тот самолёт», и были слишком плохо предсказуемы, ну а любовь к кинематографу заставила меня освоиться с FPGA ибо взаимдействие с иными сенсорами была та ещё жесть, например одна большая DALSA по сути была четырьмя одинаковыми и независимыми сенсорами на одном кристалле, всё это надо было синхронно считать, склеить, подкорректировать, сжать и записать, так-что взаимодействие с MLC казалось тривиальным, а оно таковым и было в моей задаче…
… задачи, очень близкие, но максимум что можно было купить за деньги восемь гиг SLC, или в два раза больше MLC но без каких-либо гарантий, это я про чипы говорю, готовые накопители стоили как «тот самолёт», и были слишком плохо предсказуемы, ну а любовь к кинематографу заставила меня освоиться с FPGA ибо взаимдействие с иными сенсорами была та ещё жесть, например одна большая DALSA по сути была четырьмя одинаковыми и независимыми сенсорами на одном кристалле, всё это надо было синхронно считать, склеить, подкорректировать, сжать и записать, так-что взаимодействие с MLC казалось тривиальным, а оно таковым и было в моей задаче…
Неподходящий пример и неверный вывод.
Насколько я знаю, в SPI-Flash, как правило, хранится небольшой загрузчик, сжатый образ ФС (ПО прибора) и параметры устройства (эмуляция EEPROM). При старте образ разворачивается в DRAM и обмен по SPI сводится к минимуму. А обновление ПО производится достаточно редко, что-бы наплевать на пропускную способность SPI (и даже QSPI).
Насколько я знаю, в SPI-Flash, как правило, хранится небольшой загрузчик, сжатый образ ФС (ПО прибора) и параметры устройства (эмуляция EEPROM). При старте образ разворачивается в DRAM и обмен по SPI сводится к минимуму. А обновление ПО производится достаточно редко, что-бы наплевать на пропускную способность SPI (и даже QSPI).
Специально решил посмотреть, как оно организовано в OpenWRT.
Тут ничего не сказано, копируется или нет. Ядро — да, копируется, а про ФС ничего не сказано.
Тут есть примеры устройств, у некоторых объем флеша равен объему ОЗУ. Я очень сомневаюсь, что в них копируется rootfs в память.
Последняя строка намекает, что раздел rootfs монтируется напрямую как корень.
Тут ничего не сказано, копируется или нет. Ядро — да, копируется, а про ФС ничего не сказано.
Тут есть примеры устройств, у некоторых объем флеша равен объему ОЗУ. Я очень сомневаюсь, что в них копируется 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
Последняя строка намекает, что раздел rootfs монтируется напрямую как корень.
И только на вопросы, нужные для восстановления данных ваш анализ и отвечает. Все остальное вы даже и не пытались анализировать.
Вот неполный список вопросов, на которые у вас нету ответов:
И так далее… и так далее…
Чтобы нормально разобраться в том, дает ли алгоритм контроллера преимущества FAT, реверс-инжиниринга мало. Нужно дизассемблировать прошивку контроллера, а потом сделать мат-моделирование полученного алгоритма.
Того, что у вас сделано — хватает лишь для восстановления данных.
Вот неполный список вопросов, на которые у вас нету ответов:
- Есть ли список bad-блоков? Если есть — как он хранится? Ппо каким критериями блоки считаются плохими?
- Есть ли объединение двух логических записей в один блок в одну физическую? Если есть — по каким критериям?
- Сколько резервных блоков участвует в ротации? Включают ли блоки, в которых никогда не было записи, в число свободных для ротации?
- По какому критерию выбираете физический блок для записи? Первый из списка? Блок с наименьшим числом ECC-ошибок? Блок с наименьшим числом счетчика записей? Зависит ли этот критерий от номера логического блока, то есть не дает ли он преимуществ для таблицы FAT?
И так далее… и так далее…
Чтобы нормально разобраться в том, дает ли алгоритм контроллера преимущества FAT, реверс-инжиниринга мало. Нужно дизассемблировать прошивку контроллера, а потом сделать мат-моделирование полученного алгоритма.
Того, что у вас сделано — хватает лишь для восстановления данных.
И только на вопросы, нужные для восстановления данных ваш анализ и отвечает. Все остальное вы даже и не пытались анализировать.
Вы снова фантазируете. Не все опубликовано.
Есть ли список bad-блоков? Если есть — как он хранится? Ппо каким критериями блоки считаются плохими?
в рамках логического банка могут существовать блоки, которые никогда не будут включены в трансляцию. В структурах транслятора. Список формируется на этапе заливки микропрограммы и первичного тестирования памяти. Может быть дополнен в зависимости от возможностей микропрограммы. С контроллером подобным SK6211 из-за одной битой страницы (которая не может хранить данные, которые можно скорректировать посредством ЕСС) будет исключаться целиком блок.
Есть ли объединение двух логических записей в один блок в одну физическую? Если есть — по каким критериям?блоки строго по 2Мб. В трансляторе указывается порядок их использования при построение логического пространства, с которым работает ОС.
Сколько резервных блоков участвует в ротации? Включают ли блоки, в которых никогда не было записи, в число свободных для ротации?
легко посчитать. Емкость каждого логического банка по 0x400 блоков. Количество включенных в трансляцию на рис. 11. Остальное это резервные, служебные и дефектные. Естественно при каждой перезаписи какой-то из блоков «перейдет» в резервные, а какой то из резервных станет, либо блоком с данными, либо блоком со структурой транслятора.
По какому критерию выбираете физический блок для записи?
согласно счетчиков количества записей в структуре транслятора.
Зависит ли этот критерий от номера логического блока, то есть не дает ли он преимуществ для таблицы FAT?в микропрограмме SK6211, нет даже намека на анализ данных передаваемых в пакетах. Как бы Вам не хотелось бы найти подтверждение Вашей фантазии, что чуть ли не все usb flash оптимизированы под FAT, но увы анализом это не подкрепляется.
Чтобы нормально разобраться в том, дает ли алгоритм контроллера преимущества FAT, реверс-инжиниринга мало. Нужно дизассемблировать прошивку контроллера, а потом сделать мат-моделирование полученного алгоритма.
Дизассемблируйте, проверьте мои утверждения. Этот этап для меня имеет коммерческую ценность и выкладываться мной не будет.
Того, что у вас сделано — хватает лишь для восстановления данных.
чуточку больше, чем для восстановления данных.
Не все опубликовано.
Этот этап для меня имеет коммерческую ценность и выкладываться мной не будет.
Не нужны мне ваши тайны. Но то, что опубликовано — не имеет отношения к нашему спору.
Список формируется на этапе заливки микропрограммы и первичного тестирования памяти. Может быть дополнен в зависимости от возможностей микропрограммы.
Так все-таки, список хранится в ПЗУ контролера или частично во флэш? Список bad-блоков пополняется во время работы? У меня такое впечатление, что вы этот уровень не дизассемблировали и просто гадаете.
блоки строго по 2Мб. В трансляторе указывается порядок их использования при построение логического пространства, с которым работает ОС.
Вы даже вопрос не поняли. ОС делает две логические записи в 516ый и 517 сектор флэшки подряд, с интервалом 2 микросекунды. Будет ли флэшка дважды писать физическйи блок? Или сумеет объединить дев логические передачи данных по USB в одну физическую запись?
Вот как раз посекторная запись — может быть настоящей причиной сильного износа на ext2. Насколько я помню, винчестеры умеют в таких ситуациях объединять логические записи в одну физическую. А флэшка?
в микропрограмме SK6211, нет даже намека на анализ данных передаваемых в пакетах.
Не фантазируйте, номер логического блока в любом случае анализируется транслятором. Ну просто для понимания в какой физический блок и с каким смещением писать данные. Это не анализ данных, это анализ адреса данных и он все равно выполняется.
Как бы Вам не хотелось бы найти подтверждение Вашей фантазии, что чуть ли не все usb flash оптимизированы под FAT, но увы анализом это не подкрепляется.
Ну такое уж у вас качество анализа. Воспроизведите прошивку контроллера и сделайте моделирование. И вы увидите что параметры оптимизированы не под сферическую лошадь в вакууме, а под самый частый случай использования — то есть под FAT. Ибо так сделает каждый разумный инженер. А неразумные… увы, они разоряются.
Пока что вы меня убедили лишь в том, что «в подавляющем случае они не занимаются анализом данных». Но собственно этого я и не утверждал. Для оптимизации под FAT достаточно более простых вещей, чем анализ данных.
Например (и на это вы не ответили) на вышедшей с завода флэш можно держать почти все блоки в списке резервных. И это будет отлично работать именно для FAT. Например, при заполненном наполовину банке это даст 2 тысячи блоков для ротации вместо 60-70 блоков при заполненном банке.
Не нужны мне ваши тайны. Но то, что опубликовано — не имеет отношения к нашему спору.
имеет, отчасти многие выводы можно построить на основании данного анализа.
Так все-таки, список хранится в ПЗУ контролера или частично во флэш? Список bad-блоков пополняется во время работы?В трансляторе. Транслятор в блоках, которые выделены под служебные нужды.
Вы даже вопрос не поняли. ОС делает две логические записи в 516ый и 517 сектор флэшки подряд, с интервалом 2 микросекунды. Будет ли флэшка дважды писать физическйи блок? Или сумеет объединить дев логические передачи данных по USB в одну физическую запись?
Вот как раз посекторная запись — может быть настоящей причиной сильного износа на ext2. Насколько я помню, винчестеры умеют в таких ситуациях объединять логические записи в одну физическую. А флэшка?
однозначно можно сказать, что далеко не все USB flash будут обслуживать очередь команд. Чаще будет последовательное исполнение.
Не фантазируйте, номер логического блока в любом случае анализируется транслятором. Ну просто для понимания в какой физический блок и с каким смещением писать данные. Это не анализ данных, это анализ адреса данных и он все равно выполняется.
Микропрограмма USB NAND контроллера при запросе чтения/записи расчитает номер логического блока посредством деления с остатком номера LBA на размер блока. Остаток внутриблочное смещение. И для этой позиции «посмотрит» в трансляторе номер физического блока.
Трансляторы чаще выглядит по принципу:
0x0: WORD — номер физического блока в котором содержится 0 логический.
0x2: WORD — номер физического блока в котором содержится 1 логический
Естественно разрядность величин и наличие иной, кроме номера блока может иметь место. Тут уже свобода творчества разработчика, который решил или сделать много разных таблиц, или все в одной.
Ну такое уж у вас качество анализа. Воспроизведите прошивку контроллера и сделайте моделирование. И вы увидите что параметры оптимизированы не под сферическую лошадь в вакууме, а под самый частый случай использования — то есть под FAT. Ибо так сделает каждый разумный инженер. А неразумные… увы, они разоряются.
я уже Вам писал, что делать оптимизации строго под FAT неэффективное решение. Масса пользователей работает с файлами находящимися на USB flash и при редактировании из размер зачастую меняется весьма незначительно. И куда больше записей произойдет в блок с директорией и блок с файлом, при этом таблицы FAT останутся неизменными. Отсюда и направление в оптимизации паразитных нагрузок, посредством «блок апдейтов», о которых я Вам написал в другой теме.
Пока что вы меня убедили лишь в том, что «в подавляющем случае они не занимаются анализом данных». Но собственно этого я и не утверждал. Для оптимизации под FAT достаточно более простых вещей, чем анализ данных.
по факту имеем, что в подавляющем большинстве USB flash блоки с FAT таблицами располагаются с иными данными на равным правах.
Например (и на это вы не ответили) на вышедшей с завода флэш можно держать почти все блоки в списке резервных. И это будет отлично работать именно для FAT. Например, при заполненном наполовину банке это даст 2 тысячи блоков для ротации вместо 60-70 блоков при заполненном банке.
Да при изначально пустой USB flash для ротации куда большее раздолье. Но это не оптимизация под FAT — это реализация выравнивания износа, которая лучше работает при использовании FAT. До появления TRIM аналогичный механизм выравнивания износа был в SSD. C TRIM NAND контроллер более эффективно реализует механизм выравнивания износа.
однозначно можно сказать, что далеко не все USB flash будут обслуживать очередь команд. Чаще будет последовательное исполнение.
Очередь команд с выбором порядка исполнения — это сложно. А вот подождать до 0.01-10мс, не придет ли команда записи в тот же физический блок — это сильно проще.
Масса пользователей работает с файлами находящимися на USB flash и при редактировании из размер зачастую меняется весьма незначительно.
Я вам уж писал в соседнем топике, что последние 30 лет очень редко файлы перезаписываются по месту. Создает новый файл, потом идет переименование.
Да при изначально пустой USB flash для ротации куда большее раздолье. Но это не оптимизация под FAT — это реализация выравнивания износа, которая лучше работает при использовании FAT.
Да хоть
Причина, почему FAT работает лучше — найдена.она была известна и озвучивалась. Меньшее число накладных расходов (паразитных записей, нежели в случае других файловых систем).
Я вам уж писал в соседнем топике, что последние 30 лет очень редко файлы перезаписываются по месту. Создает новый файл, потом идет переименование.к сожалению не так редко, как хотелось бы.
Да хоть синхрофазотронным горшком назовите, только в ядерную печку не ставьте. Одной этой оптимизации хватает для объяснения результатов моих экспериментов.
Результат Ваших экспериментов это некоторое число зависших USB flash. Без всякого анализа Вы сделали вывод, который был удобен для Вашего понимания.
Вы можете и дальше упорствовать, что 4 — это сильно больше, чем 4. И что оптимизация, которую вам пришлось признать — это вовсе не оптимизация. И в общем можете думать все, что вы хотите.
Но только без меня, пожалуйста. Хорошо?
Но только без меня, пожалуйста. Хорошо?
Вы можете и дальше упорствовать, что 4 — это сильно больше, чем 4. И что оптимизация, которую вам пришлось признать — это вовсе не оптимизация. И в общем можете думать все, что вы хотите.поймите, Вы ведь при расчете количества записей даже в случае FAT умудрились ошибиться не учтя запись обновляющую FSinfo.
Но только без меня, пожалуйста. Хорошо?
будто бы я заставляю Вас спорить и плодить утверждения без подкрепления фактами..
Я лишь попросил Вас аргументированно ответить на Ваши первоначальные утверждения.
Вы конечно можете простой уйти из обеих тем, а можете признать, что некоторые Ваши слова не соответствуют действительности.
Ну что ж. Вы имеете право привести ссылку на документ, показывающий частоту записи 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.
Общие соображения такие. Смысл 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.
Понимаете в чем дело. Вы исходите из того, что производитель моделирует (отлаживает) свои алгоритмы на абсолютно случайно смеси записей и чтений, не имеющих отношение ни к одной файловой системе.
А я исхожу из того, что все моделирование для USB-флэш идет для типичного случая, то есть для FAT (99.5% использования).
А если мы моделируем и настраиваем алгоритм для каких-то условий, то волей не волей он оказывается оптимизирован именно для этих условий.
Это принципиальное отличие между HDD и USB-флэш. Многие тесты HDD идут без учета файловой системы. А вот тесты USB-флэш — основаны на файловой системе.
Если хотите опровергнуть — то приведите пример программы для тестирования USB-флэш, которая не использовала бы файловую систему.
А я исхожу из того, что все моделирование для USB-флэш идет для типичного случая, то есть для FAT (99.5% использования).
А если мы моделируем и настраиваем алгоритм для каких-то условий, то волей не волей он оказывается оптимизирован именно для этих условий.
Это принципиальное отличие между HDD и USB-флэш. Многие тесты HDD идут без учета файловой системы. А вот тесты USB-флэш — основаны на файловой системе.
Если хотите опровергнуть — то приведите пример программы для тестирования USB-флэш, которая не использовала бы файловую систему.
Мне даже неудобно как-то вклиниваться в эти высокие материи ваших споров...
Однако спрошу. Правильно ли понял что блок 2 мб и пишется он ВСЕГДА по 2 мб не зависимо от фактического размера данных и при любом обновлении атрибутов? Просто это кажется много.
А каковы размеры блока в SSD? Таи запись оптимизированее? МОжно ли размер простыми методами узнать? Имеет ли смысл менять кластер на размер равный\приблизительный размеру блока?
(кстати я правильно понял что последний из ваших постов между двумя постами Jet239 был удален? а то будто он отвечает вам но там пусто)
Спасибо за статью!
Интересно было узнать как оно там.
Интересно было узнать как оно там.
Пожалуйста. Если хотите, что-то еще узнать, то предлагайте темы для будущих публикаций. По мере возможностей будет рассмотрена возможность написания.
Тут ситуация, пока не прочтёшь как оно там внутри никогда бы не подумал что оно так интересно.
Расскажите про подключение и работу с мк для микро-сд флешек)
Снятие лака со стороны контактов. Работа с логическим анализатором (в некоторых случаях потребуются рентгеновские снимки). После распайка на монтажный адаптер, а в остальном все тоже самое. Посмотрим при наличии возможности и этот материал попробую показать. Но пока на очереди другие заметки.
Да простят меня за линк на конкурентов.
Восстановление данных с флешек монолит
Восстановление данных с флешек монолит
Очень грамотное описание, на мой взгляд! Спасибо!
В microsd контролёры такие же эффективные по части коррекции ошибок и распределению износа памяти или в силу уменьшения размеров что-то упрощается?
очень интересно как оно устроено в «настоящих» ssd, открытой информации по этому вопросу практически нет, только какие-то общие слова.
если брать старые SSD то там все очень похоже, как и в древних USB flash. По мере эволюции накопителей, разработчикам микропрограмм приходилось решать различные задачи, обеспечивающие скорость и живучесть накопителя, что привело к усложнению алгоритмов работы.
Возможно при наличии свободного времени напишу очередную публикацию, где рассмотрю часть алгоритмов работы микропрограммы какого-либо относительно простого SSD.
Возможно при наличии свободного времени напишу очередную публикацию, где рассмотрю часть алгоритмов работы микропрограммы какого-либо относительно простого SSD.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного реверс-инжиниринга USB flash на контроллере SK6211