Nella stampa di tecnologia informale (cioè giornalistica) e nei blog di tecnologia online e nei forum di discussione, si incontrano comunemente consigli aneddotici per lasciare una certa quantità di spazio libero su unità disco fisso o unità a stato solido. Vengono fornite varie ragioni per questo, o talvolta nessuna ragione. Come tali, queste affermazioni, sebbene forse ragionevoli nella pratica, hanno un'aria mitica su di loro. Per esempio:

• Una volta che i tuoi dischi sono pieni all'80%, dovresti considerarli pieni e dovresti immediatamente cancellare o aggiornare. Se colpiscono al 90% , dovresti considerare che i tuoi pantaloni personali sono in fiamme e reagire con una quantità adeguata di immediatezza per rimediare. ( Fonte .)

• Per mantenere la raccolta dei rifiuti in piena efficienza, i consigli tradizionali mirano a mantenere vuota dal 20 al 30 percento del disco. ( Fonte .)

• Mi è stato detto che avrei dovuto lasciare libero circa il 20% su un HD per prestazioni migliori, che un HD rallenta davvero quando è quasi pieno. ( Fonte .)

• Dovresti lasciare spazio ai file di scambio e ai file temporanei. Al momento lascio libero il 33% e prometto di non scendere al di sotto di 10 GB di spazio libero su disco fisso. ( Fonte .)

• Direi in genere il 15%, tuttavia con quanto sono grandi i dischi rigidi oggi, purché tu abbia abbastanza per i tuoi file temporanei e file di scambio, tecnicamente sei al sicuro. ( Fonte .)

• Consiglierei il 10% in più su Windows perché la deframmentazione non funzionerà se non c'è molto libero sull'unità quando lo esegui. ( Fonte .)

• In genere si desidera lasciare circa il 10% libero per evitare la frammentazione ( Fonte .)

• Se l'unità è costantemente piena per oltre il 75 o l'80 percento, vale la pena considerare l'aggiornamento a un SSD più grande. ( Fonte .)

C'è stata qualche ricerca, preferibilmente pubblicata su una rivista peer-reviewed, sulla percentuale o quantità assoluta di spazio libero richiesto da specifiche combinazioni di sistemi operativi, filesystem e tecnologia di archiviazione (ad esempio piatto magnetico vs. stato solido)? (Idealmente, tale ricerca spiegherebbe anche il motivo per non superare la quantità specifica di spazio utilizzato, ad esempio per impedire al sistema di esaurire lo spazio di scambio o per evitare la perdita di prestazioni.)

Se sei a conoscenza di tali ricerche, ti sarei grato se potessi rispondere con un link ad esso più un breve riassunto dei risultati. Grazie!

C'è stata qualche ricerca, preferibilmente pubblicata su una rivista peer-reviewed [...]?

Per questo bisogna tornare molto più indietro di 20 anni, di amministrazione del sistema o altro. Questo era un argomento caldo, almeno nel mondo dei sistemi operativi per personal computer e workstation, oltre 30 anni fa; il tempo in cui le persone di BSD stavano sviluppando Berkeley Fast FileSystem e Microsoft e IBM stavano sviluppando il FileSystem ad alte prestazioni.

La letteratura su entrambi i suoi creatori discute il modo in cui questi filesystem sono stati organizzati in modo tale che la politica di allocazione dei blocchi abbia prodotto prestazioni migliori cercando di rendere contigui i blocchi di file consecutivi. Puoi trovare discussioni su questo, e sul fatto che la quantità e la posizione dello spazio libero rimasto per allocare i blocchi influenza il posizionamento dei blocchi e quindi le prestazioni, negli articoli contemporanei sull'argomento.

Dovrebbe essere abbastanza ovvio, ad esempio, dalla descrizione dell'algoritmo di allocazione dei blocchi del Berkeley FFS che se non c'è spazio libero nel gruppo di cilindri corrente e secondario e l'algoritmo raggiunge così il fallback di quarto livello ("applica una ricerca esaustiva a tutti i gruppi di cilindri ") le prestazioni di allocazione dei blocchi di dischi ne risentiranno, così come la frammentazione del file (e quindi le prestazioni di lettura).

