У меня есть устройство обратной связи, отформатированное с помощью ext4 (^ has_journal, отключенное ведение журнала).
Во время выключения, когда я пытаюсь принудительно перемонтировать как доступную только для чтения, файловая система смонтирована с обратной связью. эхо "и"> / proc / sysrq-trigger
Я вижу эти ошибки ext4 после перемонтирования ext4_da_writepages: jbd2_start: 8192 страницы, ino 130135; err -30
(err 30 - -EROFS, ошибка из-за обратной записи в файловую систему только для чтения). Как часть перемонтирования, я вижу, что linux вызывает invalidate_bdev (), что, как я полагаю, не должно допускать обратной записи. Не знаю, почему я вижу эти ошибки.
Я не вижу ошибок, когда форматирую устройство loopback как vfat.
Любая помощь приветствуется.
Спасибо
Это потому, что sysrq-trigger работает только в аварийных ситуациях и не имеет большого (какого-либо) интеллекта.
Глядя в исходный код ядра, на fs / super.c: do_emergency_remount (), кажется, что он будет перемонтировать файловые системы только для чтения в порядке их порядка в списке (который такой же, как вы видите, например, когда вы выполняете "cat / proc / mounts") . Это прискорбно, так как он, скорее всего, сначала перемонтирует вашу родительскую файловую систему только для чтения, а затем попытается отключить файловую систему loopback, что вызовет запись (суперблока и любых оставшихся измененных данных / метаданных) в родительскую файловую систему, которая уже доступна только для чтения, и, следовательно, не работает с -EROFS.
Решение заключается в использовании обычных инструментов для размонтирования и повторного монтирования R / O вместо sysrq-trigger, например, используя:
umount -a
(который размонтирует все, что может, и перемонтирует rootfs R / O)
Или запустить вручную в правильном порядке:
mount -oremount,ro /dev/xxx
Если вам нужно использовать / proc / sysrq-trigger (почему?), Вы можете либо попытаться заставить ядро видеть нужный вам порядок (если это вообще возможно, я не смотрел так глубоко), либо изменить ядро на делайте заказ от последнего к первому (а не от первого к последнему). Возможно, это не идеально (возможно, для некоторых более сложных настроек это тоже было бы неправильно), но в большинстве (если не во всех) случаях оно было бы лучше, чем текущее решение. Я бы рискнул, что он может даже попасть в основное ядро, если вы попытаетесь его протолкнуть, так как перемещение по этому конкретному списку в этом конкретном месте не критично для производительности, поэтому промахи в кеше и т. Д. Из-за перемещения списка назад не являются проблемой.
Кстати, вы не видите ошибок для VFAT (если он не был изменен в последнее время), потому что VFAT (из-за его простоты) не нуждается в записи измененного суперблока при размонтировании обратно на диск.