SMART-Test non finisce mai

17

Quando eseguono SMART-Test utilizzando smartmontools, non finiscono MAI. Ottengo sempre "Interrotto (ripristino dell'host.)" Su vari sistemi e dischi diversi, incluso Debian in x86 e ARM, OS X su x64, con unità esterne e interne. Anche quando eseguito in modalità captive con dischi tutti vuoti (azzerati con dd).

Che cosa sto facendo di sbagliato?

hard-drive smart maintenance

— Max Ried
fonte

Non stai facendo nulla di male a te. È l'hardware che non funziona

— Ramhound,

È pensato per funzionare affatto?

— Max Ried il

Sì, dovrebbe funzionare

— Ramhound,

@MaxRied, stai dicendo di averlo provato su molti computer diversi con registri di dischi diversi e non hai mai visto un completamento, anche per i dischi che sai essere integri rispetto a un diverso strumento di analisi SMART?

— Frank Thomas,

@FrankThomas Sì.

— Max Ried il

14

Quando l'unità non gestisce alcuna attività di input / output durante il test, può andare in standby, aumentando la Interrupted (host reset)condizione. Prova a leggere dal disco a intervalli adeguati:

while true; do dd if=/dev/disk1 of=/dev/null count=1; sleep 60; done

(sostituire /dev/disk1con il dispositivo appropriato; legge un settore da quel dispositivo ogni 60 secondi fino a quando si preme ctrl-c)

Questo mi ha aiutato nel mio ambiente: OS X 10.6.8, unità USB collegata WD Elements, driver SAT-SMART 0.8.

Un test vincolato dovrebbe teoricamente mantenere l'unità online. Tuttavia, il comando hardware inviato smartctlpotrebbe scadere prima del completamento del test, causando il reset del kernel da parte del kernel e finendo nella stessa situazione di cui sopra ( bug # 303 ).

Vedi questo thread nella mailing list del supporto smartmontools per ulteriori dettagli. Riconosco Christian Franke per le intuizioni fornite qui.

— sve.g
fonte

Altre possibili interruzioni ( serverfault.com/a/584055 ): un cavo difettoso può causare timeout e il kernel attiverà un reset. Sono meno sicuro che sia necessario smettere di smartd. Eventuali timeout e interruzioni appariranno in dmesg / kern.log / journalctl -fk.

— Tobu,

Wow, è pazzesco! Conferma: dopo aver lasciato cadere un HGST HDN726060ALE610 da uno specchio zpool, è rimasto bloccato al 10% per 36 ore (finirà più velocemente senza altra attività, DESTRA?). Cinque minuti di queste minuscole letture dd lo hanno fatto finire. Lo scetticismo è stato respinto.

— Bill McGonigle,

È /dev/disk1dovrebbe essere il dispositivo o la partizione, ad esempio, come /dev/sdao /dev/sda1?

— Merchako,

@Merchako Questo è legato al sistema operativo Mac dove è effettivamente così.

— Max Ried il

5

Ho provato la soluzione da Tobu, nel mio caso ho continuato a trovare l'unità USB esterna in modalità di sospensione a prescindere qualche volta dopo aver avviato il test e interrotto, sembra che abbia finito per leggere da una cache del kernel e la cache era abbastanza grande per il disco per entrare in modalità sospensione. Ho notato che chiamare smartctl per chiedere lo stato era sempre in grado di "riattivare" il disco. Quindi: questa versione della stessa idea ha fatto il trucco per me:

sudo bash -c 'while true; do smartctl -a /dev/sdb > /dev/null; sleep 60; done'

Dopo 5 ore il disco USB esterno continua a girare. Per la prima volta ho potuto vedere un lungo test di smartctl su un disco esterno.

Credo che questa soluzione abbia anche il vantaggio di non spostare inutilmente le testine del disco ogni minuto. Il lungo periodo è terminato quasi esattamente nel tempo previsto (lo script keep-wake non ha aggiunto tempo alla corsa)

— Ari
fonte

3

Una variazione sulla risposta di Ari è di usare watch, perché l' smartctloutput può in effetti essere interessante per tenere traccia dello stato:

sudo watch -d -n 60 smartctl -a /dev/sdx

Ciò aggiornerà automaticamente l'output di smartctl -aogni 60 secondi, in modo da poter vedere quanto tempo rimane dell'autotest ed evidenziare le modifiche (quindi è più facile individuare che il test sta effettivamente procedendo).

— GreatEmerald
fonte

+1, mai visto watchprima.

— Hashim,

1

Il test captive potrebbe non funzionare se richiede più di 20 secondi.

Fonte: ticket # 303 , intitolato "In modalità captive smart test, prolunga il timeout come descritto dal dispositivo ATA".

— Sergey V
fonte