Sono queste e simili analisi (che sono tutt'altro che i soli progetti di filesystem che miravano a migliorare le politiche di layout dei progetti di filesystem dell'epoca) su cui si è basata la saggezza ricevuta degli ultimi 30 anni.

Ad esempio: il motto nel documento originale secondo cui i volumi FFS devono essere mantenuti pieni del 90% al massimo, per non risentirne delle prestazioni, basata su esperimenti fatti dai creatori, può essere trovato acriticamente ripetuto anche nei libri sui filesystem Unix pubblicati questo secolo ^{(ad es. Pate2003 p. 216)} . Poche persone lo mettono in discussione, anche se Amir H. Majidimehr lo ha effettivamente fatto il secolo prima, dicendo che xe in pratica non ha osservato un effetto evidente; anche perché il meccanismo Unix consuetudine che riserva che finale del 10% per uso superutente, il che significa che un disco pieno 90% è effettivamente piena 100% per i non superutenti comunque ^{(Majidimehr1996 p. 68)}. Così ha fatto Bill Calkins, il quale suggerisce che in pratica si può riempire fino al 99%, con dimensioni del disco del 21 ° secolo, prima di osservare gli effetti delle prestazioni di spazio libero ridotto perché anche solo l'1% dei dischi di dimensioni moderne è sufficiente per avere un sacco di spazio libero non frammentato ancora con cui giocare ^{(Calkins2002 p. 450)} .

Quest'ultimo è un esempio di come la saggezza ricevuta possa sbagliarsi. Ci sono altri esempi di questo. Proprio come i mondi SCSI e ATA di indirizzamento a blocchi logici e registrazione dei bit suddivisi in zone piuttosto gettavano fuori dalla finestra tutti i calcoli accurati della latenza rotazionale nella progettazione del filesystem BSD, così la meccanica fisica degli SSD piuttosto gettava fuori dalla finestra lo spazio libero ha ricevuto saggezza che si applica ai dischi di Winchester.

Con gli SSD, la quantità di spazio libero sul dispositivo nel suo insieme , cioè su tutti i volumi sul disco e tra di essi , ha un effetto sia sulle prestazioni che sulla durata. E la base stessa dell'idea che un file debba essere archiviato in blocchi con indirizzi di blocchi logici contigui è ridotta dal fatto che gli SSD non hanno piatti da ruotare e si dirigono a cercare. Le regole cambiano di nuovo.

Con gli SSD, la quantità minima di spazio libero consigliata è in realtà superiore al tradizionale 10% derivante da esperimenti con dischi Winchester e Berkeley FFS 33 anni fa. Anand Lal Shimpi dà il 25%, per esempio. Questa differenza è aggravata dal fatto che deve essere spazio libero su tutto il dispositivo , mentre la cifra del 10% si trova all'interno di ogni singolo volume FFS , e quindi è influenzata dal fatto che il proprio programma di partizionamento sappia TRIM tutto lo spazio che non è allocato a un volume di disco valido dalla tabella delle partizioni.

È inoltre aggravato da complessità come i driver di file system compatibili con TRIM che possono TRIM liberare spazio all'interno dei volumi del disco e dal fatto che i produttori di SSD stessi allocano già vari gradi di spazio riservato che non è nemmeno visibile al di fuori del dispositivo (cioè all'host ) per vari usi come la raccolta dei rifiuti e il livellamento dell'usura.

Bibliografia

