Perché la deframmentazione dell'unità C ha aumentato lo spazio libero su disco di 10 GB?

Ho usato Defraggler per deframmentare lo spazio libero sul mio disco C: \ da 100 GB che era pieno di 85 GB. Dopo la deframmentazione, l'unità ha mostrato solo 75 GB pieni. Come sono comparsi magicamente 10 GB di spazio libero? Ho perso dei dati?

Ho eseguito una pulizia del disco prima della deframmentazione e il cestino era solo di circa 11 MB, quindi non è possibile a causa della pulizia dei file temporanei. Nota che ho deframmentato lo "spazio libero", il che significa che avrebbe dovuto riorganizzare i blocchi vuoti per essere contigui.

ntfs disk-space defragment

— goweon
fonte

Probabilmente un'interazione con la copia shadow: vedi ad esempio ( piriform.com/docs/defraggler/technical-information/… )

— horatio

Inoltre, Defraggler ha un'opzione per svuotare il cestino prima della deframmentazione.

— OKtosiTe

Risposte:

Ciò che probabilmente è accaduto è che l'operazione di deframmentazione ha costretto Windows a lanciare alcune istantanee di ripristino del sistema. Sarebbe un caso patologico di frammentazione causare un sovraccarico di metadati pari al 10% dello spazio su disco in aggiunta a ciò che Windows utilizza normalmente. anche allora, non sono sicuro che sia possibile.

Non vedo nulla nella cronologia delle versioni o nella documentazione di Defraggler che indichi che è in grado di deframmentare correttamente i file per impedire l'eliminazione delle copie shadow. In effetti, questo thread dal forum di supporto di Defraggler indica che sanno che sta succedendo (c'è un post di un amministratore di bordo etichettato "Official Piriform Bug Fixer" nel thread) ma non indicano se lo risolveranno o meno.

Le copie shadow potrebbero andare perse quando si deframmenta un volume : la ragione per cui ciò accade è che, per impostazione predefinita, VSS funziona con cluster da 16 KB per impostazione predefinita, mentre la maggior parte dei volumi NTFS sono formattati con cluster da 4 KB. Quindi, se un'operazione di deframmentazione sta spostando dati che non sono multipli di un cluster da 16 KB (o che la "distanza" che viene spostata non è un multiplo di 16 KB), VSS li traccerà come una modifica e potrebbe eliminare tutti i tuoi istantanee.

MSDN: deframmentazione dei file :

Se possibile, spostare i dati in blocchi allineati l'uno rispetto all'altro con incrementi di 16 kilobyte (KB). Ciò riduce l'overhead di copia su scrittura quando le copie shadow sono abilitate, poiché lo spazio della copia shadow viene aumentato e le prestazioni vengono ridotte quando si verificano le seguenti condizioni:

La dimensione del blocco della richiesta di spostamento è inferiore o uguale a 16 KB.

Il delta di spostamento non è in incrementi di 16 KB.

La deframmentazione integrata di Vista non funziona in questo modo :

Un cambiamento che non è ovvio per gli utenti è la nostra ottimizzazione delle copie shadow durante la deframmentazione. Defrag ha un'euristica speciale per spostare i blocchi di file in modo da ridurre al minimo l'attività di copia su scrittura e il consumo dell'area di archiviazione delle copie shadow. Senza questa ottimizzazione, il processo di deframmentazione accelererebbe l'eliminazione delle copie shadow meno recenti.

— afrazier
fonte

Non conosco le istantanee di questa risposta, ma non sono convinto che la deframmentazione abbia liberato lo spazio. La deframmentazione potrebbe aver svuotato il cestino? Su un filesystem che non combina piccoli file in un singolo cluster, non riesco a vedere come la deframmentazione comporterebbe un tale guadagno di spazio. Immaginavo che avessi 10 G di spazio disponibile in blocchi così piccoli che Windows non lo contava, ma non avevo mai sentito parlare di quel comportamento prima.

— Slartibartfast,

@Slartibartfast: è un problema se l'app non è scritta correttamente. Aggiornerò la mia risposta con ulteriori prove, ora che non sono sul mio telefono. :-)

— Afrazier

@afrazier - anche se penso che la risposta aggiornata di ThouArtNotDoc sia una risposta generale migliore. Devo concordare sul fatto che le copie shadow stanno probabilmente svolgendo un ruolo nella situazione del PO. Ho trovato anche questo: "Se si prevede di deframmentare i volumi su cui sono abilitate le copie shadow, si consiglia di utilizzare una dimensione del cluster (o unità di allocazione) di almeno 16 KB. In caso contrario, il numero di modifiche causate dal processo di deframmentazione può far sì che le copie shadow vengano eliminate più rapidamente del previsto. " - MS: "Progettare una strategia per la copia shadow" technet.microsoft.com/en-us/library/cc728305(WS.10).aspx

— Ƭᴇcʜιᴇ007

