我有一个回送设备格式化的ext4（^ has_journal，禁用日记）。
在关机期间，当我尝试强制重新挂载为只读时，挂载的文件系统被回送。 echo“u”> / proc / sysrq-trigger
在重新装入ext4_da_writepages后，我看到这些ext4错误：jbd2_start：8192页，ino 130135; err -30
（错误30是-EROFS，由于回写到只读文件系统而导致错误）。 作为remount的一部分，我看到linux调用invalidate_bdev（），我猜不应该让任何回写发生。 不知道为什么我看到这些错误。
当我将环回设备格式化为vfat时，我看不到任何错误。
任何帮助表示赞赏。
谢谢
这是因为sysrq触发器只是紧急情况，并没有很多（任何）智能。
查看内核源代码，在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（为什么？），那么你可以尝试让内核看到你想要的顺序（如果这是可能的，我没有看到那么深）或修改内核从倒数第一（而不是倒数第一）开始进行sorting。 这可能不是完美的（也许对于一些更复杂的设置也是错误的），但是在大多数情况下（如果不是全部的话）比当前的解决scheme更好。 如果你试图推动它，甚至可能进入主线内核，因为在那个特定的地方行走那个特定的列表并不是性能关键的，所以caching未命中行为等等不是问题。
顺便说一句，你没有看到VFAT的错误（如果它最近没有被修改），因为VFAT（由于其简单）不需要在umount上写修改的超级块回磁盘。