Опубликован выпуск проекта LittleFS 2.10, развивающего компактную файловую систему для встраиваемых устройств и микроконтроллеров. Изначально файловая система была создана компанией ARM для операционной системы Mbed OS, но затем выделена в отдельный проект. Код ФС написан на языке Си и распространяется под лицензией BSD. Эталонная реализация LittleFS поставляется в виде Си-библиотеки, на базе которой создан FUSE-модуль и обвязки для различных языков программирования...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62398
Годно. А то понапридумывают монструозных btrfs, а людям простые фс нужны. Уже по списку багфиксов видно насколько она простая.
Мне нужна фс чтобы везде работает. А то мой андроид видит только фат32.
Гнусмасовский Андроед должен бы видеть ещё F2FS. Это же их родное детище.
Это детище Самсунга так то, только потом они отдали это в открытый доступ
Мой текущий сасунг-пхоне уже не подразумевает внешней карточки. Так что пофиг.
> Мой текущий сасунг-пхоне уже не подразумевает внешней карточки. Так что пофиг.Ну так замажь его замазкой чтоб не тек!
Прочитай Гнусмас наоборот.
Удивительно! У вас, наверное, очень старый смартфон?У меня есть Samsung Galaxy Star Plus GT-S7262. Android 4.1 Изначально я использовал для него внешнюю карту памяти с файловой системой FAT32.
После того как купил новый смартфон, я разрешил root-доступ на своём старом устройстве. И использую его в основном как музыкальный плейер.SD-карту разбил на три раздела: Ext4, SWAP, FAT32.
- На Ext4 расширил системный раздел для APK.
- SWAP 1 Гб, чтобы суспендить некоторые задачи.
- FAT32 для данных пользователя.
Пользовался только возможностями стоковой прошивки.
Хорошо если так. Если я форматировал флешку под Ext4, Android (любой) говорил, что она странная и надо её форматировать под exfat
А теперь попробуйте прошить сток, после чего проверить работоспособность ext раздела
Не совсем понимаю, зачем что-то прошивать? Я использую стандартную прошивку.
Автоматизировал только несколько вещей:
- Указал точки монтирования в файле fstab, и после перезагрузки устройство видит нужные разделы.
- Прописал символические ссылки.
Возможно, я занимался чем-то ещё, но из-за давности событий не могу точно вспомнить.Насколько мне известно, на системном разделе этого устройства от Samsung используется файловая система Ext3 или Ext4. В результате не произошло ничего необычного.
> Насколько мне известно, на системном разделе этого устройства от Samsung используется файловая
> система Ext3 или Ext4. В результате не произошло ничего необычного.Использоваться то используется, но на большинстве андроидов из коробки монтирование ext разделов в юзерспейсе невозможно
> монструозных btrfsВ CoW файловых системах нет ничего монструозного. ZFS давно уже успользовалась компаниями, работает по схожему принципу. Сейчас некоторые ZFS на BTRFS меняют из-за нативной поддержки на уровне Linux ядра и ничего при этом не теряют.
PS: и сабж, кстати, тоже CoW, за такими системами именно будущее.
В иерархических (не плоских) ФС нет ничего монструозного. ZFS давно уже успользовалась компаниями, работает по схожему принципу. PS: и сабж, кстати, тоже иерархический, за такими системами именно будущее.
> В иерархических (не плоских) ФСты сам то понял про что ты пишешь?
FAT12 это пример плоской файловой системы. где все файлы размещаются в корневом каталоге без подкаталогов.
А BTRFS, ZFS, LittleFS к таким не относятся.
> FAT12 это пример плоской файловой системы. где все файлы размещаются в корневом каталоге без подкаталогов.Открою секрет, каталог это тоже файл
> Открою секрет, каталог это тоже файлВот это мягко говоря - зависит от. Вооон те B-Tree это ну такой себе очень условный "файл". Как максимум там от файла будет немного абстракции, для совместимости по апям...
>> Открою секрет, каталог это тоже файл
> Вот это мягко говоря - зависит от. Вооон те B-Tree это ну такой себеА чей-то ты переключился с абстракции представления на абстракцию реализации?
Файлы, каталоги, папки, директории, ссылки, пайпы, девайсы, двери, ...
> А чей-то ты переключился с абстракции представления на абстракцию реализации?Когда абстракция довольно сильно расходится с реализацией, это начинает напоминать натяг совы на глобус и может работать не очень хорошо.
Де факто например под CoW, SSD и все такое - часть файловых операций вообще стоило бы несколько переделать.
> FAT12.. все файлы размещаются в корневом каталоге без подкаталогов.FAT12 с каталогами, кроме редакции для DOS 1.x.
Без каталогов, плоская, и по дурости все ещё используемая, это SPIFFS.
(но проблема там не в отсутствии каталогов, а в ненадежности)
а что там с БД? есть подозрения что redo log, апдейт индекса не выиграют от CoW
Могут и выиграть. Просто не бывает так чтобы одни только плюсы.https://notes.eatonphil.com/whats-the-big-deal-about-key-val...
http://www.bzero.se/ldapd/btree.htmlНу вот как-то так, да. Можно дерево расплющить и COWнуть. Просто это не совсем халявно.
Впрочем господа типа поха рассказывающие про write amplification - упорно игнорят что для in place патча вон той мелочи SSD эвона какое действо вообще развернет. А HDD будет тормозить от метания во все стороны.
> Могут и выиграть. Просто не бывает так чтобы одни только плюсы.
> https://notes.eatonphil.com/whats-the-big-deal-about-key-val...
> http://www.bzero.se/ldapd/btree.htmlв первой статье какая-то херата написана:
${TABLE_IDENTIFIER}_${PRIMARY_KEY}_${ROW_IDENTIFIER}: ${ENCODED_VALUE}
Embedded key-value stores almost always support efficient scanning of rows by a key-prefix. This means that you can efficiently grab all rows within a table by prefix-scanning on the table identifier.так а что нового? точно также как ты получишь эффективный скан по кластерному первичному ключу в любой RDBMS
и какое отношение это имеет к CoW?
то что SSD будет насилован - это понятно, но там есть DRAM и конденсатор, если не дешман-диск ))
но я о другом, скорее всего запись dirty pages не почувствует этот cow - блоки будут заменяться целиком, а вот с redo/undo log есть вопросы, потому что он пишется первым и флашится после каждой транзакции, которая может быть очень маленькой, но придется считать целый блок на уровне FS и записать его, и похожая ситуация с обновлением индексов
> Сейчас некоторые ZFS на BTRFS меняют из-за нативной поддержки на уровне Linux ядра и ничего при этом не теряют.Ну да ничего не теряют. Кроме данных, которые хранятся на btrfs.
К сожалению ее так и не допили до работоспособного состояния.
У меня как раз очередная попытка была его поиспользовать несколько месяцев назад. Через пару месяцев использования она была безнадёжна повреждена - некоторые файлы были недоступны к использованию.
Сколько реплик использовали? С какой периодичностью Scrub и Balance прогонялся?
Или не зная броду сунулись в воду?
> Ну да ничего не теряют. Кроме данных, которые хранятся на btrfs.
> К сожалению ее так и не допили до работоспособного состояния.При том лучше всего как оно в btrfs почему-то в курсе всякие маздащики и прочие BSDшники. Один из которых тут и нарисовался. Что бы это могло быть? :)
При том лучше всего как оно в BSD почему-то в курсе всякие маздащики и прочие 294ые. Один из которых любит нарисоваться в каждой БЗДшой новости.
Но! "Стрелочка не поворачивается, нет!" 🙂Кстати, отписавшийся в этой ветке ниже, в #77 - маздайщик или "бздун"?
А из соседней новости?
https://www.opennet.dev/openforum/vsluhforumID3/135573.html#13
> btrfs отличная фс, фич море, но я постоянно с ней на штыках. Полностью дефолт, никаких дополнительных опций не включаю и при этом от одного до нескольких раз в год теряю данные (резервные копии наше всё). Устройства разные, производители разные.Или как обычно "там читаем, там ... рыбу заворачивали!"?
> При том лучше всего как оно в BSD почему-то в курсе всякие
> маздащики и прочие 294ые. Один из которых любит нарисоваться в каждой
> БЗДшой новости. Но! "Стрелочка не поворачивается, нет!" 🙂Почему же. Мой показометр прекрасно детектит вас и декодирует все ваши примитивные потуги и (анти)паттерны.
А на маздайщика я не тяну чисто технически, за отсутствием у меня и намека на маздай. Я взял и перенес все мои воркфлоу на пингвин. Мне некуда отступать, поэтому я обеспечу ЗБС в этой системе. И себе и другим. Это по своему прикольно. Иногда полезно покидать зону комфорта, но вам кажется не рассказывали это.
> Кстати, отписавшийся в этой ветке ниже, в #77 - маздайщик или "бздун"?
Да кто его там знает. Может и просто чайник, делавший что-то странное. Или с откровенно битым железом. На ext4 и прочих FAT - про битость файлов пользак узнает в последнюю очередь. Когда масштаб трэша уже совсем ломовой и там живого места не осталось. Деталей там никаких нету. Предлагается джентльмену на слово верить. Ага. Вы вместе с ZFSниками уже показали как это рабоатет, так что - ну вот не.
> А из соседней новости?
> https://www.opennet.dev/openforum/vsluhforumID3/135573.html#13В этом спиче налицо несоответствие деклараций и фактов. Т.е. чел утверждает про руки и голову, но даже не нашел причину факапа. А она обычно вполне рациональна и логична.
"У меня в чулане что-то стучит" - это не аргумент. Показать конкретный факап с техническими деталями - как бы да. А сказ каких-то хмырей по рандому о стуке в подполе - я могу такого спама написать с 10 разных ников ничуть не хуже.
> Или как обычно "там читаем, там ... рыбу заворачивали!"?
Не, просто двойный стандарты и потуги даунплея факапов одних и выпячивание мутных заяв других - весьма сомнительный подход к делу как по мне.
> Почему же. Мой показометр прекрасно детектит вас и декодирует все ваши примитивные
> потуги и (анти)паттерны."Показометр" и "детектирует" -- неплохой эвфемизм для "πуканчик" и "подгорает" 🙂
> А на маздайщика я не тяну чисто технически, за отсутствием у меня и намека на маздай.
Ну да, кто ж себе, любимому, смерти желать будет - только другим, ага (разжевываю: если хочешь намекнуть на венду, а не на свой совсем уж радикальный фанатизм - пиши "пользователи маздая")
> Я взял и перенес все мои воркфлоу на пингвин. Мне некуда отступать, поэтому я обеспечу ЗБС в этой [остальная вода поскипана]О, опять завел шарманку.
Неужели я угадал с эвфемизмами и радикальным фанатизмом?
Ну тогда: я не пользуюсь ни мастаем (ни макосью) года с 2005 и прочее бла.
Гори^W Живи теперь с этим 🙂
> Да кто его там знает. Может и просто чайник, делавший что-то странное.
> [...] Предлагается джентльмену на слово верить. Ага.[...]
> В этом спиче налицо несоответствие деклараций и фактов. Т.е. чел утверждает про
> руки и голову, но даже не нашел причину факапа. А она
> обычно вполне рациональна и логична....
> Не, просто двойный стандарты и потуги даунплея факапов одних и выпячивание мутных(припоминая твое же недавнее педалирование "на вон том макпуке не работает" и постоянные отсылки на комменты крипта - где тоже "предлагается верить джентельменам на слово", как впрочем и постоянные унылые попытки глупых набросов в бздяшных новостях по мотивам "слышал звон")
Уж чья бы корова насчет двойных стандартов и даунплеев мычала бы ...
> "Показометр" и "детектирует" -- неплохой эвфемизм для "πуканчик" и "подгорает" 🙂Вам виднее что там у вас подгорает.
> Ну да, кто ж себе, любимому, смерти желать будет - только другим,
Это, выражаясь вашими словами, эвфемизм. Хотя...
> ага (разжевываю: если хочешь намекнуть на венду, а не на свой
> совсем уж радикальный фанатизм - пиши "пользователи маздая")Ну так я себе не враг - поэтому и не юзаю маздайную ос, собственно. А самые суровые и непримиримые противники образуются после обнаружения что им делали мозг, и радикальной смены сторон.
> Неужели я угадал с эвфемизмами и радикальным фанатизмом?
У меня есть персональные причины не жаловать майкрософт, и его приспешников. За мной накопился довольно большой техдолг и я верну его этим господам, с превышением.
> Ну тогда: я не пользуюсь ни мастаем (ни макосью) года с 2005
> и прочее бла. Гори^W Живи теперь с этим 🙂ИМХО вы приврали или не сказали всей правды. Хотя возможно это "с такими друзьями никаких врагов не надо". Надеюсь что линухи вы тоже не юзаете, упаси меня от таких "друзей", ножики из спины вынимать замучаешься.
>> Не, просто двойный стандарты и потуги даунплея факапов одних и выпячивание мутных
> (припоминая твое же недавнее педалирование "на вон том макпуке не работает" и
> постоянные отсылки на комменты крипта - где тоже "предлагается верить джентельменам
> на слово", как впрочем и постоянные унылые попытки глупых набросов в
> бздяшных новостях по мотивам "слышал звон")Так сами же фряшники и пишут советы как openwrt в виртуалочке запускать чтоб вафля работала. Ну о них и мнение за такие советы - под стать. Если б линуксоиды писали советы по использованию RNDIS я б к авторам таких советов тоже не очень относился. Но к счастью это повымерло.
> Уж чья бы корова насчет двойных стандартов и даунплеев мычала бы ...
Судя по подгару я все же угадал.
Эту балалайку развивают уже 6 лет и она только сейчас научилась слеши обрабатывать. Фейспалм.
Ну дак ты до сих пор не умеешь походу ...
>уже 6 лет
> Эталонная реализация LittleFS поставляется в виде Си-библиотекиПочему не на rus то есть ada gnat fsf?
>В реализации LittleFS применяются только статически определённые буферы (без динамического выделения памяти)Use after free ей и так не грозит.
А как же традиция сишников вылазить за пределы буфера при любом удобном случае?
Джаваскрпитизеры некогда не вылезают а толку?
Неправильный код. Нужно динамическое выделение и боровчекер.
Почему не на русской Ада? Ну пока что есть только русский Оберон.
> Почему не на русской Ада? Ну пока что есть только русский Оберон.Это вы так 1С чтоли обозвали?
Микроконтроллеры из коробки чаще всего только FAT32 умеют. Интересно было бы попробовать.
Эта FS давно распространена на ESP8266 и ESP32.
так я не понял, как её юзать на Ардуино ???
Через API, которое прописано в документации этой ФС.
а как закидывать файлы или снимать с этой SD в Windos XP ? Какая ОС работает с LittleFS 2.10 ?
1) читаешь API своей ОС, касаемые работы файловых систем
2) читаешь API в докуметации файловой системы
3) пишешь драйвер, используя эти API
4) устанавливаешь драйвер
5) пользуешься
> а как закидывать файлы или снимать с этой SD в Windos XPЭта ОС уже не поддерживается производителем - а остальным это все и подавно нахрен надо, соответственно. Кроме случая когда кто-то из тех кому надо - сам разопрется решать свои проблемы.
> ? Какая ОС работает с LittleFS 2.10 ?
> LittleFS поставляется в виде Си-библиотеки, на базе которой создан FUSE-модульВ принципе любая под которую FUSE есть. А это довольно много чего. Поддерживает ли FUSE актуальных версий и этот модуль работу в XP - я ессно без понятия.
Спасибо, я не знал про FUSE
> Спасибо, я не знал про FUSEДа правильно, кто же читает новости до того как еще и коментить к ним?!
чукча не читатель - чукча писатель!
Не думал, что статические буферы это охренеть какая особенность. Часто байты внезапно превращаются в петабайты. Ну кто знал...
> Для исключения нарушения целости и потери данных применяется механизм copy-on-write (COW)1) данные при внезапном отключении питания в любом случае потеряются - буфер в ОЗУ
2) так как буфер этот будет минимальным по причине 1) и потому что это для устройств с ограниченной ОЗУ тормозит это наверняка адово3) нештатные отключения питания можно еще обработать на raw nand но никак не на современных накопителях со своим встроенным FTL - так что все прелести этой ОС обнуляются а востатке только тормоза из 2)
>>при внезапном отключении питания в любом случае потеряютсяКак напишете так и будет. :)
Достаточно не запарывать файловую систему. А после восстановления питания можно продолжить.>>буфер в ОЗУ
Так это буфер диска, а исходные данные в приложении, которое просто повторит запись.
А важные данные хранят в энергонезависимом RAM, EEPROM, FRAM, что б при внезапном отключении ничего не терялось.
На том же ESP32 для этого есть дополнительные 8 кБ статического ОЗУ подпитанного от батареи RTC. Даже ничего мудрить не надо.
> исходные данные в приложении, которое просто повторит запись.афигеть! прилажение "просто повторит"
да если такие требования к прикладному софту выдвигать, да еще заставлять его хранить по другим ЗУ и синхронизировать, то файловая система и нинужна тогда.
я теперь понимаю чо серьезные databases стремились себе отгрызть raw раздел и там самим уже как-то рулить - хоть мешать не будут.
> я теперь понимаю чо серьезные databases стремились себе отгрызть raw раздел и там самим уже как-то рулить - хоть мешать не будут.А получалось у них боль и страдание. Особенно при сбоях железа.
Именно так! Чем проще ПО, но логически обосновано, тем всё в нём проще.>>..то файловая система и нинужна
Разница в размерах энергонезависимой памяти, и размере файловой системы.
Конечно, можно с флеш и напрямую работать, что нередко и делается, и для баз данных особенно,
только те данные которые не успел записать при выключении питания, тоже надо как то продожить записывать, и где то хранить.
И.. "выливаем воду из чайника, и задача сводится к предыдущей"(с)Кстати, даже в игрушечном ESP32, внутренную флеш можно разбить на разделы, и сделать как RAW разделы, так и с файловыми системами, и пользоваться тем и другим.
Возвращаясь к файловым системам в мелких контроллерах.
SPIFFS - сыплется на ровном месте, нередко даже без записи.FAT32 - сыплется сильно меньше, но обычно её не сложно восстановить даже силами мелкого контроллера, но это лишний код, а размеры флеш там точно ограничены.
LittleFs - самое то. Есть мелкие особенности в исходниках, зато не доставляет проблем в работе.
> только те данные которые не успел записать при выключении питания, тоже надо
> как то продожить записывать, и где то хранить.Или не надо. Без многих данных можно прекрасно прожить. А мелкая хрень на МК к тому же от кондеров может продержаться достаточно чтобы закончить все что оно там хотело. Да и от аккумулятора эвона сколько фигачить может, если надо.
> Без многих данных можно прекрасно прожить.Конечно. Сохранение данных, именно с точным сохранением данных нужно далеко не все устройствам.
Но речь то о надежности файловой системы. Какое нибудь протенькое устройство может писать логи, и при неудачном отключении питания запороть все. Или удаленное обновление ПО, что и простых устройсвах сейчас не экзотика, должно переживать отключение в любой момент перезаписи прошивки и продолжить работу.
> А мелкая хрень.. от кондеровЯ и в поделках ориентируюсь на ГОСТ, по профессиональной привычке, и хоть и отступаю от них, но хотя бы читаю и задумываюсь. В общем, хрень не делаем.
> Конечно. Сохранение данных, именно с точным сохранением данных нужно далеко не все устройствам.
> Но речь то о надежности файловой системы. Какое нибудь протенькое устройство может
> писать логи, и при неудачном отключении питания запороть все.Это только при тупом подходе к ФС. Хотя и на обычных девайсах бывает, когда умники переформатируют флеху, разложив партишн в том же блоке что FAT. При слете питания улетает не только часть фата, но и партишн.
> Или удаленное обновление ПО, что и простых устройсвах сейчас не экзотика, должно переживать
> отключение в любой момент перезаписи прошивки и продолжить работу.Имеет полное право вывалиться в урезанный бутлоадер при полном факапе. Если такое надо, нормальный подход либо 2 копии фирмвари завести и при обломе с стартом обновляемой по любой причине - юзать предыдущую, или - качать фирмвару в скажем другую SPI флеху, sd карту или что там - откуда шить уже после получения целиком, от и до. Чтоб не остаться с полупрошитой железкой когда ремота уже куда-то свалила.
>> А мелкая хрень.. от кондеров
> Я и в поделках ориентируюсь на ГОСТ, по профессиональной привычке, и хоть
> и отступаю от них, но хотя бы читаю и задумываюсь. В
> общем, хрень не делаем.Ваши госты давно и являют собой - хрень. Мониторинг питания и корректная реакция на его отвал - совершенно нормальаная ситуация в МК.
>> умники переформатируют флехуLittleFS для других флешек, оставьте тех умников наедине с их проблемами
>>Имеет полное право вывалиться в урезанный бутлоадер
Превращение в кирпич при удаленном обновлении? И напомню отключение будет именно в самый неподходящий момент. Если об этом задумываются до того как вляпаются, то способов решения проблемы много. Но обычно об этом не думают - "что может пойти не так?" :)
>>госты давно и являют собой - хрень.
Они обновляются и вводятся новые, и для всяких контроллеров и протоколов, тем более.
Проблема с ГОСТАми в стиле изложения, что не позволяет им стать книгой полезных советов.
> LittleFS для других флешек, оставьте тех умников наедине с их проблемамиВ общем то да. Но вон то все же бывает и все же характерная для флеша проблема. Связанная на самом деле с тем что erase blocks у флех - довольно здоровые. А запись на самом деле состоит из "erase" и "program". При том первое только - здоровенными блоками.
> Превращение в кирпич при удаленном обновлении? И напомню отключение будет именно в
> самый неподходящий момент.Ну как бы если на выбор кирпич даже без бутлоадера.... :)
> Если об этом задумываются до того как вляпаются,
> то способов решения проблемы много. Но обычно об этом не думают - "что может
> пойти не так?" :)Способов и правда много. Но практически все они - не халявные ни разу. Т.е. надо либо места в основной флехе мк на 2 фирвари + бут (увеличение требований более чем вдвое), либо сохранение фирмвари в некую внешнюю флеху, чтоб потом уж точно прошить. И это тоже ессно тоже лишние детали и не бесплатно.
>>>госты давно и являют собой - хрень.
> Они обновляются и вводятся новые, и для всяких контроллеров и протоколов, тем более.Только этот процесс лагает на дофига лет и в целом - принадлежит к категории документов где трава должна быть зеленой, а то что январь - да подумаешь, ведерко зеленой краски.
> Проблема с ГОСТАми в стиле изложения, что не позволяет им стать книгой
> полезных советов.Их проблема в том что они зачастую - контрпродуктивны, отсталы и - активно мешаются.
> А важные данные хранят в энергонезависимом RAM, EEPROM, FRAM, что б при внезапном отключении ничего не терялось.и вот вы пришли к тому что весь этот софтовый кал не нужен - нужно бесперебойное питание
> * не нужен - нужно бесперебойное питаниеБесперебойное питание тоже пропадает.
Да, с ним проблем меньше, но в надежном ПО нельзя все сваливать на аппаратнве проблемы.Так же файловая система и способ обмена информацией. В случае микроконтроллеров, обычно через Веб интерфейс.
> Бесперебойное питание тоже пропадает.на то оно и бесперебойное чтобы НЕ пропадало, а если деньги есть лучше FRAM/MRAM etc вы ничего не придумаете но опять же весь этот софтовый кал не нужен
Если есть деньги, то можно нанять золотаря для работы с "софтовым калом", получится гораздо дешевле, чем FRAM/MRAM.
> можно нанять золотаря для работы с "софтовым калом"поставь копеечный ионистор для корректного завершения работы при отключении питания и нанимать никого не надо - надо грамотно системы проектировать
> поставь копеечный ионистор для корректного завершения работы при отключении питания и нанимать
> никого не надо - надо грамотно системы проектироватьУвы, это требует SRAM который при прочих равных намного дороже DRAM с 1 стороны, чтоб мало жрало в холостом режиме, и не такие уж ионисторы и копеечные - с другой.
Так что в контексте ФС и долговременного хранения данных это все же не решение, увы. И даже не адресует простой топик - а что если это на полочку положат на пару лет после вон того эвента? Заряда в ионисторе не так уж и много.
> Увы, это требует SRAM который при прочих равных намного дороже DRAMничего он не требует, ионистор это конденсатор большой емкости, энергии его хватит чтобы корректно сохранить данные вообще ничего не теряя и не ломая любую нетормозящую фс при потере питания - запускать по прерыанию завершение работы как с ибп компах.
>> Увы, это требует SRAM который при прочих равных намного дороже DRAM
> ничего он не требует,Если именно хранить, именно в ней - то требует. DRAM жрет слишком много.
> ионистор это конденсатор большой емкости, энергии его хватит
> чтобы корректно сохранить данные вообще ничего не теряяЕсли данных немного - для мк хватит и просто кондеров. В каких-то случаях и ионисторы - вариант, но это делают довольно редко и тому есть причины.
> и не ломая любую нетормозящую фс при потере питания - запускать по прерыанию завершение
> работы как с ибп компах.При cow-подобной логике она и так не сломается, недописанного просто никогда не существовало и будет чуть более старый вид.
И да, даже для записи настроек например имеет смысл так делать. Т.е. завести версию в блоке настроек и писывать их в несколько разных блоков, никогда не стирая все сразу. В хучшем случае поюзаются предыдущие, но так чтобы совсем и все слетело и девайсу фаталити - ну вот нет, это плохой план.
> Если именно хранить, именно в ней - то требует.чего хранить ? как была sdram так и остаётся, ниразу не видел чтобы на компах sdram на sram меняли после установки ИБП
> ионисторы - вариант, но это делают довольно редко и тому есть причины
абдуринщики не проектируют платы а берут готовые, им на лопате в ide фс подсунули они и рады
> При cow-подобной логике она и так не сломается
бэд появится и потеряешь данные, чудес не бывает, писать по кругу пропуская бэд-блоки и без фс можно внезапно
> чего хранить ? как была sdram так и остаётся, ниразу не видел
> чтобы на компах sdram на sram меняли после установки ИБПОднако, между нами, DRAM выжирает в случае лаптопа весьма жирный акум за пару недель к хренам. Т.е. аппетит у нее - весьма отличный от ноля. И уповать на только это - порой выходит боком.
>> ионисторы - вариант, но это делают довольно редко и тому есть причины
> абдуринщики не проектируют платы а берут готовые, им на лопате в ide фс подсунули они и радыПлаты с ионисторами не такая уж распостраненная категория. А я так то умею себе рисовать платы на STM32'ах, но все же скажу что ионисторы все же далеко не самая распостраненная или дешевая штука.
>> При cow-подобной логике она и так не сломается
> бэд появится и потеряешь данные, чудес не бывает,Вон то не делано под media с бэдами. И вон там FEC есть на такие случаи. Навесной. Рядом с сабжем в репе лежит.
> писать по кругу пропуская бэд-блоки и без фс можно внезапно
Или даже запилив себе FEC, внезапно... я так даже умею.
>> бэд появится и потеряешь данные, чудес не бывает,
> Вон то не делано под media с бэдами. И вон там FEC есть на такие случаи.
> Или даже запилив себе FEC, внезапно... я так даже умею.коды корреции отдельно от данных лежат в spare area и любой нормальный контроллер иcправляет ошибки аппартно без софтового колхоза, если ошибок много и их невозможно исправить данные потеряны а блок в таблицу бэдов отправляется
> коды корреции отдельно от данных лежат в spare area и любой нормальный
> контроллер иcправляет ошибки аппартно без софтового колхоза, если ошибок много и
> их невозможно исправить данные потеряны а блок в таблицу бэдов отправляетсяСабжеобразная штука - может применяться в более мелких штуках, где вон того просто нет. А еще - я в отличие от вас эти таблицы трогал руками. И вы удумали мне мастеркласс на тему давать?
Далеко не все и вся наворочено как SSD. А "холхоз" с софтовым FEC лежит - прямо по ссылкам новости.
> В каких-то случаях и ионисторы - вариант, но это делают довольно редко и тому есть причины.это довольно распространение решение
https://www.kingston.com/ru/blog/servers-and-data-centers/ss...
> это довольно распространение решение
> https://www.kingston.com/ru/blog/servers-and-data-centers/ss...По сравнению с чем? Нельзя быть распостраненным в сферическом вакууме. Если сравнить с например числом применений RAM и Flash - то ионисторы весьма редкий вид. Поэтому их не очень просто найти и на них не особо прикольные ценники, особенно если не брать вагонами. Специфичная деталюха. Намного более специфичная чем RAM/Flash сами по себе.
> ионисторы весьма редкий вид. Поэтому их не очень просто найти и на них не особо прикольные ценники, особенно если не брать вагонами.особенно если не искать а идти в ближайший чип и дип
https://aliexpress.ru/item/1005005496819248.html
> Выделение блоков осуществляется через сканирование ФС на предмет использованных блоков в области фиксированного размера, хранимой в виде битового вектора.Битовые вектора - сомнительная затея ещё со времён FAT. Особенно когда хранилища подрастут, а неуклюжая ФС всё ещё будет строить для них "битовые карты" размером с мегабайты. Которые ЕСТЕСТВЕННО будут постоянно перезатираться и один вылетевший блок махом уничтожит целую кучу данных.
Тут надо действовать умнее.И нет, ФС не должна заниматься "выравниванием износа"! Время дискеток прошло. Сейчас всё движется в сторону SSD, магнитные носители останутся в музеях. Ну или стриммерные ленты, но там вообще другая сфера.
>> когда хранилища подрастут, а неуклюжая ФС всё ещё будет строить для них "битовые
> карты"Чаще всего, да в мелких контроллерах, LittleFS используется с разделами всего 1-16 МЕГА байт.
Для этого применения всё нормально.
> всё движется в сторону SSDНу да, прицепить к каждому контроллеру за 100-200р ssd за 5-10 килорублей. У меня только в умном доме с огородом их за 30шт. ;)
Такой подход, с ssd,уместен для более толстых контроллеров, типа Распберри.
> за 100-200р ... У меня только в умном доме с огородом их за 30шт. ;)и чего там в фс хранится, сова на глобусе ?
> и чего там в фс хранится, сова на глобусе ?Да что угодно, как и на компе или более толстых контроллерах.
Если брать ESP32, то EEPROM у него нет, а есть флешка с крупными страницами.
Если на из каких то убеждений игнорировать файлы, и в лоб работать с флеш, то..
на каждом из контроллеров свои флешки, да и в рамках одного бывают разных типов, и на каждый чих придется писать обертки и "велосипеды", да и перенос кода не то что на Распбери, но и на другой контроллер выльется в напрасное переписывание кода.
Если данные хранить в RAW флеш, их надо туда как то записывать, и извлекать, а с файлами проще, из и закинуть элементарно, и доступны хоть через Веб интерфейс.
Так же с файлами безопаснее, невозможно как при RAW доступе к флеш, записывая один объект, переписать случайно и другой.
По сути, RAW доступ к флеш оправдан только для чего то типа баз данных.
> а с файлами проще, из и закинуть элементарно, и доступны хоть через Веб интерфейспонятно - ногой дёргать на абдурине через вебинтерфейс, просто прозвучали такие слова как "отказоустойчивость" я уже подумал вдруг не сова на глобусе, но чуда не случилось..
Вот, например, поливалки для цветов. Ардуинисты обычно тупо по датчику влажности льют воду.. на подоконник, в ботинок под окном, или всухую крутят моторчики. Итог таких поделок показан в Разрушителях легенд, растения погибли с таким поливалом.
А по нормальному. помимо контроля неисправностей и частичного резервирования есть еще режим полива, у разных растений разный, и зависит от температуры, влажности, и возраста растений, и времени года. Для парников
удаленный контроль и перенастройка из интернета обязательна, оно же должно работать когда я уехал.
> А по нормальному. помимо контроля неисправностей и частичного резервирования есть еще режим полива, у разных растений разный, и зависит от температуры, влажности, и возраста растений, и времени года.и зачем для этого 30 esp32 с wifi если есть LoRa-дачники которые от одной батарейки годами работают, а управлять можно одноплатником с Linux - это на порядок надежней чем сеть каких-то прыщеконтроллеров, в качестве бесперебойника ионистор а ФС и носитель на любой вкус.
> Вот, например, поливалки для цветов. Ардуинисты обычно тупо по датчику
> влажности льют воду.. на подоконник, в ботинок под окном, или всухую крутят моторчики.На минутку, даже копеечная китайская какаха у знакомого хомяка умеет детектить сухой ход, банально по току насоса. И как вы понимаете - я был бы тот еще дятел если бы не сделал так же.
> Итог таких поделок показан в Разрушителях легенд, растения погибли с таким поливалом.
Да вот знаете, в какой-то момент в такой штуке, если ее не мониторить, кончится вода - и все же изредка вмешательство человека - потребуется. Исключение разве что - если это колодец какой, но даже и там возможна ситуация когда - при каком-то неудачном раскладе, таки, все выкачали - и наступило обломинго.
> удаленный контроль и перенастройка из интернета обязательна, оно же должно
> работать когда я уехал.Тоже палка о 2 концах - ибо постоянно пялиться в это? А оно надо? Да и как вы проверите - сухо ли или льет ли на подогонник? Это надо кучу датчиков - и кучу проводов.
Если уж это тянуть - мне больше нравится идея автоматического адаптива, по показаниям уровня влажности хреначить. Впрчоем это совсем не мешает скажем сообщить что воды мало осталось. И тут совсем без мониторинга тоже такое себе. Правда для себя я МКшками по "простому радиоканалу" на линуховый девайс скидываю. Там можно сделать нормальную сеть, а не пародию на оную. И морду - тоже.
> Ну да, прицепить к каждому контроллеру за 100-200р ssd за 5-10 килорублей.
> У меня только в умном доме с огородом их за 30шт.Если уж хочется странного - SD/uSD карточки умеют SPI режим, так что даже контроллер SD (или ногодрыг GPIO) не потребуется если хардварный SPI есть. Это может стоить заметно меньше.
Так это и есть улучшенный fat, для ембедовки. Заменять этим ext4 никто и не предлагает.
У сабжа ничего общего с FAT нет.
Извини, но магниторезистивная память (SOTA-вариант называется FRAM) - это как раз будущее. Почти без износа, и ОЧЕНЬ быстрая. Просто её ещё не научились специально делать так, чтобы она таки изнашивалась. И рынок флаша ещё не дочерпали. Как скотину фтранзисторами с плавающим затвором додоят до стенки - вот тогда и будет массовая магнеторезистивная память.
> Извини, но магниторезистивная память (SOTA-вариант называется FRAM) - это как раз будущее.
> Почти без износа, и ОЧЕНЬ быстрая. Просто её ещё не научились
> специально делать так, чтобы она таки изнашивалась. И рынок флаша ещё
> не дочерпали. Как скотину фтранзисторами с плавающим затвором додоят до стенки
> - вот тогда и будет массовая магнеторезистивная память.Не, просто технология малоемкая, не отлаженная. Ну ее и производят пока только для специфичных применений, типа замены EEPROMок и тому подобного - емкостью килобайты...мегабайты.
К тому же у FRAM еще и чтение деструктивное бывает. И если при ЧТЕНИИ слетит питание ... таки можно про@#$ть данные. Эвоно оно как, михалыч.
cow - это хорошо, но как бороться с отключением питания ровно после операции очистки блока с метаданными(участка фс в котором инфа о используемых блоках), до записи туда новых данных? Или здесь два таких блока и очистка сразу двух невозможна?
> cow - это хорошо, но как бороться с отключением питания ровно после
> операции очистки блока с метаданнымиНапример CoW'ать и метаданные тоже! Т.е. запись данных в сторону -> апдейт "указателей" в метаданных -> запись апдейтнутой версии, тоже вбок. Если что-то из этого не прокатило - не судьба, логика будет видеть старое состояние, взяв в том числе и старую версию метаданных, в котторой того апдейта "указателей" на данные еще не было.
> (участка фс в котором инфа о используемых блоках),
А кто сказал что и с этим добром нельзя подобные вещи проворачивать, по тем же причинам?
Если всё cow, то как понять где читать нужный первый блок? Сканить всё на предмет "начального"(по сигнатуре), и если их два, то выбирать тот, что новее?
> Если всё cow, то как понять где читать нужный первый блок?
> Сканить всё на предмет "начального"(по сигнатуре), и если их два, т
> о выбирать тот, что новее?Есть много разных вариантов как это делать. Например - http://www.bzero.se/ldapd/btree.html
Это больше для БД - но идею как расплющить дерево и сделать его cow - и даже шариться по сразу нескольким версиям, если хочется, показывает.
Ах да, catch? В какой-то момент вамв в такой штуке все же захочется GC, почему-то :-)
Есть ext4, которая достаточно отказоустойчивая. А это какое-то reinventing the wheel. Не нужно.
> Есть ext4, которая достаточно отказоустойчивая. А это какое-то reinventing the wheel. Не нужно.Да, у меня как-то на одном из девайсов - вылез единичный случайный бэд под EXT4. К сожалению, он вылез - под libc6. И я смог ощутить всю отказоустойчивость этой штуки от души - когда управляющий одноплатник резко, внезапно и без предупреждения стал тыквой.
В чем проблема? В том что резко и внезапно подрываться чинить это в темпе вальса - было ну совсем не прикольно. Такая вот отказоустойчивость EXT4 на практике, если закинуть необслуживаемую железку в перди, рулить процессами.
С тех пор я люблю btrfs с схемой DUP, хорошо справляется с такими подарками.
> С тех пор я люблю btrfs с схемой DUP, хорошо справляется с такими подарками.что-то я не вижу в описании littlefs что она делает копии данных и может восстанавливать повреждённые
>> С тех пор я люблю btrfs с схемой DUP, хорошо справляется с такими подарками.
> что-то я не вижу в описании littlefs что она делает копии данных
> и может восстанавливать повреждённыеОна и не сватается для SD/eMMC из относительно хлипкого нанда при относительно высокой емкости где это актуально. Для мелкого NOR вполне себе нормально переживать сотни тысяч циклов без факапов. И хранить данные дофига. Там единичный сбой - исключение, а не правило как в NAND который прям с фабы - с дефектлистом уходит.
Так, блин, смотрим в книгу - видим фигу!
Добавлены два новых примера блочных устройств ramcrc32bd и ramrsbd, в которых реализован механизм коррекции ошибок, совместимый с LittleFS. В текущем виде в самой ФС LittleFS отсутствует поддержка определения и коррекции ошибок, и данные операции выносятся на уровень блочных устройств.