Linux，暂时崩溃后如何从ReadOnly更改HDD状态？

17

目前，您对此问题一无所获。

通常，在对块设备进行读取或写入问题后，内核决定将“整个设备”的标志切换为只读。此后，对此设备上任何分区/文件系统的任何写入都会导致将其与设备状态一起切换为只读状态，因为无法进行任何写入。

dmesg的示例，这是碎片整理获取来宾设备映像时使用VirtualBox在Windows8上对来宾linux进行的仿真：

[11903.002030] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11903.003179] ata3.00: failed command: READ FPDMA QUEUED
[11903.003364] ata3.00: cmd 60/08:00:a8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11903.003385]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11903.004074] ata3.00: status: { DRDY }
[11903.004248] ata3: hard resetting link
[11903.325703] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11903.327097] ata3.00: configured for UDMA/133
[11903.328025] ata3.00: device reported invalid CHS sector 0
[11903.329664] ata3: EH complete
[11941.000472] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[11941.000769] ata3.00: failed command: READ FPDMA QUEUED
[11941.000952] ata3.00: cmd 60/08:00:c8:77:57/00:00:00:00:00/40 tag 0 ncq 4096 in
[11941.000961]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[11941.001353] ata3.00: status: { DRDY }
[11941.001504] ata3: hard resetting link
[11941.320297] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[11941.321252] ata3.00: configured for UDMA/133
[11941.321379] ata3.00: device reported invalid CHS sector 0
[11941.321553] ata3: EH complete
[11980.001746] ata3.00: exception Emask 0x0 SAct 0x11fff SErr 0x0 action 0x6 frozen
[11980.002070] ata3.00: failed command: WRITE FPDMA QUEUED
[11980.002255] ata3.00: cmd 61/18:00:28:23:59/00:00:00:00:00/40 tag 0 ncq 12288 out
[11980.002265]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
-------------------
There are many other errors, like "lost write page", "Journal has aborted", "Buffer I/O error", "hard resetting link" and many others.

之后，重新安装原因：

mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected

因为保留rootfs sda1的整个设备sda是READONLY。

以我的经验，这是在以下情况下发生的：

硬盘确实损坏。返回的写入问题取决于硬盘条件
主机超载，然后linux guest虚拟机虚拟硬盘写入超时
FC电缆或SAN设备（光纤通道上的阵列磁盘）超载
通过FC或FCoE暂时失去了连接。FC数据包可能丢失/超时

在这种情况下，设备实际上是可读写的，但是linux内核在内部将该设备标记为只读，并用作只读。这是为防止损坏而设计的内核功能，但仅在1.点可用。

问题是。如何手动告诉内核，硬盘块设备正常运行？

取消此操作后，内核会将设备作为只读设备，例如“ CD-ROM”，并且没有其他命令可以正常工作，包括mount / remount -o read-write，fsck等。

无法使用的邮件，确实是想要帮助但对问题性质不了解的人的垃圾邮件资格：

尝试重新安装为可读写（不可能，设备为RO）

fsck this（用于什么目的的设备是RO，无法修复）

“我不知道”（首先有道理，但无法使用）

“替换设备” *（通常是其他问题）

有没有人要问以上问题的公式？将可写块设备从只读状态恢复到可读写状态的开关标志？这时似乎没人知道怎么做。

这是一些解决方法，但通常是半可用或不可用的：

删除模块支持访问指定的硬盘或存储阵列。不幸的是，通常损坏的设备保留rootfs，或者驱动程序同时保留损坏的设备和保留rootfs的设备
删除FC对设备的访问权，然后再次加入（fctools），这是不可能的，并非总是可行的。
重新启动整个机器。通常，这总是可能的，而我们总是被迫这样做。

在第1点和第2点，我们告诉内核我们完全断开了设备的连接并再次连接到它。内核将其识别为已加入新的正常运行的设备。我们可以使用USB设备模拟此情况并暂时断开电源。第三点是最后一次机会，通常可以奏效。但是，为什么我们应该重新启动所有？不幸的是，我们在所有方面都丢失了所有日志更新和脏缓冲区。

