Questa fonte è più solida di una generica lamentela del tipo «i miei dischi non entrano mai in sospensione», perché IceWhale ha risposto sia con un piano di correzione del prodotto sia con un metodo diagnostico. I sei HDD in RAID5 sono rimasti attivi anche dopo l'arresto delle applicazioni Docker, quindi l'indagine si è spostata sui servizi di archiviazione e integrità di ZimaOS e su una possibile attività a livello del kernel.
ZimaOS 1.3.2 ha quindi ridotto le interrogazioni non necessarie dei dischi e migliorato il comportamento della modalità standby. Molto più tardi, ZimaOS 1.6.0 ha risolto un altro problema specifico per cui smartd riattivava a intermittenza i dischi in sospensione. Queste versioni risolvono cause note di riattivazione, ma un disco attuale che continua a rimanere attivo potrebbe essere utilizzato da un'altra applicazione, da un backup, da un indicizzatore, da un'attività del filesystem, da un bridge USB o da un servizio del kernel.
IceWhale ha modificato il polling dello storage in ZimaOS 1.3.2
orca-zhang ha descritto tre ottimizzazioni specifiche previste per la versione 1.3.2:
- una logica più semplice per i controlli dello stato;
- l'aggiornamento della cache dei dati del disco solo quando viene rilevata una modifica del disco;
- la rinuncia a recuperare informazioni come la temperatura o il tempo di accensione da un disco già in modalità standby.
Il motivo è importante: alcuni HDD o controller non sono in grado di rispondere a queste interrogazioni dalla cache, quindi la richiesta dei dati di integrità riattiva il disco fisico.
Le note sulla versione corrente 1.3.2 riassumono questo lavoro come una riduzione delle attività di lettura/scrittura non necessarie e un miglioramento della modalità Disk Standby.
IceWhale ha fornito un comando per interrogare i processi che accedono al disco
La risposta ufficiale della fonte suggeriva di identificare i processi che attualmente hanno aperto un filesystem o un dispositivo:
for pid in $(fuser -m <device_path> 2>/dev/null); do
ps -p $pid -o comm=
done | uniqSostituisci <device_path> con il percorso effettivo del disco o dello storage montato. Si tratta di una procedura diagnostica, non distruttiva.
IceWhale ha suggerito anche di arrestare temporaneamente i servizi di storage e file
Per la risoluzione dei problemi, la fonte suggeriva di verificare la modalità standby dopo aver arrestato:
systemctl stop zimaos-local-storage
systemctl stop icewhale-filesIceWhale avvertiva che alcune funzioni di Impostazioni e File avrebbero smesso di funzionare mentre questi servizi erano arrestati. Usa questa procedura solo come test diagnostico controllato, quindi riavvia i servizi o riavvia il dispositivo.
ZimaOS 1.6.0 ha risolto un'altra causa nota di riattivazione
Il changelog ufficiale della versione 1.6.0 ha aggiunto in seguito una correzione separata: i dischi non riuscivano a entrare nella normale modalità di sospensione perché il servizio smartd li riattivava a intermittenza.
Consulta la correzione ufficiale relativa alla modalità standby e a smartd.
Spostare AppData su NVMe non garantisce che gli HDD rimangano inattivi
L'utente della fonte aveva già spostato i database Docker su NVMe. Gli HDD possono comunque essere utilizzati dalla scansione dei contenuti multimediali, da Backup, dalle miniature, dai client SMB, dai controlli SMART, dalle attività RAID/parità, dall'indicizzazione di File o da un processo che mantiene aperto un percorso.
Usa prove effettive degli accessi invece di presumere che «tutte le app sono su NVMe» significhi che l'array non effettui alcuna operazione di I/O.
Il RAID5 può generare attività in background
I controlli di parità, le ricostruzioni, le verifiche, le attività sui metadati del filesystem e il monitoraggio possono accedere legittimamente a ogni membro. Verifica che il RAID non sia impegnato in un'operazione di manutenzione prolungata prima di diagnosticare il problema della modalità standby.
La versione corrente di ZimaOS dovrebbe essere testata prima di applicare vecchie soluzioni alternative sui servizi
La versione corrente di ZimaOS è la 1.7.1 e include anni di modifiche alla gestione dello storage successive a questo rapporto del gennaio 2025. Prima riproduci il problema nella versione corrente, quindi identifica la causa della riattivazione. Non disabilitare permanentemente i servizi di integrità o di storage solo per forzare l'arresto dei dischi.
Domande frequenti sulla modalità standby dei dischi
IceWhale ha riconosciuto il problema della modalità standby nella fonte?
Sì. Il personale ha dichiarato che il problema era oggetto di indagine e ha documentato le ottimizzazioni della versione 1.3.2.
Il controllo della temperatura o dell'integrità del disco può riattivare alcuni dischi?
Sì. IceWhale ha specificato che alcune unità prive di informazioni memorizzate nella cache potevano riattivarsi quando venivano interrogate.
smartd è stato successivamente identificato come un'altra causa di riattivazione?
Sì. ZimaOS 1.6.0 ha risolto esplicitamente le riattivazioni intermittenti causate da smartd, che impedivano la normale sospensione.
