О да, хвалёная надёжная-как-скала ext4 😁

Какую ФС с какими параметрами посоветует ЛОР

btrfs + flushoncommit

можешь ещё dup включить для данных и метаданных для пущей параноидальности

Log-structured FS на развчасные данные, остальное в R/O и забэкапленное.

никогда не было проблем с ext3/ext4 при подобных ситуациях. опции монтирования во fstab?

btrfs

если ext4 накрывается есть шансы вытащить файло, чего не скажешь про btrfs.

4.2, btrfs restore

Спасибо, так и сделал. Завтра погоняю под ребутами.

никогда не было проблем с ext3/ext4 при подобных ситуациях. опции монтирования во fstab?

Дефолтные.

Хотя впрочем оно и не удивительно.

если ext4 накрывается есть шансы вытащить файло, чего не скажешь про btrfs.

Ну скажем так, мое файло не настолько важное чтоб его «вытаскивать», это просто стата энергопотребления почасово. Если оно наипнется, всего лишь будет намотано меньше киловатт.

Но вот эти глюки когда ОС не может загрузиться после внезапного ребута, уже честно говоря на Малине достали. Мы в 2021 году живем, а ведем себя как Винда в 95м.

Проблема не в «восстановлении» а в том что во время «восстановления» не работает освещение на улице, бойлер, конвекторы, логгинг энергопотребления. Все никак не доходят руки сделать по человечески.

я хз что там в «малинке», ext3/ext4 неоднократно ронялись, более того, я видел как живет ext4 на умирающем винте, и при этом всем она еще и выживает, не без ручных вмешательств с fsck.

может огласите опции монтирования во fstab?

PARTUUID=9730496b-01 /boot vfat defaults 0 2

PARTUUID=9730496b-02 / ext4 defaults,noatime 0 1

хм, странно, pass 1 стоит, должен прочекать/исправить

Вопрос другого плана: состояние памяти? а то был тут с годик назад один товарищ, винил во всем ФС, пока не выяснилось, что у него винт мрет.

Есть стойкое ощущение, что проблема может быть связана с SD-картой. Возможно, она портит свои внутренние структуры данных при потере напряжения. Я бы попробовал другую.

Перевел полтора года назад свою малинку на F2FS, чтобы поменьше беспокоиться об износе - уже был случай, когда карта внезапно переставала работать. В этом году во время ремонта регулярно пропадал свет, плюс блок питания начал барахлить. Система по сей день работает хорошо, никаких проблем не замечал.

artyom@rpi ~> sudo journalctl | grep -- "-- Reboot --" | wc -l
18318

кстати, f2fs пригодно для / на подобном эмбедеде?

rootfs содержит кучу фейлонутых инодов,

ext3/4 я полагаю?
Надо было форматировать в btrfs с metadata=dub и раскидать rootfs по разным субтомам.

Есть стойкое ощущение, что проблема может быть связана с SD-картой. Возможно, она портит свои внутренние структуры данных при потере напряжения.

Или при перегреве, а потеря напряжения просто даёт толчёк расстройству.

кстати, f2fs пригодно для / на подобном эмбедеде?

Учитывая то, что для / и btrfs хорош, имхо лучше подождать пока f2fs не пройдёт стабилизацию и несколько отловов ошибок.

(Сам я f2fs не пробовал, но когда нибудь потом попробую)

Вопрос другого плана: состояние памяти? а то был тут с годик назад один товарищ, винил во всем ФС, пока не выяснилось, что у него винт мрет.

Состояние памяти - отличное. Сей баг был не один раз, не на одной малине, и не на одной microSD.

Ну и знаешь ли, ДО ребута все работает норм, включая ребуты с sync, а после внезапного ребута, все поломалось …

Проблема не в «восстановлении» а в том что во время «восстановления» не работает освещение на улице, бойлер, конвекторы, логгинг энергопотребления.

А может, просто купить бесперебойник к Raspberry Pi? Вроде есть такие.