@afrazier: confermato. Tutti i precedenti punti di ripristino del sistema sono spariti. Nella configurazione, ho impostato il 12% come spazio massimo consentito per le copie shadow, quindi 10 GB non sono irragionevoli. D'altra parte, ho appena installato un gioco da 9 GB, che avrebbe potuto semplicemente sovrascrivere i punti di ripristino precedenti.

— Goweon,

@firebat: lo spazio utilizzato da Ripristino configurazione di sistema serve per tenere traccia delle modifiche ai file esistenti (istantanei), non a quelli nuovi. L'installazione di un nuovo gioco non influirebbe sul ripristino dello spazio del sistema, ma una patch di grandi dimensioni potrebbe.

— Afrazier

Ogni frammento deve essere rintracciato da qualche parte. Ciò richiede spazio di archiviazione (all'interno dell'impianto idraulico del file system, non roba a cui si intende accedere direttamente).

Un esempio: supponiamo di avere un singolo file con 1000 frammenti. Quindi il tuo file viene archiviato attraverso una raccolta di blocchi casuali. Invece che in un singolo blocco continuo. Ciò significa che il file frammentato richiede 1000 volte più spazio di archiviazione all'interno dell'impianto idraulico del file system, anche solo per la memorizzazione degli indirizzi per ciascun frammento. L'impianto idraulico del file system mantiene piccoli dizionari / database / mappe / tabelle / elenchi nella posizione di ciascun frammento del file. Quindi, per l'impianto idraulico del file system, la memorizzazione di un elenco di un singolo puntatore di frammento non richiede molto spazio, rispetto a un elenco di 1000 puntatori di frammento.

Ma hey, forse mi sbaglio ...

Modifica: informazioni di supporto da qui :

Quando un flusso di dati non residenti è troppo frammentato, quindi la sua mappa di allocazione effettiva non può rientrare interamente nel record MFT, la mappa di allocazione può anche essere memorizzata come flusso non residente, con solo un piccolo flusso residente contenente l'allocazione indiretta mappare all'effettiva mappa di allocazione non residente del flusso di dati non residenti.

Traduzione: se si dispone di una forte frammentazione, le ipotesi generali sull'impianto idraulico del file system non verranno applicate. Come tale, il FS deve prendere misure per accogliere la frammentazione e finire per costare spazio di archiviazione aggiuntivo, solo per gestire i frammenti. Esattamente la mia ipotesi dal primo posto.

Modifica: dato quanto sopra, sembra che perdere 10 GB solo a causa della frammentazione dei file sia pazzesco. Scommetto che durante la deframmentazione, hai avuto qualche corruzione del file system comune che è stata corretta automaticamente. Penso che non solo tu abbia avuto una grande frammentazione, ma anche file parzialmente eliminati che occupano spazio di archiviazione. Sarebbe stato bello vedere un registro scandisk da quella deframmentazione (o una serie di scandisk prima della deframmentazione)

— James T Snell
fonte

PS: deve essere stata una frammentazione hardcore.

— James T Snell,

Non so se sia una ragione valida per un tale aumento del consumo di memoria dopo la deframmentazione. Ma l'ho notato molte volte, se hai un punto di ripristino del sistema che è piuttosto vecchio (in genere non succede se esegui regolarmente l'utilità di pulizia del disco) e quindi deframmenta dopo che molti dati sono stati raccolti sull'unità C, il consumo di memoria aumenta dal nulla, ma se si elimina quel punto di ripristino, si pulisce la memoria occupata. Beh, tecnicamente, potrebbe non avere alcun senso, ma mi è successo molte volte, dal momento che gli straordinari, i punti di ripristino occupano memoria.

— Kushal,

Non so, 10G sembra molto, ma IME, i dischi molto completi tendono a frammentarsi molto più rapidamente rispetto ai dischi meno frammentati. Se fosse stato> 85% prima (dato che i suoi probi significavano 85GiB ma disco da 100 GB), e forse nel frattempo più pieno, avrebbe potuto avere una frammentazione incredibilmente alta e prestazioni orrende conseguenti.

— Bernd Haug,

A meno che il blocco su quel volume non sia oscenamente alto, personalmente non riesco a credere che 10 GB di spazio vengano liberati semplicemente non monitorando i frammenti. Con una dimensione di 4096k e supponendo che ogni frammento richieda un blocco completo solo per tracciare (che è falso), occorrerebbero 2,5 milioni di frammenti precedentemente tracciati ma non più per liberare così tanto spazio.

— CarlF,

@Doc: un puntatore non richiede un intero blocco. Se (come è probabile) ogni blocco di allocazione è composto da più settori, hai bisogno di meno puntatori poiché ci sono meno blocchi da tracciare per i tuoi dati - quindi il sovraccarico massimo possibile per tracciare tutti i frammenti sarà molto inferiore al 3%. Non conosco i dettagli esatti di NTFS, ma con i sistemi di archiviazione FAT (relativamente inefficienti), non è ancora possibile ottenere un sovraccarico del 10% per la tabella di allocazione dei file (quei puntatori di tracciamento dei frammenti) a cui il FAT è stato chiamato.

— Steve314,