• Marshall K. McKusick, William N. Joy, Samuel J. Leffler e Robert S. Fabry (1984-08). Un file system veloce per UNIX . Transazioni ACM su sistemi informatici. Emissione volume 2 3. pagg. 181-197. Archiviato su cornell.edu.
• Roy Duncan (1989-09). Obiettivi di progettazione e implementazione del nuovo file system ad alte prestazioni . Microsoft Systems Journal . Edizione volume 4 5. pp. 1–13. Archiviato su wisc.edu.
• Marshall Kirk McKusick, Keith Bostic, Michael J. Karels e John S. Quarterman (1996-04-30). "Il Berkeley Fast Filesystem". La progettazione e l'implementazione del sistema operativo 4.4 BSD . Addison-Wesley Professional. ISBN 0201549794.
• Dan Bridges (1996-05). All'interno del file system ad alte prestazioni - Parte 4: frammentazione, bitmap dello spazio su disco e pagine di codice . Bit significativi. Archiviato su Electronic Developer Magazine per OS / 2.
• Keith A. Smith e Margo Seltzer (1996). Un confronto tra i criteri di allocazione del disco FFS . Atti della Conferenza tecnica annuale USENIX. Archiviato su harvard.edu.
• Steve D. Pate (2003). "Analisi delle prestazioni dell'FFS". File system UNIX: evoluzione, progettazione e implementazione . Amplificatore John Wiley; Figli maschi. ISBN 9780471456759.
• Amir H. Majidimehr (1996). Ottimizzazione di UNIX per le prestazioni . Prentice Hall. ISBN 9780131115514.
• Bill Calkins (2002). "Gestione dei file system". All'interno di Solaris 9 . Pubblicazione Que. ISBN 9780735711013.
• Anand Lal Shimpi (2012-10-04). Esplorare la relazione tra area di riserva e coerenza delle prestazioni nei moderni SSD . AnandTech.
• Henry Cook, Jonathan Ellithorpe, Laura Keys e Andrew Waterman (2010). IotaFS: esplorazione delle ottimizzazioni del file system per SSD . Transazioni IEEE su elettronica di consumo. Archiviato su stanford.edu.
• https://superuser.com/a/1081730/38062
• Accela Zhao (10-04-2017). Un riepilogo su SSD e FTL . github.io.
• Windows taglia lo spazio non partizionato (non formattato) su un SSD?

Anche se non posso parlare della "ricerca" pubblicata da "riviste con peer review" - e non vorrei fare affidamento su quelli per il lavoro quotidiano - posso comunque parlare delle realtà di centinaia di produzioni server con diversi sistemi operativi per molti anni:

Esistono tre motivi per cui un disco completo riduce le prestazioni:

• Fame di spazio libero: pensa a file temporanei, aggiornamenti, ecc.
• Degrado del file system: la maggior parte dei file system risente della loro capacità di disporre in modo ottimale i file se non è presente spazio sufficiente
• Degrado a livello di hardware: SSD e dischi SMR senza abbastanza spazio libero mostreranno un throughput ridotto e - ancora peggio - una maggiore latenza (a volte di molti ordini di grandezza)

Il primo punto è banale, soprattutto perché nessun sistema di produzione sano userebbe mai lo spazio di swap per espandere e ridurre in modo dinamico i file.

Il secondo punto differisce notevolmente tra file system e carico di lavoro. Per un sistema Windows con carico di lavoro misto, una soglia del 70% risulta abbastanza utilizzabile. Per un file system ext4 Linux con pochi ma file di grandi dimensioni (ad es. Sistemi di trasmissione video), questo può arrivare fino al 90 +%.

Il terzo punto dipende dall'hardware e dal firmware, ma in particolare gli SSD con un controller Sandforce possono ricorrere alla cancellazione a blocco libero su carichi di lavoro a scrittura elevata, portando a latenze di scrittura che aumentano di migliaia di percento. Di solito lasciamo il 25% libero a livello di partizione, quindi osserviamo un tasso di riempimento inferiore all'80%.

raccomandazioni

Mi rendo conto di aver menzionato come assicurarsi che venga applicato un tasso di riempimento massimo. Alcuni pensieri casuali, nessuno dei quali "rivisto da pari" (pagato, falso o reale) ma tutti provenienti da sistemi di produzione.

