È male avere i filesystem quasi pieni?

Esempio Ho filesystem JFS2 / EXT3 di dimensioni grandi / piccole , qualunque sia (e vari sistemi operativi, Linux, AIX), ma alcuni di questi sono in uso: 90%, 95%, 98% di utilizzo.

Domande: avere un filesystem quasi pieno fa qualcosa di male? Problemi di prestazioni o corruzione FS o problema HW?

AGGIORNARE:

• La domanda riguarda l'ambiente aziendale. Qualcuno ha saggi / URL autentici sugli effetti? :)

• "Quali directory si trovano su questi filesystem?" - qualsiasi, ad es .: SAP, ORACLE, ecc.

• I dischi di solito provengono da SAN.

Se si tratta di un'archiviazione del database "statica" non vi è alcun danno nel riempirla, specialmente quando l'estensione automatica del DB è disattivata. Qualsiasi altra cosa sarebbe uno spreco di prezioso spazio SAN. Il monitoraggio può essere disattivato per questi filesystem oppure il livello di avviso deve essere aumentato al 99 o addirittura al 100%.

Questo vale solo per i dati non in crescita, quindi i log dovrebbero andare altrove. Tuttavia, l'archiviazione dei registri deve essere attentamente monitorata. E dovrebbe essere abbastanza grande da consentire a un amministratore di reagire tempestivamente a un avviso.

Un filesystem non si rompe solo perché è pieno, quindi non ci sono problemi dal punto di vista del filesystem. È più probabile che i file si frammentino quando il filesystem è quasi pieno e sono possibili problemi di prestazioni a seconda del filesystem, ma questo di solito non è critico.

Il vero problema è che su un filesystem completo, qualsiasi scrittura fallirà . Quindi dipende da cosa proverà a scrivere su un tale filesystem.

Molti programmi devono essere in grado di scrivere / salvare i dati per funzionare correttamente. Quindi se il tuo filesystem è pieno quando qualcosa sta provando a scrivere, sperimenterai la perdita o la rottura dei dati a livello di applicazione. "Ho provato a salvare i tuoi dati, ma non ci sono riuscito" è un caso che molti programmi non gestiscono particolarmente bene. Nel peggiore dei casi il programma avrà iniziato a sovrascrivere il vecchio file di salvataggio prima di notare che non ci sarà abbastanza spazio per il nuovo file di salvataggio, quindi hai perso entrambi.

