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


17

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


Pas de réponse, mais peut-être lié en cas de # 2 (charge d'hôte élevée, délai d'expiration du disque dur invité): augmentez le délai d'expiration du disque dur Linux pour éviter la corruption du système de fichiers causée par les délais d'expiration du disque dur dans le système invité.
basic6

@Znik, ces machines virtuelles invitées fonctionnent-elles sur Citrix XenServer? Ou du matériel physique? Notre StorageServer fait le pont entre le pays de l'Ethernet et le pays des mini-sas. Lorsque cette machine à bridge panique, elle doit être redémarrée de force. Les machines virtuelles invitées Windows reviennent. Les machines virtuelles invitées Linux présentent exactement le même problème que vous. Rien de suggéré ici ne ramène les points de montage à rw.
rjt

@rjt, cela se produit dans de nombreuses situations. La situation principale est lorsque l'appareil est extrêmement ralenti avec tout problème, comme des dommages physiques, une surcharge de l'appareil, un câblage, un FC externe sur Eth et eth est surchargé, parfois une réinitialisation du commutateur lorsque le bloc de transfert, le délai d'attente, le paquet perdu, etc. L'appareil est généralement toujours visible, mais marqué comme en lecture seule. Le redémarrage n'est pas une résolution, c'est une solution de contournement comme je l'ai décrit dans la description principale de la question / du problème.
Znik

Réponses:


12

essayez avec blockdev --setrwouhdparm -r 0


merci, cela devrait être utile. J'attends tout timeout sur le contrôleur fc
Znik

Une partie importante qui doit être ajoutée: Parfois, il est nécessaire de faire un fscksur le système de fichiers en lecture seule, avant de pouvoir le remonter.
Evi1M4chine

3
Je ne travaille pas pour moi. j'ai un problème similaire
jonneymendoza

1
N'a pas fonctionné pour moi même avec fsck. Invités Citrix XenServer Linux.
rjt

Ca ne fonctionne pas ! Ces commandes semblent efficaces, mais le dongle est toujours RO. (c'est un logiciel, mais d'où?) Si vous voulez essayer, prenez n'importe quelle iso 9.4 de Debian.
Sandburg

5

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

1
Il est plus logique d'exécuter juste fsckavant le mount, car il ne pourra pas être monté sans fsck. (Au moins dans mon cas, c'est le cas.)
Evi1M4chine

`# blockdev --setrw / dev / xvda1 # # touch / tmp / date +%Y%m%d-%H%M%Stouch: ne peut pas toucher? / tmp / 20170722-221904?: Système de fichiers en lecture seule # # mount -o remount, rw / dev / xvda1 [137010.709883] EXT4 -fs erreur (périphérique xvda1): ext4_remount: 4824: abandon forcé par le montage utilisateur: ne peut pas remonter le périphérique / dev / xvda1 en lecture-écriture, est protégé en écriture `
rjt

2

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


Oui, c'est vraiment un timeout. Cela se produit généralement sur le contrôleur FC lorsque le périphérique de la baie est surchargé. Vous avez raison, sur le sous-système ATA local, il s'agit généralement d'un bug matériel ou d'une implémentation de pilote / chipset
Znik

C'est donc un temps mort? Eh bien, que sudo hdparm -I /dev/sdX | grep lockeddit-on? Il faut dire: «non verrouillé». Il a montré ces délais énigmatiques dans le passé ici chaque fois qu'un disque dur était verrouillé par un mot de passe ATA (en raison d'un effacement de sécurité précédent et d'un plantage du système plus tard, ce qui empêchait le pw de sécurité d'être effacé à nouveau). Ce truc de mot de passe a vraiment un impact énorme , aussi sur vos nerfs. :) Même les outils standard livrés par votre fournisseur de lecteur HD se comportent de manière folle, comme si le disque dur était sur le point de mourir lorsque le mot de passe est actif. Le coupable pour d'innombrables touffes de cheveux arrachés au fil des ans.
erreur de syntaxe

1

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.