Perché i dischi rigidi danneggiati bloccano l'intero sistema?


128

Perché un disco rigido noto per avere blocchi danneggiati (verificato in HDTune e HDDScan), congela l'intero sistema?

Non è l'unità del sistema operativo; è collegato a un'altra porta SATA e sto provando a copiare i file da essa su un'altra unità integra.

Ho riscontrato questo problema con quasi tutti i dischi rigidi danneggiati e tutti i PC Windows.

Mi aspetterei di vedere il blocco solo per il programma che sto usando per copiare i file (Windows Explorer, ecc.), Ma invece il mio intero PC diventa a scatti e non riesco a navigare sul web o guardare film durante la copia di file dall'unità danneggiata.

La lunga storia

Vivo in una zona rurale dove ci sono problemi con l'elettricità (brownouts, ecc.). Io stesso sto usando un UPS e i miei dischi rigidi sono perfettamente a posto. Ma i miei vicini spesso chiedono aiuto per i loro problemi con il PC e trovo spesso che i loro dischi rigidi siano danneggiati, molto probabilmente a causa di problemi di elettricità. Naturalmente, dopo aver sostituito l'unità danneggiata, suggerisco ai miei vicini di acquistare un UPS.

Mi sono sempre chiesto, perché il mio PC si blocca completamente durante il recupero dei dati da unità danneggiate. È un problema hardware? È causato dal modo in cui il sistema operativo legge i dati? È qualcosa di specifico di Windows e non lo sperimenterò su * nix?

Ad ogni modo, d'ora in poi userò alcuni software dedicati (come l'inesorabile copiatrice di Roadkil) invece di Windows Explorer, anche se non sono sicuro che funzionerà diversamente, senza congelare l'intero PC.

Non è una richiesta di aiuto, è più per scopi educativi, quindi so perché le cose funzionano in questo modo.


11
L'uso di un enclosure USB esterno dovrebbe aiutare, poiché non si collega più il disco difettoso al controller SATA del sistema (inoltre, è sempre una buona idea aggiungere un ulteriore livello di hardware sacrificabile tra la scheda madre e un disco difettoso).
Matteo Italia,

3
Non è specifico per SATA, anche le unità IDE lo hanno fatto. Anche solo perché il disco è danneggiato non significa che il controller non lo sia, specialmente se un guasto elettrico ha danneggiato il disco.
Chris H,

La risposta accettata è fantastica, contiene ciò che stavo per dire e molto altro. Fondamentalmente stai andando nel panico il tuo controller SATA, che è un dispositivo di sistema super-importante, che a sua volta va nel panico di Windows. Mi chiedo se abilitare AHCI / "hot-swap" nel BIOS migliorerebbe la situazione.
Arthur Kay,

Risposte:


170

Questa è una di quelle aree in cui SATA non è ottimale. Il problema è a livello di protocollo di interconnessione del dispositivo di archiviazione e quindi non è correlato al software in esecuzione. L'uso di un'altra copiatrice di file o di un altro sistema operativo non migliorerà magicamente le cose, tranne per il fatto che potrebbe tentare di impostare valori di timeout diversi per ridurre l'impatto del problema (che potrebbe essere o meno possibile a seconda dell'hardware e del firmware; vedere di seguito ).