• Usa i confini del filesystem: /varnon appartiene al filesystem di root.
• Monitoraggio, monitoraggio, monitoraggio. Usa una soluzione pronta, se ti va bene, altrimenti analizza l'uscita df -he lascia che le campane d'allarme si spengano nel caso. Questo può salvarti da 30 kernel su un root fs con aggiornamenti automatici installati e in esecuzione senza l'opzione autoremove.
• Pesare la potenziale interruzione di un overflow di fs rispetto al costo di ingrandirlo in primo luogo: se non si è su un dispositivo incorporato, è possibile raddoppiare quei 4G per root.

C'è stata qualche ricerca ... sulla percentuale o sulla quantità assoluta di spazio libero richiesto da specifiche combinazioni di sistemi operativi, filesystem e tecnologia di archiviazione ...?

In 20 anni di amministrazione del sistema, non ho mai incontrato ricerche dettagliate sui requisiti di spazio libero di varie configurazioni. Sospetto che ciò sia dovuto al fatto che i computer sono configurati in modo così vario che sarebbe difficile farlo a causa del numero assoluto di possibili configurazioni di sistema.

Per determinare la quantità di spazio libero richiesto da un sistema, è necessario tenere conto di due variabili:

1. Lo spazio minimo richiesto per prevenire comportamenti indesiderati, che possono avere una definizione fluida.

   Si noti che non è utile definire lo spazio libero richiesto solo con questa definizione, poiché questo equivale a dire che è sicuro guidare 80 miglia all'ora verso un muro di mattoni fino al punto in cui ci si scontra.

2. La velocità con cui viene consumata la memoria, che determina una quantità variabile di spazio aggiuntivo da riservare, per evitare che il sistema si degrada prima che l'amministratore abbia il tempo di reagire.

La combinazione specifica di SO, filesystem, architettura di archiviazione sottostante, insieme al comportamento delle applicazioni, alla configurazione della memoria virtuale, ecc. Crea una vera sfida per chi desidera fornire requisiti di spazio libero definitivi.

Ecco perché ci sono così tante "pepite" di consigli là fuori. Noterai che molti di loro suggeriscono una configurazione specifica. Ad esempio, "Se si dispone di un SSD soggetto a problemi di prestazioni in prossimità della capacità, rimanere al di sopra del 20% di spazio libero".

Poiché non esiste una risposta semplice a questa domanda, l'approccio corretto per identificare il requisito di spazio libero minimo del sistema è quello di considerare le varie raccomandazioni generiche alla luce della configurazione specifica del sistema, quindi impostare una soglia, monitorarla ed essere disposta a modificarla come necessario.

Oppure potresti semplicemente mantenere almeno il 20% di spazio libero. A meno che, naturalmente, non si disponga di un volume RAID 6 da 42 TB supportato da una combinazione di SSD e dischi rigidi tradizionali e un file di scambio pre-allocato ... (è uno scherzo per la gente seria).

Ovviamente, un'unità stessa (HDD o SSD simili) non potrebbe fregare di meno di quante percentuali sono in uso, a parte il fatto che gli SSD sono in grado di cancellare il loro spazio libero in anticipo. Le prestazioni di lettura saranno esattamente le stesse e le prestazioni di scrittura potrebbero essere leggermente peggiori su SSD. Ad ogni modo, le prestazioni di scrittura non sono così importanti su un'unità quasi completa, poiché non c'è spazio per scrivere nulla.

Il tuo sistema operativo, file system e applicazioni, d'altra parte, si aspettano che tu abbia sempre spazio libero disponibile. 20 anni fa era normale che un'applicazione controllasse lo spazio disponibile sull'unità prima di provare a salvare i file lì. Oggi, l'applicazione crea file temporanei senza la tua autorizzazione e in genere si arresta in modo anomalo o si comporta in modo irregolare quando non riesce a farlo.

I filesystem hanno aspettative simili. Ad esempio, NTFS riserva un grosso pezzo del tuo disco per MFT, ma ti mostra ancora questo spazio come libero. Quando si riempie il disco NTFS oltre l'80% della sua capacità, si ottiene la frammentazione MFT che ha un impatto molto reale sulle prestazioni.