Но как, черт побери???! Я малинку и в хвост и в гриву, reset ей многократно делаю для проверки, хоть бы хны, железобетонна и стабильна (на debian10, на 11 никак не перейду) У тебя microsd или usb?

ext3/4 я полагаю? Надо было форматировать в btrfs с metadata=dub и раскидать rootfs по разным субтомам.

Пользуюсь вроде как «официальным дистрибутивом», просто накатывая их образ на карту. Странно что за много лет существования проблемы (гуглится по q=raspberry pi corrupted file system) они это не починили.

потеря напряжения просто даёт толчёк расстройству.

От «толчека расстройства» очень сильно посмеялся.

btrfs

Она уже спасает, если сам накопитель с ума сошёл? Ну там, часть erase-блоков обнулилась, часть переставилась местами, часть получила случайные данные. Потому что microsd-карточки это не SSD. Там производители, похоже, вообще не особо заморачиваются с сохранностью данных при внезапных отключениях.

А может, просто купить бесперебойник к Raspberry Pi? Вроде есть такие.

Это временная постоянная система, хе. Вообще by design в ней стоят аккумуляторы и несколько 12В источников питания, просто в этот раз эти детали перекочевали ближе к машине ввиду отсутствия у меня зарядки для автоаккумулятора и того что последний аккумулятор я купил дерьмище, посему вожу с собой два.

Запланировал себе небольшой шкаф-стойку под эти дела, потом похвастаюсь. Уже купил сварку, научился варить, купил болгарку, научился пилить. Осталось выделить время, купить пару металлопрофилей и начать химичить.

Так что временно это все.

Но как, черт побери???! Я малинку и в хвост и в гриву, reset ей многократно делаю для проверки, хоть бы хны, железобетонна и стабильна (на debian10, на 11 никак не перейду) У тебя microsd или usb?

https://www.google.com/search?q=raspberry+pi+corrupted+file+system

Нерепрезентативно, сорян. Хомякоз неистребим, особенно в хомячных одноплатниках.

Ну там, часть erase-блоков обнулилась, часть переставилась местами, часть получила случайные данные. Потому что microsd-карточки это не SSD. Там производители, похоже, вообще не особо заморачиваются с сохранностью данных при внезапных отключениях.

Когда у меня сегодня это случилось, я снял карточку, подключил к стационарному компу.

Первое что мне выдалось - невозможно примонитировать rootfs, bad system type or corrupted data, or чото там еще.

Запустил fsck на первый раздел, vfat - он мне написал детально уже не помню что, что-то типа про разные копии таблицы и спросил, скопировать оригинальную в бэкап, или из бэкапа в оригинальную.

Второй раздел был больше на один блок, чем физический. Это я подправил. Затем fsck понаходил там и коцнутые иноды, и еще пару десятков непонятных мне вещей, которые успешно пофиксил. Но увы.

Нерепрезентативно, сорян. Хомякоз неистребим, особенно в хомячных одноплатниках.

Та это понятно. Но тем не менее проблема присутствует, и не только у меня. И собственно она не появляется на пустом месте из-за каких-то «ССЗБ». Купил официальную малинку, к ней рекомендуемую ими флешку, на нее накатил образ ОС с их официального вебсайта.

Вот в чем вся соль. Я бы разбирался сам, если бы например ставил Арч, или костылил загрузку с USB носителя, или какой-нить SPI-флешки припаянной ПОС-60м. Но здесь тот случай когда все делалось step-by-step

Купил официальную малинку, к ней рекомендуемую ими флешку, на нее накатил образ ОС с их официального вебсайта.

Ну ты все сделал не так… Если часто пишешь в карту (я уже писал тебе), надо карту endurance (хотя у меня обычная и в ro), официальный образ заточен на декстоп и кривоват, ставь debian11.

Ну там, часть erase-блоков обнулилась, часть переставилась местами, часть получила случайные данные. Потому что microsd-карточки это не SSD. Там производители, похоже, вообще

Ну так метадата то в dup, да и данные в dup можно.

