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