Inoltre, avere spazio libero aiuta davvero contro la frammentazione dei file regolari. I filesystem tendono ad evitare la frammentazione dei file trovando il posto giusto per ogni file a seconda delle sue dimensioni. Su un disco quasi pieno avranno meno opzioni, quindi dovranno fare scelte più povere.

Su Windows, ci si aspetta anche di avere spazio su disco sufficiente per il file di scambio , che può aumentare quando necessario. In caso contrario, dovresti aspettarti che le tue app vengano chiuse forzatamente. Avere pochissimo spazio di swap può effettivamente peggiorare le prestazioni.

Anche se lo swap ha dimensioni fisse, esaurire completamente lo spazio su disco del sistema può causare l'arresto anomalo del sistema e / o renderlo non avviabile (sia Windows che Linux), poiché il sistema operativo si aspetterà di poter scrivere sul disco durante l'avvio. Quindi sì, colpire il 90% dell'utilizzo del disco dovrebbe farti considerare le tue vernici in fiamme. Non ho visto computer che non si sono avviati correttamente fino a quando i download recenti non sono stati rimossi per dare al sistema operativo un po 'di spazio su disco.

Per gli SSD dovrebbe esserci un po 'di spazio perché la velocità di riscrittura aumenta e influisce negativamente sulle prestazioni di scrittura del disco. L'80% è un valore sicuro probabilmente per tutti i dischi SSD, alcuni modelli più recenti potrebbero funzionare bene anche con una capacità occupata del 90-95%.

https://www.howtogeek.com/165542/why-solid-state-drives-slow-down-as-you-fill-them-up/

Le "regole" variano a seconda delle esigenze. E ci sono casi speciali, come ad esempio ZFS: "Con una capacità del 90%, ZFS passa dall'ottimizzazione basata sulle prestazioni a quella spaziale, che ha enormi implicazioni sulle prestazioni". Sì, questo è un aspetto progettuale di ZFS ... non qualcosa derivato dall'osservazione o da prove aneddotiche. Ovviamente, questo è meno un problema se il tuo pool di archiviazione ZFS è costituito esclusivamente da SSD. Tuttavia, anche con i dischi rotanti, puoi raggiungere felicemente il 99% o il 100% quando hai a che fare con l'archiviazione statica e non hai bisogno di prestazioni di prim'ordine, ad esempio la tua collezione di film preferita di tutti i tempi, che non cambia mai e dove la sicurezza è priorità 1.

Successivamente, btrfs - un caso estremo: quando lo spazio libero diventa troppo basso (pochi MByte), puoi raggiungere il punto di non ritorno. No, l'eliminazione dei file non è un'opzione, in quanto non è possibile. Semplicemente non c'è abbastanza spazio per eliminare i file. btrfs è un file system COW (copia su scrittura) e puoi raggiungere un punto in cui non puoi più modificare i metadati. A questo punto, è ancora possibile aggiungere ulteriore spazio di archiviazione al file system (potrebbe funzionare una chiavetta USB), quindi eliminare i file dal file system espanso, quindi ridurre il file system e rimuovere nuovamente lo spazio di archiviazione aggiuntivo). Ancora una volta, questo è un aspetto causato dalla progettazione del file system.

Le persone che possono fornirti "dati reali (gravi)" sono probabilmente quelli che si occupano di "archiviazione reale (grave)". La risposta (eccellente) di Twisty menziona gli array ibridi (costituiti da enormi quantità di spinning lento economico, molti dischi con spinning veloce, molti SSD ...) che sono gestiti in un ambiente aziendale in cui il principale fattore limitante è la velocità con cui l'amministratore è in grado di ordinare aggiornamenti. Passare da 16T a 35T può richiedere 6 mesi ... quindi finisci con rapporti seriamente supportati che suggeriscono di impostare la sveglia al 50%.

