Al momento non è possibile rispondere a questo problema.
Di solito dopo alcuni problemi con letture o scritture per bloccare il dispositivo, il kernel decide di cambiare flag per TUTTO IL DISPOSITIVO in sola lettura. Dopo questo, qualsiasi scrittura su qualsiasi partizione / filesystem situata su questo dispositivo causa lo scambio come di sola lettura insieme allo stato del dispositivo, perché qualsiasi scrittura è impossibile.
Esempio da dmesg, questa è una simulazione per guest linux su windows8 usando VirtualBox quando defrag prende l'immagine del dispositivo guest:
[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.
Dopo questo, rimontare causa:
mount / -o remount,rw
mount: cannot remount block device /dev/sda1 read-write, is write-protected
perché TUTTO il dispositivo sda mantenendo rootfs sda1 è PRONTO.
Nella mia esperienza questo si verifica in situazioni:
- L'HDD è veramente danneggiato. I problemi di scrittura restituiti dipendono dalle condizioni dell'HDD
- La macchina host è sovraccarica, quindi le scritture HDD virtuali per guest Linux sono scadute
- Il cavo FC o il dispositivo SAN (dischi array su Fibre Channel) sono sovraccarichi
- Connessione momentanea persa su FC o FCoE. Forse un pacchetto FC perso / scaduto
In queste situazioni il dispositivo è realmente in lettura-scrittura, ma il kernel linux contrassegna questo dispositivo internamente come sola lettura e viene usato come sola lettura. Questa è la funzionalità del kernel creata per la prevenzione dei danni, ma è utilizzabile solo in 1. punto.
La domanda è Come dire manualmente al kernel, il dispositivo a blocchi hdd funziona normalmente?
A parte questo, il kernel serve il dispositivo in sola lettura, come "CD-ROM", e nessun altro comando ha la possibilità di funzionare correttamente, incluso mount / remount -o read-write, fsck e altri.
Risponditori inutilizzabili, veramente qualificati come spam da persone che vogliono aiutare, ma non comprendono la natura del problema:
- Prova a rimontare come read-write (impossibile, il dispositivo è RO)
- fsck questo (cosa per? dispositivo è RO, nessuna riparazione è possibile)
- 'Non lo so' (prima con senso, ma inutilizzabile)
- 'Sostituisci il tuo dispositivo' * (di solito il problema è qualcos'altro)
Qualcuno ha qualche formula per la domanda sopra? Cambia flag per il dispositivo a blocchi scrivibile che lo ripristina dallo stato di sola lettura a quello di lettura-scrittura? In questo momento sembra che nessuno sappia come.
Sono alcune soluzioni alternative, ma di solito semi-utilizzabili o inutilizzabili:
- Rimuovi modulo supporta l'accesso all'hdd o all'array di archiviazione specificati. Sfortunatamente il dispositivo solitamente danneggiato mantiene i rootfs, o il driver mantiene sia il dispositivo danneggiato che il dispositivo che mantiene i rootfs
- Rimuovere l'accesso FC al dispositivo e unirlo nuovamente (fctools), non sempre possibile, non sempre funziona.
- Riavvia TUTTA la macchina. Di solito solo questo è sempre possibile e siamo sempre costretti a farlo.
Ai punti 1. e 2. diciamo al kernel che disconnettiamo completamente il dispositivo e ci riconnettiamo ad esso. Il kernel lo ha riconosciuto come unendo un nuovo dispositivo funzionante correttamente. Possiamo simularlo utilizzando il dispositivo USB e rimuovere temporaneamente l'alimentazione. Il punto 3. è l'ultima possibilità e di solito funziona. Ma perché dovremmo riavviare tutto? Sfortunatamente in ogni momento abbiamo perso tutti gli aggiornamenti delle riviste e i buffer sporchi.
Si noti, nelle stesse situazioni non ho problemi con Windows (desktop e server).