ext4 переносит просто выключение норм ?

sync в crontab на 5мин запхни.

Любую в R/O.

Обычно откатывает журнал и прибивает потерянные куски данных. Ну у меня на ФС нагрузка максимум торрентами.

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

USB-дисках при недостаточном питании.

Это вообще такая такая штука ненадежная, эти usb диски, даже с внешним бп… Походу, в ноутбуках USB-подсистема говно, потому что больше всего проблем при подключении к ноутам. На удивление, RPi3 имеет стабильный USB коннект к диску. Но лишь usb2.0.

Понимаю что оффтоп. У меня ext4 последний раз немного ломалась в 2012 наверно, завис ноут, после ребута раздел не виделся. Но вынимание и fsck диска на другой машине проблему решил.

Да вполне.

Но если это система на ней, то обязательно надо смотреть на то, чтобы в фоне обновления не ставились. Если во время этого бабахнет, то веселье обеспечено.

RPi3 имеет стабильный USB коннект к диску

Попробуй одновременно подключить клавиатуру, например. Там очень тухлое питание, как в ноутбуках наверно.

рекомендую засунуть систему в squashfs и держать её в tmpfs.

mkinitramfs `mktemp -d` --overlay /mnt --squashfs-xz --output /boot/initrd

где /mnt это корневой раздел с системой, на выходе получишь initrd готовый к загрузке

положи рядом с vmlinuz.

добавь initrd /boot/initrd в загрузчик. всё.

теперь ядро будет грузить систему не с жёсткого диска, а с initrd, в котором система в squashfs упакована.

1. Сама фс не разваливается, нормально монтируется.

2. Случаи обнаружения в файлах испорченных по вине ext4 мусора или хотя-бы нулей (привет xfs) мне не известны. Хотя наверное можно настроить так чтобы данные бились (барьеры, журнал вырубить и другие «оптимизации» от умельцев)

3. Гарантировать, что новые файлы не окажутся недописанными естественно нельзя.

4. За аппаратные глюки и особенности фс ответственности не несёт.

Лучше использование файловой системы, доступной только на чтение, а запись в tmpfs.

синхронную запись включи и будет болие-лимение

в зависимости от настроек

data=journal is the safest way of writing data to disk. Since all data and metadata are written to the journal before being written to disk, you can always replay interrupted I/O jobs in the case of a crash. It also disables the delayed allocation feature, which may lead to data loss.

The 3 modes are presented in order of safeness in the manual:

    data=journal
    data=ordered
    data=writeback

There's also another option which may interest you:

commit=nrsec    (*) Ext4 can be told to sync all its data and metadata
                    every 'nrsec' seconds. The default value is 5 seconds.

Нет. В ro все равно происходит запись на диск.

Если это «роутер» или что-то такое то фат32 с образом ос. Образ грузиш грабом в оперативку и можно отмонтировать диск... А так ext4 довольно надёжная, но никто гарантии не даст... Невозможно предвидеть все исключительные ситуации.

Данные пиши на отдельный раздел

Главное чтобы в журнал не попало что-то чего разрабы не ожидают там увидеть...

В ro все равно происходит запись на диск.

Опять конь в вакууме?

Если вы про фс как таковую. То переносит норм, есть многолетний опыт. Если про данные которые могут в тот момент писаться на fs тут уже может быть проблема с конкретными файлами но от этого ни одна fs не застрахована.

у меня ни разу не было проблем с ext4 при экстренном отрубании питания. несколько раз были проблемы с jfs, когда после отрубания питания менялись разрешения прав корня раздела