makc 220 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 1 минуту назад, haker_fox сказал: Всё, что у меня есть Reliance_Edge_Developers_Guide_PDF_781.pdf 1 MB · 0 скачиваний Спасибо и на этом, хотя в общем-то и так было понятно что это типичная CoW файловая система. Интересовали именно детали, которые к сожалению в их патенте не описаны. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 238 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 2 минуты назад, makc сказал: Это не совсем так, т.к. очень многое зависит от физического носителя. Одно дело если вы напрямую работаете с NAND или NOR флешом и совсем другое если это происходит через непонятный (недокументированный) FTL, который запросто может потерять карту отображения логических блоков на физические в момент отключения питания при неудачном стечении обстоятельств. SD-карты как раз имеют такой уровень трансляции на скрытом от пользователя уровне, поэтому в общем случае ничего гарантировать не получится. Понятно, что я имел в виду "при отсутствии багов реализации". При их наличии никакая ФС не будет гарантирована от разрушения, насколько бы безопасной она не была бы в теории. Если предположить, что работаем с безглючной картой, то даже FAT16/FAT32 можно сделать абсолютно устойчивой к сбоям питания, всего-лишь добавив журналирование транзакций в слой low-level IO того же FatFS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 5 minutes ago, makc said: Интересовали именно детали Других документов у меня нет. В детали ФС я не вдавался, и даже не помню, что там описано в этой доке. Выложил сюда в надежде, что кому-либо она пригодится, раз сайт теперь закрыт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 220 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 7 минут назад, jcxz сказал: Понятно, что я имел в виду "при отсутствии багов реализации". При их наличии никакая ФС не будет гарантирована от разрушения, насколько бы безопасной она не была бы в теории. Это не совсем баги реализации, скорее это "особенности". Никто ведь не заявляет, что SD-карта будет надежно работать в условии пропадания питания во время записи? 7 минут назад, jcxz сказал: Если предположить, что работаем с безглючной картой, то даже FAT16/FAT32 можно сделать абсолютно устойчивой к сбоям питания, всего-лишь добавив журналирование транзакций в слой low-level IO того же FatFS. Поскольку в случае FAT при записи в файл в общем случае данные приходится записывать в две совершенно разные области данных (в сам FAT и в кластеры данных), то я не представляю, как вы предлагаете сделать журналирование транзакций на низком уровне. Если только вручную отслеживать где располагаются данные FAT и где начинаются данные файлов, но в этом случае мы уже говорим об отсутствии изоляции низкого и верхнего уровней (как это сделано в FatFS). С моей точки зрения это будет весьма костыльное решение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Herz 5 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 1 час назад, haker_fox сказал: Посмотрите Red FS от Reliance Edge. Использовал её в нескольких проектах. На порядки устойчивее Fat FS. Правда, в редких случаях, при интенсивном тестировании всё-таки сбои были. Разбираться мне время не дали, сказали, что "и так сойдёт". А как насчёт "порога вхождения"? Я только присматриваюсь к Fat и как-то опасаюсь, что освоение займёт у меня прилично времени... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 220 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 36 минут назад, Herz сказал: А как насчёт "порога вхождения"? Я только присматриваюсь к Fat и как-то опасаюсь, что освоение займёт у меня прилично времени... Судя по API там всё довольно просто (на входе), а вот докопаться до причин проблем без описания логики и архитектуры будет проблематично (выход будет дорогой). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 2 часа назад, jcxz сказал: Журналирующая запись сделает любое небезопасное отключение, безопасным. А что произойдет, если сбой питания будет в момент записи в журнал? Информация пропадет по-любому... Все, что дает журналирование - это спасение ФС и не более того... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 220 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 42 минуты назад, mantech сказал: А что произойдет, если сбой питания будет в момент записи в журнал? Информация пропадет по-любому... Все, что дает журналирование - это спасение ФС и не более того... Нет совсем даже не обязательно, почитайте как устроены Copy on Write (CoW) ФС. В них ничего не пропадает, если носитель гарантирует целостность данных, которые в момент выключения питания не модифицируются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба On 9/7/2021 at 6:09 AM, Ruslan1 said: Устройство безостановочно работает месяцами-годами. Периодически пишет на SD-карту. Используется FAT32 (из FatFS Чина), SDIO интерфейс. И есть сильные подозрения, что внутренний контроллер SD карты не очень-то и выравнивает количество записей по физическим секторам. В результате появляются bad block, и время чтения некоторых секторов сильно увеличивается. Бэды появляются там, куда часто пишем (FAT). Время доступа тоже очень вырастает для части блоков. Изношенная флеш память даст сбой в любом случае. Если это устройство разрабатывается, то я бы сделал неотъемлимой частью проекта архивирование данных на другой носитель. К тому же регламентировать замену носителя при 75-80% износа. В готовом устройстве такие изменения сделать труднее. ext3 или ext4 защитят от сбоев, вызванных внезапным обесточиванием. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 238 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 2 часа назад, mantech сказал: А что произойдет, если сбой питания будет в момент записи в журнал? Информация пропадет по-любому... Все, что дает журналирование - это спасение ФС и не более того... Что произойдёт если сбой произойдёт перед записью? Не знаете что происходит с информацией в ОЗУ при выключении питания? Вот то и произойдёт. Журналирование спасает от разрушения уже записанных ранее данных (и всей структуры их хранения). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 238 8 сентября, 2021 Опубликовано 8 сентября, 2021 · Жалоба 5 часов назад, makc сказал: Поскольку в случае FAT при записи в файл в общем случае данные приходится записывать в две совершенно разные области данных (в сам FAT и в кластеры данных), то я не представляю, как вы предлагаете сделать журналирование транзакций на низком уровне. Если только вручную отслеживать где располагаются данные FAT и где начинаются данные файлов, но в этом случае мы уже говорим об отсутствии изоляции низкого и верхнего уровней (как это сделано в FatFS). С моей точки зрения это будет весьма костыльное решение. Все операции с файлами выполняем в виде отдельных безопасных транзакций. Перед такой транзакцией - стабильное валидное состояние ФС, и после завершения транзакции - другое стабильное валидное состояние. В low-level IO слой посылаем сообщение "Начало транзакции" и "Конец транзакции" соответственно - перед ней и после её завершения (в хвосте завершения не забыть сделать flush() буферов записи ФС). По 1-му сообщению слой low-level IO открывает запись о транзакции (помечает запись как "пустая"); далее в теле транзакции слой low-level IO сохраняет в эту запись все запрошенные операции записи/стирания с секторами карты (вместе с их содержимым); по сообщению "Конец транзакции", слой low-level IO закрывает созданную запись (помечает её как "заполненная" (точка 1)); далее - выполняет все операции, содержащиеся в этой записи; далее - удаляет запись (помечает её как "удалённая" (точка 2)). Очевидно, что опасный интервал - между точками 1 и 2. Если в этот момент происходит перезагрузка, ФС находится в промежуточном состоянии. Тогда код монтирования слоя low-level IO, увидев валидную заполненную запись, выполняет все операции записанные в неё, и удаляет её. Очевидно, что сбой питания может произойти сколько угодно раз в этом интервале - при каждом рестарте ПО код будет выполняться заново, до тех пор, пока не успеет дойти до точки 2. Как видно - никакой связи с логическим уровнем ФС у слоя low-level IO тут нет и оно ему не нужно. И тип ФС этому слою тоже по-барабану - будет работать с любой ФС. Минус конечно в том, что объём данных в такой безопасной транзакции будет ограничен ёмкостью журнала. Но можно этот минус сильно уменьшить, усложнив алгоритм (добавив слой переназначения секторов например или как-то по-иному). PS: И да конечно - выдёргивать карту в таком случае можно только сделав предварительно "безопасное извлечение". Хотя и от этого можно избавиться, если журнал хранить на этой же SD, а на ПК написать драйвер, который будет выполнять ту же операцию, что и код монтирования (при обнаружении заполненной записи журнала). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 9 сентября, 2021 Опубликовано 9 сентября, 2021 · Жалоба 7 hours ago, Herz said: А как насчёт "порога вхождения"? Чуть заморочистей (ИМХО), чем FatFS. Хотя бы потому, что настраивать эту ФС нужно специальной утилитой (была бесплатной). А так, всё стандартно: все функции понятны по их именам. Открыть файл, писать, читать, закрыть. То же самое с директориями. Пара служебных функций для разметки диска. FatFS значительно проще. Снова же ИМХО. Возможно, потому что она всё-таки FAT и многократно где описана. Тем не менее, внимательное вычитывание документации решает значительное количество невозникших проблем. В документации и на ту и на ту ФС описано всё, чтобы их использовать. Включая, написания драйверов IO. Кстати, RedFS позволяет взять драйвера нижнего уровня от FatFS. В обоих системах есть заготовки для их работы в различных ОСРВ. Мне была актуальна только FreeRTOS, которую мы используем на работе. 7 hours ago, makc said: а вот докопаться до причин проблем без описания логики и архитектуры будет проблематично (выход будет дорогой) С этим соглашусь. Как я уже отмечал, у нас на объектах была пара сбоев RedFS. Я не смог найти причину. По-крайней мере в своём ПО. А разбираться во внутренностях RedFS без документации не было ни желания, ни времени. Сейчас снова стоит передо мной вопрос отказоустойчивой системы, я буду настаивать на собственном изготовлении. Тут хотя бы будет понятно, чей косяк и где) Кстати, а Вы не знаете подобного рода готовые хорошие ФС, пригодные для использования на bare-metal (без linux, win, qnx ит.п. больших систем)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 220 9 сентября, 2021 Опубликовано 9 сентября, 2021 · Жалоба 8 часов назад, Tarbal сказал: ext3 или ext4 защитят от сбоев, вызванных внезапным обесточиванием. Включение журнала только для метаданных на этих ФС при использовании на SD убивает ресурс карт и очень тормозит, при этом ни от чего толком не защищает, т.к. структура ФС и её логика не учитывает особенностей носителя типа SD-карт. Поэтому наличие слова "журналирование" в описании ФС совсем недостаточное условие. 6 часов назад, jcxz сказал: Не знаете что происходит с информацией в ОЗУ при выключении питания? Вот то и произойдёт. В ОЗУ какого типа? Статического или динамического? Они ведут себя по-разному в этих условиях. 6 часов назад, jcxz сказал: Журналирование спасает от разрушения уже записанных ранее данных (и всей структуры их хранения). Не всегда, см.выше про журналирование метаданных (включенное по-умолчанию) на ext3 и ext4. Хотя в целом я с вами согласен. 6 часов назад, jcxz сказал: Как видно - никакой связи с логическим уровнем ФС у слоя low-level IO тут нет и оно ему не нужно. И тип ФС этому слою тоже по-барабану - будет работать с любой ФС. Вы сами описали логику, которая предполагает наличие сигнализации начала и конца транзакций, которую нужно реализовать на верхнем уровне ФС для нижнего уровня, работающего с носителем. Эта логика и определяет такую связь. И в существующей реализации того же FatFS ничего для этого нет, поэтому либо модифицировать FatFS, либо тащить на самый высокий уровень. Оба решения по-своему плохи. 2 часа назад, haker_fox сказал: Кстати, а Вы не знаете подобного рода готовые хорошие ФС, пригодные для использования на bare-metal (без linux, win, qnx ит.п. больших систем)? Готовых и сразу хороших мне под свои задачи найти не удалось. Я писал свои. Одну с учётом фамильной специфики NOR-флешек серии AT45DB, вторую для 25й серии типа W25Q и им подобных. Вторая по логике работы похожа на https://github.com/pellepl/spiffs и в принципе делает то же самое, только немного по-своему и как мне кажется получше. Поэтому если у вас относительно небольшие NOR флешки, то можно взять эту spiffs и сделать на её основе своё решение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 9 сентября, 2021 Опубликовано 9 сентября, 2021 · Жалоба Выключения у меня и сейчас с FAT32 ни к чему фатальному не приводят в абсолютном большинстве случаев- я даже перманентную запись веду с буферизацией, отрывая файлы на короткое время для записи буфера на карту. Моя проблема именно в "затирании" и появлении bad blocks. Раньше даже было что карточки в Read-only переключались, но там софт действительно много писал на крточку, причем малыми порциями. Переписал с тех пор сильно программу, теперь до этого не доходит. Я уже думал про SLC и Industrial Grade. цена вопроса невелика по сравнению с остальными вариантами. Но что я могу обещать? Если сейчас нефейковый SanDisk SDHC UHS-I начинает глючить через полгода-год, то другая карточка (SLC) сколько протянет, пять лет? Для меня это самый бюджетный вариант по сравнению с изменением софта и дополнительными телодвижениями для чтения экзотических фаловых систем в Винде. Просто заплатить за хорошие карточки выгоднее. Буду смотреть.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 238 9 сентября, 2021 Опубликовано 9 сентября, 2021 · Жалоба 3 часа назад, makc сказал: В ОЗУ какого типа? Статического или динамического? Они ведут себя по-разному в этих условиях. Одинаково - разрушается содержимое. Цитата Вы сами описали логику, которая предполагает наличие сигнализации начала и конца транзакций, которую нужно реализовать на верхнем уровне ФС для нижнего уровня, работающего с носителем. Нет, я там имел виду сигнализацию о начале-завершении транзакций с уровня пользовательского приложения (выше ФС). Т.е. - любые операции с ФС пользователь выполняет через функции-обёртки (описанные в его пользовательском коде либо прослойке между его кодом и ФС). В начале такой обёртки - сигнал "начало в слой журналирования" (мимо или сквозь ФС), в конце - "завершение в слой журналирования". Сами эти обёртки и слой журналирования о типе ФС (и формате её хранения на диске) ничего не знают. Например обёртка "добавление/модификация одной записи в базе данных на диске": 1. Начало транзакции в слой журналирования. 2. Запись внутрь файла file1.data базы данных по смещению X1. 3. Запись внутрь файла file1.index базы данных по смещению X2. 4. Конец транзакции в слой журналирования. И все операции добавления/модификации записей с этой БД должны выполняться через эту функцию-обёртку. И они станут перезагрузко-безопасными. Цитата Эта логика и определяет такую связь. И в существующей реализации того же FatFS ничего для этого нет, поэтому либо модифицировать FatFS Не надо ничего модифицировать! См. выше. FatFS (или любую другую) вообще не трогаем. Она ничего не знает о нашем журналировании. 5 минут назад, Ruslan1 сказал: Выключения у меня и сейчас с FAT32 ни к чему фатальному не приводят в абсолютном большинстве случаев- я даже перманентную запись веду с буферизацией, отрывая файлы на короткое время для записи буфера на карту. Просто везёт. Запустите миллион ваших устройств, работающих 24/7 и непрерывно пишущих на диск.... и проблемы посыпятся потоком. 5 минут назад, Ruslan1 сказал: Для меня это самый бюджетный вариант по сравнению с изменением софта и дополнительными телодвижениями для чтения экзотических фаловых систем в Винде. Просто заплатить за хорошие карточки выгоднее. Буду смотреть.... Если нет уверенности, что выравнивание износа работает в карте, то почти единственный путь (если всё-же такие карты использовать) - реализовать собственный слой выравнивания износа на уровне low-level IO. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться