☰

尽管配置是读/写，ext4 磁盘如何突然被写保护？

tag-icon • tag-icon linux rhel mount fstab disk
尽管配置是读/写，ext4 磁盘如何突然被写保护？

我们有一台 Redhat 7 机器。设备的文件系统/dev/sdc是ext4。

当我们执行：

mount -o rw,remount /grop/sdc

我们收到写保护错误，例如：

/dev/sdc read-write, is write-protected

尽管/etc/fstab允许读取和写入，并且其下的所有子文件夹都/grop/sdc具有完全的写入/读取权限：

/dev/sdc /grop/sdc ext4 defaults,noatime 0 0

然后我们就做

umount -l  /grop/sdc

从 中df -h，我们看到磁盘当前尚未安装。

然后我们执行

 mount /grop/sdc

但我们很忙。 :-(

所以我们别无选择，只能重新启动。

从历史上看，我们没有看到有人通过挂载将磁盘限制为只读。

这就很奇怪了，磁盘设备怎么变成写保护了？

为了解决这个问题，我们执行完全重新启动，现在磁盘已恢复写读本来应该如此。

这里发生了什么，重新启动后我们检查 dmesg，我们看到以下内容：

 EXT4-fs warning (device sdc): ext4_clear_journal_err:4698: Marking fs in need of filesystem check.
 EXT4-fs (sdc): warning: mounting fs with errors, running e2fsck is recommended
 EXT4-fs (sdc): recovery complete

我们可以说在启动期间执行了 e2fsck 吗？

dmesg | grep sdc
[sdc] Disabling DIF Type 2 protection
[sdc] 15628053168 512-byte logical blocks: (8.00 TB/7.27 TiB)
[sdc] 4096-byte physical blocks
[sdc] Write Protect is off
[sdc] Mode Sense: d7 00 10 08
[sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdc: unknown partition table
[sdc] Attached SCSI disk
EXT4-fs warning (device sdc): ext4_clear_journal_err:4697: Filesystem error 
 recorded from previous mount: IO failure
EXT4-fs warning (device sdc): ext4_clear_journal_err:4698: Marking fs in 
need of filesystem check.
EXT4-fs (sdc): warning: mounting fs with errors, running e2fsck is recommended
 EXT4-fs (sdc): recovery complete
 EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null)
 EXT4-fs (sdc): error count since last fsck: 5
 EXT4-fs (sdc): initial error at time 1510277668: ext4_journal_check_start:56
 EXT4-fs (sdc): last error at time 1510496990: ext4_put_super:791

答案1

您的文件系统似乎已损坏。大多数文件系统一旦遇到错误就会切换到只读模式。请在终端中执行以下命令：

umount /dev/sdc
e2fsck /dev/sdc
mount /dev/sdc

如果 /dev/sdc 是装有操作系统的硬盘，请使用启动 DVD 或 USB 记忆棒进行启动。

答案2

错误的原因很可能是过去的。您应该检查系统日志中与正在使用的块设备相关的消息。最近的工具（例如dumpe2fs）甚至可以显示发生错误的时间，如下所示：

dumpe2fs 1.43.8 (1-Jan-2018)
Filesystem state: clean with errors
Errors behavior: Continue
FS Error count: 5
First error time: Mon Nov 1 00:22:11 2021
First error function: ext4_journal_check_start
First error line #: 60
First error inode #: 0
First error block #: 0
Last error time: Tue Nov 2 10:45:47 2021
Last error function: ext4_remount
Last error line #: 5175
Last error inode #: 0
Last error block #: 0

因此，时间戳将为您提供查看日志的良好间隔。

（对于所示的情况，它是稀疏文件的循环安装，并且底层容器文件系统已满）

相关内容