儘管配置是讀/寫的，但 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

看來您的文件系統已以某種方式損壞。大多數文件系統一旦遇到錯誤就會切換到只讀模式。請在終端中執行以下命令：

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

如果 /dev/sdc 是安裝了您的作業系統的硬碟，請使用啟動 DVD 或 USB 記憶棒從其啟動。

錯誤的原因很可能是在過去。您應該檢查系統日誌以獲取與正在使用的塊設備相關的消息。最近的工具（例如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

因此，時間戳將為您提供一個很好的時間間隔來查看日誌。

（對於顯示的情況，它是稀疏文件的循環掛載，並且底層容器文件系統已滿）

引用自：https://unix.stackexchange.com/questions/404019