Ci sono alcuni punti importanti qui:

  1. Con SATA, se l'unità smette di rispondere, questo può legare l'intero sistema di archiviazione, non solo quello che ha problemi. Ha certamente il potenziale per legare l'intero controller e poiché la maggior parte dei sistemi consumer ha un solo controller del disco (quello integrato sulla scheda madre), questo significa tutto lo storage. È anche peggio se l'unità si guasta in qualche modo non standard e / o imprevisto, il che può certamente accadere se l'unità è marginale. Potresti essere interessato a In che modo un singolo disco in un array SATA RAID-10 hardware può arrestare l'intero array? in caso di errore del server.
  2. La maggior parte delle unità SATA consumer ha lunghi periodi di timeout predefiniti (nell'ordine dei minuti) e molte unità SATA consumer non dispongono di controllo configurabile per il ripristino degli errori . Le unità cosiddette "NAS" spesso hanno ERC configurabile, e le unità di fascia alta praticamente sempre lo fanno; tali unità possono anche avere timeout predefiniti più brevi (7 secondi essendo un valore comune). Lunghi periodi di timeout sono vantaggiosi se l'unità contiene l'unica copia dei dati, che purtroppo è comune nei sistemi consumer; sono uno svantaggio in una configurazione ridondante o in cui si desidera semplicemente ottenere il più possibile dall'unità prima che si deteriori ulteriormente.
  3. Un'unità continuerà a provare a leggere un settore danneggiato fino a quando non raggiunge la soglia di timeout o fino a quando l'host non segnala un interruzione. Poiché il bus SATA può essere collegato dall'attesa del completamento della lettura, potrebbe non essere possibile che il sistema operativo segnali un interruzione del comando a livello di memoria e, in casi estremi, le unità potrebbero non rispondere bene a un ripristino del bus SATA in una situazione del genere.

Il punto n. 1 è uno dei principali punti di vendita per SAS sui server; SAS ha una gestione degli errori significativamente migliore rispetto a SATA. Il punto n. 2 è una limitazione del firmware dell'unità e il n. 3 diventa un problema in realtà solo a causa del n. 2.

Quindi ciò che accade è che il sistema operativo emette un comando "Leggi settori" sul disco e che i settori particolari sono in qualche modo danneggiati. Pertanto, il disco passa alla modalità di nuovo tentativo per cercare di estrarre i dati dai piatti, provando ancora e ancora la lettura fino a quando non ottiene dati abbastanza buoni che la correzione degli errori del disco ( FEC ) è in grado di correggere gli errori rimanenti. Se sei sfortunato, questo potrebbe non essere mai, ma l'unità continuerà a provare per un periodo di tempo abbastanza lungo prima di decidere che questa lettura non avrà successo.

Poiché il sistema operativo è in attesa della lettura, questo rallenterà almeno il processo di copia in una ricerca per indicizzazione e, a seconda dell'esatta architettura del sistema operativo, il sistema operativo potrebbe diventare a scatti o addirittura bloccarsi per la durata. Il disco, a questo punto, è occupato con la lettura originale e non risponderà a ulteriori comandi di lettura fino a quando quello che sta eseguendo termina (con successo o senza successo), e altri software generalmente non faranno meglio del sistema operativo sta funzionando.

Quindi, tutto ciò che innesca una lettura altrove ( idealmente , solo sull'unità danneggiata) dovrà attendere in linea fino a quando l'unità danneggiata non legge correttamente il settore in questione o determina che non può essere letta. A causa della gestione non ottimale di SATA delle unità che non rispondono, ciò può significare che non solo l'unità da cui si sta copiando subirà un ritardo nell'I / O. Ciò può facilmente causare la lentezza o la mancata risposta di altri software, poiché il software attende che una diversa richiesta I / O finisca, anche se il sistema operativo è in grado di far fronte.

È anche importante notare qui che l'I / O del disco può avvenire anche se non si accede esplicitamente a nessun file sul disco. Le due cause principali sono il codice eseguibile load-on-demand e lo scambio. Poiché lo swap viene talvolta utilizzato anche quando il sistema non è sotto pressione della memoria e il codice eseguibile load-on-demand è comune nei sistemi moderni e con i moderni formati di file eseguibili, l'attività di lettura del disco non intenzionale durante l'uso normale è una possibilità molto reale.

Come sottolineato in un commento alla domanda di Matteo Italia , una strategia attenuante è quella di utilizzare una diversa interconnessione di archiviazione, che è un modo complicato di dire "metti il ​​disco in un contenitore USB". Astrattando tramite il protocollo di archiviazione di massa USB , ciò isola la parte problematica SATA dal resto del sistema, il che significa che, in teoria , solo gli I / O su quel disco specifico dovrebbero essere influenzati da problemi di I / O su quel disco.

A parte questo, questo è praticamente il motivo per cui SATA (in particolare SATA senza ERC a livello di unità) è spesso scoraggiato per RAID (in particolare livelli RAID con ridondanza, che tra quelli standard è tutto tranne RAID 0 ); i lunghi periodi di timeout e la cattiva gestione degli errori possono far sì che un intero dispositivo venga espulso dall'array per un singolo settore danneggiato, che il controller RAID potrebbe gestire bene se esiste ridondanza e il controller di archiviazione sa semplicemente che questo è il problema. SAS è stato progettato per array di archiviazione di grandi dimensioni, e quindi con l'aspettativa che occasionalmente si verifichino problemi su varie unità, il che ha portato alla sua progettazione per gestire il caso di una singola unità problematica o richiesta I / O con graziaanche se l'unità non lo fa. I dischi problematici non sono molto comuni nei sistemi consumer semplicemente perché quelli tendono a non avere molti dischi installati e quelli installati praticamente non hanno mai ridondanza; poiché SATA mirava a sostituire PATA / IDE e non SCSI (quest'ultimo era la nicchia a cui si rivolgeva SAS), è probabile che le sue caratteristiche di gestione degli errori e le richieste (o le garanzie) fossero considerate adeguate per il caso d'uso previsto.


19
Grazie per aver pubblicato una risposta sensata che spiega cosa sta succedendo. Questo è il tipo di domanda in cui di solito vedo risposte vaghe come "perché il sistema è in attesa del disco" o "perché è progettato in questo modo".
Mehrdad,

4
@kasperd: praticamente. Anche se in parte è anche un "errore" di Windows, poiché può succedere altrettanto facilmente con più controller. IMO questa risposta è un po ' volutamente vaga , visto che anche i controller SAS aziendali non sono immuni al problema. Si riduce davvero a determinate richieste I / O di blocco. Alcune operazioni del disco rigido richiedono che l'operazione X sia completata prima dell'operazione Y, e se X non finisce mai, Y non può mai iniziare - e qualsiasi cosa dopo Y si blocca, nominare se l'unità, il controller, il driver o il sistema operativo sono su colpa.
qasdfdsaq,

2
@JustAMartin In realtà, è quasi tutto asincrono già - qualsiasi periferica che supporta DMA in questi giorni è piena su asincrona; il kernel pianifica solo le richieste e gestisce gli interrupt che segnalano che la richiesta è stata eseguita. Il problema è che a volte è necessario attendere il completamento dell'operazione e, nel processo, possono bloccare qualcosa di importante. Come notato da user20574, la memoria virtuale è una di quelle, ma ci sono molte cose che richiedono alcune garanzie. Alcune parti del kernel non sono asincrone e, naturalmente, alcuni driver / dispositivi semplicemente fanno schifo.
Luaan,

2
@ MichaelKjörling "Poiché il sistema operativo è in attesa della lettura, questo rallenterà almeno il processo di copia in una ricerca per indicizzazione e, a seconda dell'esatta architettura del sistema operativo, il sistema operativo potrebbe diventare a scatti o addirittura bloccarsi per la durata." - Perché il sistema operativo diventa esattamente a scatti nel caso di lettura da un'unità secondaria (non di sistema)? Il problema non può essere interamente dovuto al comportamento di gestione degli errori del controller SATA. Penso che questa risposta potrebbe trarre vantaggio dalle informazioni su come Windows gestisce gli errori nel suo sottosistema di dischi.
Jordan Rieger,

1
@ MichaelKjörling Abbastanza giusto. La risposta ha molte buone informazioni, ma penso che non spieghi del tutto lo scenario specifico del PO. Per arrivare da una prospettiva diversa, puoi citare qualsiasi riferimento per il backup del tuo punto n. 1: "Con SATA, se l'unità smette di rispondere, questo può legare l'intero sistema di archiviazione, non solo quello che ha problemi Ha certamente il potenziale per legare l'intero controller ". ? Sembra un design terribile. Il sottosistema del disco del sistema operativo non è forse il colpevole più probabile? Cioè il controller è asincrono, ma il driver del sistema operativo a volte si blocca inutilmente.
Jordan Rieger,

3

Come affermato in precedenza, il problema con il sistema si blocca a causa di un disco rigido danneggiato è principalmente dovuto ai lunghi tentativi da parte dell'unità di recuperare dati illeggibili da settori danneggiati. Uno dei punti di forza delle unità aziendali è il timeout di lettura molto breve per i settori falliti. L'uso di un'unità aziendale può mitigare i problemi in una certa misura, ma non risolverli.

La risposta migliore, andando avanti, è mantenere backup adeguati in modo che non sia necessario il ripristino. La modifica del software di ripristino non farà alcuna differenza poiché si tratta di un problema di timeout del firmware.


2

Perché i dischi rigidi danneggiati bloccano l'intero sistema?

Non devono (in generale). Dipende dal particolare file system in che modo viene gestito un errore del disco.

Prendi in considerazione ZFS, che è progettato da zero per gestire una certa tolleranza ai guasti. Ecco un video dimostrativo (e uno con più spiegazioni ) in cui posizionano le unità in esecuzione su un'incudine, fanno un'oscillazione con una mazza e forano un'altra unità. Tutto mentre ZFS continua a funzionare.


2
In realtà, ci sono guasti al disco che ZFS non gestisce bene. Ad esempio, letture estremamente lunghe prima del timeout della richiesta I / O, in configurazioni ridondanti o non ridondanti. (È possibile configurare ZFS con la stessa facilità in modo tale da non avere ridondanza.) Ciò può facilmente portare all'uscita di unità dall'array in ZFS, che se questo scende al di sotto della soglia di ridondanza può causare l'intero array diventare non disponibile. Se impostato con failmode = wait, questo può mostrare risultati simili. L'errore completo del disco intero è il caso semplice per qualsiasi sottosistema di archiviazione; sono le pulsioni marginali che pongono problemi.
un CVn l'

E prima che tu pensi diversamente, in realtà eseguo ZFS (quasi esclusivamente) da solo. È un ottimo file system e un meraviglioso gestore di volumi, se stai attento e sai cosa stai facendo. Tuttavia, è progettato per sistemi di classe enterprise (workstation e server di fascia alta), con gli amministratori pagati per sapere cosa stanno facendo. Non è progettato per gestire bene alcune modalità di errore riscontrate nell'hardware delle materie prime, inclusi problemi di RAM e unità che impiegano troppo tempo a tornare da una richiesta I / O, e non è progettato per la facilità d'uso per gli utenti domestici o in casi d'uso per utenti domestici.
un CVn l'

Tranne nel video, ZFS non continua a funzionare. Ricomincia a funzionare dopo aver scollegato l'unità.
Christoffer Hammarström,

-2

Penso che il problema che stai riscontrando sia una parte di basso livello del sistema operativo che tenta numerose volte di leggere blocchi danneggiati prima di arrendersi. Questa routine viene implementata a un livello basso nel caso in cui sia necessaria durante l'avvio o altre operazioni autonome, quindi è difficile ripristinarla. Il sistema operativo eseguirà la pagina continuamente durante il normale funzionamento ed è difficile dare una priorità alle richieste concorrenti perché il sistema di basso livello non conoscerà la priorità del processo che possiede una richiesta di paging.


6
Il 'sistema a basso livello' fa conoscere la priorità di un processo che richiede una pagina; tali informazioni sono contenute nelle tabelle delle pagine , sebbene l'implementazione dipenda dal sistema da come viene gestita la priorità. Questa non è la risposta corretta alla domanda, si tratta di un problema hardware, non di un sistema operativo.
Chris Cirefice,

1
Penso che la risposta corretta alla domanda sia rifiutare di usare un'unità guasta. Tuttavia, ciò non soddisferebbe gli utenti che desiderano comprensibilmente recuperare il maggior numero possibile di dati.
jrrk,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.