请注意，在相同情况下，Windows（台式机和服务器）没有问题。

linux readonly mount

— 兹尼克
source

这不是一个答案，但可能与＃2（主机负载高，来宾硬盘超时）有关：增加Linux硬盘超时以防止由来宾系统硬盘超时引起的文件系统损坏。

— basic6

@Znik，这些来宾虚拟机是否在Citrix XenServer上运行？还是物理硬件？我们的StorageServer是从以太网到小型sas的桥梁。当此桥接计算机出现紧急情况时，必须强制重新启动它。Windows来宾VM回来了。Linux来宾虚拟机也存在与您完全相同的问题。这里没有建议将安装点恢复为rw。

— rjt

@rjt，这在许多情况下都会发生。主要情况是设备出现任何问题（例如物理损坏，设备过载，电缆连接，Eth和eth上的外部FC过载）极端减速，有时在传输块，超时，丢包等情况下切换复位。设备通常仍然可见，但标记为只读。重新启动不是解决方案，而是如我在主要问题/问题描述中所述的解决方法。

— Znik

12

尝试blockdev --setrw或hdparm -r 0

— 何塞·路易斯·马丁
source

谢谢，这应该是有用的。我正在等待fc控制器上的任何超时

— Znik，

需要添加的重要部分：有时必须fsck在只读文件系统上执行，然后才能再次挂载它。

— Evi1M4chine

3

Diddnt为我工作。我有类似的问题

— jonneymendoza

1

即使使用fsck也不适合我。Citrix XenServer Linux来宾。

— rjt

不起作用！该命令似乎有效，但是加密狗仍然是RO。（它是软件，但是从哪里来的？？？）如果您想尝试，请使用任何Debian iso 9.4。

— 桑德堡

5

就像何塞·路易斯·马丁建议使用blockdev一样，我的2cent是重新安装rw和forcefsck

（假设sda是您的磁盘）

blockdev --setrw /dev/sda
mount /dev/sda -o remount,rw
touch /forcefsck

— 罗伯托
source

1

仅在fsck之前运行会更有意义mount，因为如果没有，它将无法安装fsck。（至少在我看来是这样。）

— Evi1M4chine

`＃blockdev --setrw / dev / xvda1＃＃touch / tmp / date +%Y%m%d-%H%M%Stouch：无法触摸？/ tmp / 20170722-221904 ?:只读文件系统＃＃mount -o remount，rw / dev / xvda1 [137010.709883] EXT4 -fs错误（设备xvda1）：ext4_remount：4824：被用户挂起中止：无法重新挂载块设备/ dev / xvda1读写，处于写保护状态

— rjt

2

检查此Wiki页面，它解释了libata引发的错误：

https://ata.wiki.kernel.org/index.php/Libata_error_messages

从我上面看到的，您遇到了超时问题，并且根据提到的文档：

控制器无法响应活动的ATA命令。这可能是多种原因造成的。通常，这是由于不相关的中断子系统错误（尝试使用“ pci = nomsi”或“ acpi = off”或“ noapic”引导），当我们期望从硬件获得中断时，该中断未能传递中断。

您可能要禁用ACPI（检查基于发行版的方式）或检查内核中是否存在已知错误，如果不是最新版本，则可能对其进行更新（或降级）。

— UnX
source

是的，这确实是超时。通常，当阵列设备过载时，这会在FC控制器上发生。没错，在本地ATA子系统上，这通常是任何硬件错误或驱动程序/芯片组实现

— Znik

这是超时时间吗？好吧，怎么sudo hdparm -I /dev/sdX | grep locked说呢？它必须说：“未锁定”。每当硬盘被ATA密码锁定时，它就会显示这些神秘的超时（由于先前的安全性擦除和后来的系统崩溃导致安全性pw不再被清除）。密码的确对您的神经产生了巨大的影响。多年来，无数簇毛的罪魁祸首。

— 2014年

1

在Windows 10中重新启动，转到电源选项，然后关闭快速关机。然后重新启动到Linux ..gbamm一切都很好。

Windows 10中的快速关机会休眠一些文件，并且部分使用了驱动器。所以linux觉得很忙。

— 唤醒
source