Per aspetti critici del sistema (ad es. Eventuali scritture che si verificano all'avvio / spegnimento, funzionalità di registrazione, ecc.), Nella peggiore delle ipotesi un filesystem completo potrebbe rendere il sistema incapace di funzionare correttamente; I filesystem ext * hanno una riserva di root proprio per questo motivo, per consentire alle cose di sistema (root) uno spazio libero quando tutto il resto è pieno. Questo è un caso in cui è necessario fornire ulteriore spazio di archiviazione o eliminare alcune cose vecchie.

Dal punto di vista della produzione è un cattivo stato. In primo luogo le prestazioni diminuiscono all'aumentare dell'utilizzo del disco. Quando un disco si avvicina alla piena capacità, ci sono meno aree sequenziali del disco in cui archiviare i dati. Ciò influisce sulle prestazioni a causa delle ricerche del disco aggiuntive e degli effetti di latenza in attesa che un settore libero raggiunga la testa del disco.

Più importante è il potenziale effetto sul sistema. Il server fornisce un servizio vitale? Quanto tempo passerà prima che i team di sviluppo e operazioni si rendano conto che i servizi sono inattivi? Quanto tempo passerà prima che gli utenti si arrabbino quando non è disponibile alcun servizio? Le applicazioni si bloccano spesso quando non c'è spazio di archiviazione su cui scrivere. Potrebbero esserci effetti a catena che possono causare ulteriori problemi, aggiungendo ancora più tempo prima che i servizi vengano completamente ripristinati. E quando il servizio è stato ripristinato, lo stato del sistema potrebbe non essere bilanciato, ad esempio un enorme arretrato di dati in entrata durante i tempi di inattività del servizio provoca ritardi nell'elaborazione.

Non è intrinsecamente negativo, ma qualcosa di cui prestare molta attenzione. Non vuoi esaurire completamente lo spazio su un'unità quando il sistema operativo richiede più spazio accidentale di quello che hai, o qualunque cosa il tuo computer tenti di scrivere dopo fallirà semplicemente. Le conseguenze dipenderanno da ciò che stava cercando di salvare.

I "mangiatori di spazio" improvvisi possono includere un file di scambio inaspettatamente grande (forse causato da perdite di memoria, ecc.), Un'immagine di sonno che può occupare tanto spazio su disco fisso quanto la RAM e file di output di grandi dimensioni dai programmi. Devi semplicemente essere sempre sicuro di non rimanere a corto di spazio.

Lo scenario migliore è quando non c'è più spazio per un file di scambio e il sistema di solito si arresta in modo anomalo senza effetti negativi a lungo termine.

Di solito è sicuro riempire le partizioni che non dispongono di un sistema operativo (ad esempio su un disco rigido esterno in cui archiviare manualmente i dati). Le prestazioni possono diminuire se le unità si riempiono, ma se sei costantemente in esecuzione con un utilizzo elevato del disco, dovresti davvero ottenere un altro disco rigido in modo da poter smettere di preoccuparti.

Ci sono tre podcast davvero validi sui filesystem e se ricordo bene e come funzionano come "deframmentazione automatica" che forse ti aiuta a capire meglio il tuo problema. Penso che valga la pena ascoltare quei 3 episodi se sei interessato ai file system. Ma attenzione, è estremamente geek:

Episodio 1 2 e terzo è il numero 58 che non posso pubblicare a causa della reputazione troppo scarsa \:

Il podcast si chiama ipercritico e l'host è John Siracusa.

Dovresti considerare alcune cose:

1. AVETE BISOGNO dei dati che stanno consumando tutto quello spazio? Potrebbero esserci molti dati che VUOI, ma non di cui hai bisogno. E se decidi di averne BISOGNO, assicurati di fare ogni uso dei dati. In altre parole, ci sono informazioni sulla tua azienda, mercato o clienti che puoi ottenere dai dati? Puoi avere un senso
2. Se necessario, tutti i dati considerano il modo più economico per archiviarli. Nei server interni, archiviazione remota, compressa, l'X% più recente dei dati. Se non si dispone di budget per l'espansione o l'archiviazione remota, eliminare il 10% più vecchio dei dati semplicemente per migliorare le prestazioni.

Nel caso di un disco rigido esterno in cui il sistema operativo non è presente, è possibile utilizzare in modo sicuro la maggior parte del disco senza un notevole deterioramento delle prestazioni. Per un disco rigido con il sistema operativo, esistono file di cache le cui dimensioni dipendono dal sistema operativo e dai tipi di attività che esegue.

Per Linux, dai un'occhiata a questo: come posso fare un benchmark del mio HDD?

Vedi questi testi per un'esposizione più approfondita: http://www.amazon.com/Memory-Mass-Storage-Giovanni-Campardo-ebook/dp/B00F76KCGY/ref=sr_1_4?s=digital-text&ie=UTF8&qid=1420389894&sr=1- 4 & parole chiave = disco rigido + + prestazioni

http://www.amazon.com/SImple-Choosing-Installing-Upgrading-Super-fast-ebook/dp/B00LNZTXFE/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1420389894&sr=1-2&keywords=hard+drive+ prestazione

Se le unità sono piene, le prestazioni del PC potrebbero essere ridotte . Sto eseguendo il mio PC su Ubuntu 12.10 e le mie unità erano piene. Le mie applicazioni si aprivano molto lentamente e l' avvio era lento . Quindi ho portato un disco rigido esterno e da allora ho mantenuto il 50-60% di utilizzo del disco. Ti suggerirò lo stesso.