Ещё можно попробовать включить кфшв5 и распределить данные по трём разделам, но я с этим не эксперементировал, так что как будет работать не знаю.

рутфс в r/o

Я ленивый, поэтому использую Ubuntu Core — там уже из коробки

https://ubuntu.com/core/docs/uc20/storage-layout

ext3/ext4 неоднократно ронялись...и при этом всем она еще и выживает

Присоединяюсь. В частности есть три десятка компов с ext3 где хард ребут устраивают чуть ли не ежедневно, система робит второй десяток лет.

Живучесть фс зависит от адекватности диска. Компьютерные диски в большинстве своём адекватны, даже ссд. А сд карты не адекватны и при выключении там может происходить что угодно. Плюс в компьютерах блок питания даёт ток с конденсаторов несколько миллисекунд и сигнал об отключении, это тоже даёт диску время на запись чего-нибудь. А без всего этого развалится любая фс. По-хорошему нужен конденсатор на входе, какие-то сигнальные прерывания в ОС и код, который тупо будет отмонтировать сд карту и выключать процессор.

лол нет!

По-хорошему нужен конденсатор на входе, какие-то сигнальные прерывания в ОС и код, который тупо будет отмонтировать сд карту и выключать процессор.

журналирование фс, не слышал?

правда по дефолту в ляликсе оно считай что и не включено толком.

а загружался б в tmpfs, такой проблемы б не возникло.

данные об энергопотреблении мог бы отправлять на удалённый сервер.

кто при объёме памяти >1гб в 2к21 году всё ещё пользуется устаревшими ФС на накопителях?

Давно бы собрал FreeBSD для Raspberry PI и использовал отказоустойчивую UFS2+SU.

Как уже говорили выше, может карточке кранты. У меня было так же с Cubietruck и SD картой.

А от такого вообще хоть что-нибудь спасает?

Научитесь уже настраивать файловую систему. Хотя бы про «data=» прочитайте. https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

ФС тут не при чём. SD-карты это ненадёжный носитель, особенно дешёвые карточки.

btrfs + flushoncommit

Нда, это вместо сахарного домика советовать домик из говна

/boot vfat

Ну-ну, конечно ext4 виновата

Есть стойкое ощущение, что проблема может быть связана с SD-картой.

Чаще всего

Как уже говорили выше, может карточке кранты. У меня было так же с Cubietruck и SD картой.

Карточке однозначно не кранты. Все работало до перезапуска, dmesg был здоров. Все работало с перезапусками после sync. И все работает после переустановки. Хотя конечно проблема может быть карто-специфична.

ФС тут не при чём. SD-карты это ненадёжный носитель, особенно дешёвые карточки.

Вот мне и интересно, в чем «ненадежность», учитывая что по поверхности все пучком, да и собственно фейлится оно после внезапного ребута, а не запланированного. Карта ведь не первая и не последняя. Как и Малина. Да и есть устройства, к примеру регик, которые на тех же самых картах (но в fat32, да) работают чуть ли не годами.

Ну-ну, конечно ext4 виновата

Да. Потому что /boot раздел не используется на запись, ломаться там нечему. Я ж писал выше, что потерянные иноды были на разделе ext4

Да. Потому что /boot раздел не используется на запись, ломаться там нечему.

Действительно, поэтому в boot лежит ядро которое не загружается потому что там же нечему ломаться

Я ж писал выше, что потерянные иноды были на разделе ext4

«Потерянные ноды» если долбить питание есть почти на любой fs. На любой которой я когда-либо пользовался.

fat/ntfs/ext2-3-4/apfs/ufs/zfs

Не сомневался в тебе, пеши ысчо ;)

не понимаю почему все продолжают разводить срачь если очевидно что выбор должен быть за tmpfs

Из моей практики: если дергать питание, то фс на карточке быстро накрывается, если вместо карточки грузиться с харда, то фс тоже может накрыться, но хотя бы восстанавливается штатными средствами.

завязать весь дом на одну плату без возможности ручного управления - элитное ССЗБ