Linux, comment changer l'état du disque dur de ReadOnly après un crash temporaire?

Pour le moment, aucun ansver pour ce problème.

Habituellement, après quelques problèmes avec les lectures ou les écritures pour bloquer le périphérique, le noyau décide de changer l'indicateur pour WHOLE DEVICE en lecture seule. Après cela, tout écrit sur n'importe quelle partition / système de fichiers situé sur ce périphérique provoque le basculement en lecture seule avec l'état du périphérique, car tout écrit est impossible.

Exemple de dmesg, il s'agit d'une simulation pour linux invité sur windows8 utilisant VirtualBox lorsque la défragmentation prend l'image du périphérique invités:

[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.

Après cela, remontez la cause:

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

parce que tout le périphérique sda ​​gardant rootfs sda1 est en lecture seule.

D'après mon expérience, cela se produit dans des situations:

1. Le disque dur est vraiment endommagé. Les problèmes d'écriture retournés dépendent de l'état du disque dur
2. La machine hôte est surchargée, puis les écritures du disque dur virtuel invité Linux sont expirées
3. Le câble FC ou le périphérique SAN (disques de matrice sur Fibre Channel) est surchargé
4. Connexion momentanément perdue sur FC ou FCoE. Peut-être un paquet FC perdu / expiré

Dans ces situations, le périphérique est vraiment en lecture-écriture, mais le noyau Linux marque ce périphérique en interne comme en lecture seule et est utilisé en lecture seule. Il s'agit d'une fonctionnalité du noyau conçue pour la prévention des dommages, mais elle n'est utilisable qu'à un point.

La question est. Comment dire manuellement au noyau, le périphérique de bloc hdd fonctionne normalement?

Sans cela, le noyau sert le périphérique en lecture seule, comme le «CD-ROM», et aucune autre commande n'a de chance de fonctionner correctement, y compris mount / remount -o lecture-écriture, fsck et autres.

Ansvers inutilisable, vraiment qualifié de spam de personnes qui veulent aider, mais ne comprennent pas la nature du problème:

1. Essayez de remonter en lecture-écriture (impossible, l'appareil est RO)
2. fsck ceci (pourquoi? l'appareil est RO, aucune réparation n'est possible)
3. «Je ne sais pas» (d'abord avec sens, mais inutilisable)
4. 'Remplacez votre appareil' * (généralement le problème est autre chose)

Quelqu'un at-il une formule pour la question ci-dessus? Indicateur de commutateur pour le périphérique de bloc inscriptible qui le fait passer de l'état lecture seule à l'état lecture-écriture? À l'heure actuelle, il semble que personne ne sache comment.

Il s'agit de quelques solutions de contournement, mais généralement semi-utilisables ou inutilisables:

1. Le module de suppression prend en charge l'accès au disque dur ou à la baie de stockage spécifié. Malheureusement, le périphérique généralement endommagé conserve rootfs, ou le pilote conserve à la fois le périphérique endommagé et le périphérique qui conserve rootfs
2. Supprimez l'accès FC à l'appareil et rejoignez-le à nouveau (fctools), ce n'est pas toujours possible, cela ne fonctionne pas toujours.
3. Redémarrez la machine ENTIÈRE. Habituellement, cela est toujours possible et nous sommes toujours obligés de le faire.

Aux points 1. et 2. nous disons au noyau que nous déconnectons complètement le périphérique et que nous nous y connectons à nouveau. Le noyau a reconnu que cela rejoignait un nouveau périphérique fonctionnant correctement. Nous pouvons simuler cela en utilisant un périphérique USB et couper momentanément l'alimentation. Le point 3. est la dernière chance et fonctionne généralement. Mais pourquoi devrions-nous tout redémarrer? Malheureusement, à tout moment, nous avons perdu toutes les mises à jour des journaux et les tampons sales.

Remarquez, dans les mêmes situations, je n'ai aucun problème avec Windows (bureau et serveur).

essayez avec blockdev --setrwouhdparm -r 0

Comme Jose Luis Martin a suggéré d'utiliser blockdev, mon 2cent est de faire un remontage rw et forcefsck

(en supposant que sda ​​est votre disque)

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

Consultez cette page wiki, elle explique l'erreur lancée par libata:

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

D'après ce que je vois ci-dessus, vous avez un problème de délai d'attente et selon le document mentionné:

Le contrôleur n'a pas répondu à une commande ATA active. Cela pourrait être un certain nombre de causes. Le plus souvent, cela est dû à un bogue de sous-système d'interruption non lié (essayez de démarrer avec 'pci = nomsi' ou 'acpi = off' ou 'noapic'), qui n'a pas réussi à fournir une interruption alors que nous en attendions une du matériel.

Vous voudrez peut-être désactiver ACPI (vérifier comment en fonction de votre distribution) ou vérifier votre noyau pour les bogues connus et éventuellement le mettre à jour s'il n'est pas le plus récent (ou le rétrograder).

Redémarrez dans Windows 10, accédez aux options d'alimentation et désactivez l'arrêt rapide. puis redémarrez sous linux ..gbamm tout va bien.

un arrêt rapide dans Windows 10 met en veille certains fichiers et le lecteur est partiellement utilisé. donc Linux voit est aussi occupé.