Ci sono molti, molti fattori che contribuiscono al risultato in quantità molto specifiche per l'installazione. Quindi, non esiste un numero reale e veloce, questo può essere misurato solo in funzione di quei parametri. (Questo è probabilmente il motivo per cui altri utenti non riportano ricerche specifiche su questo specifico argomento fatto - troppe variabili per compilare qualcosa di conclusivo.)

• Hardware

  • L'HDD ha tutti i suoi settori assegnati in ogni momento. Quindi non importa assolutamente quanti di essi contengano i dati degli utenti attuali. (Per il controller, tutti i settori contengono sempre dei dati, li legge e li sovrascrive come detto.)
  • Il controller di SSD, d'altra parte, (de) alloca i suoi settori in modo dinamico, simile a un file system. Il che rende questo lavoro più difficile con usi più elevati. Quanto è più difficile e quanto questo influenza le prestazioni osservabili dipende da:
    • Le prestazioni del controller e la qualità degli algoritmi
    • Scrivi carico
    • In una lettera, carico complessivo (per dare al controller il tempo per la garbage collection)
    • Overprovision dello spazio (alcuni produttori lasciano addirittura che il cliente lo scelga preordinando o cambiando dinamicamente)

• File system

  • Diversi file system sono progettati per carichi diversi e requisiti di elaborazione dell'host. Questo può essere modificato in una certa misura dai parametri di formato.
  • Le prestazioni di scrittura di FS sono una funzione dello spazio libero e della frammentazione, le prestazioni di lettura sono solo una funzione di frammentazione. Si degrada gradualmente fin dall'inizio, quindi la domanda è dove si trova la tua soglia tollerabile.

• Tipo di carico

  • Il carico pesante in scrittura enfatizza rapidamente la ricerca e l'accesso a nuovi blocchi liberi
  • Il carico pesante in lettura enfatizza il consolidamento dei dati correlati in modo che possano essere letti con un sovraccarico

Una cosa da considerare con le trasmissioni meccaniche è che il throughput del bordo esterno è superiore a quello interno. Questo perché ci sono più settori per giro per la più grande circonferenza dell'esterno.

Man mano che l'unità raggiunge la capacità, le prestazioni diminuiranno perché saranno disponibili solo settori interni più lenti.

Per un'analisi più approfondita, consultare https://superuser.com/a/643634

Dipende dall'uso previsto dell'unità, ma in generale dal 20% al 15% di spazio libero è una buona risposta per i dischi rotanti e il 10% o più è buono per gli SSD.

Se questa è l'unità principale sul computer e i file possono essere spostati, lo spazio libero del 20% dovrebbe impedire rallentamenti significativi. Ciò consentirà uno spazio libero sufficiente in tutto il disco per i dati da spostare e copiare secondo necessità. Un disco rotante funzionerà meglio quando le posizioni libere sono più vicine ai dati originali, mentre in un SSD la posizione fisica non influisce sulle prestazioni quotidiane. Quindi, l'unità di spinning dovrebbe avere più spazio libero per motivi puramente prestazionali. Su SSD, lo spazio libero ridotto ridurrà la longevità dell'unità, ma non ridurrà le prestazioni. Gli SSD tentano di archiviare dati temporanei e file di download casuali in posizioni meno utilizzate in modo da bilanciare l'utilizzo della cella nell'intero disco; altrimenti una parte del disco invecchierà molto più velocemente del resto.

Se si tratta di un'unità multimediale o di archiviazione a lungo termine, dovrebbe essere sufficiente una percentuale compresa tra il 5% e il 10% e il 10% sarebbe preferibile se si tratta di un disco rotante. Non è necessario tanto spazio libero perché questa unità richiede raramente lo spostamento dei dati, quindi le prestazioni non sono un fattore altrettanto rilevante. Lo spazio libero è utile principalmente per consentire l'eliminazione e la sostituzione di settori danneggiati e per consentire ai file di essere più contigui.

Non spingerei oltre il 95% della capacità di guida per più di un giorno a meno che non ci sia una ragione molto buona e chiara.