La deframmentazione recupera molto spazio: è vera questa affermazione?.

[Antonio55]

Ho questa idea: se un file è frammentato ci saranno tanti puntatori che puntano alle zone del file frammentato.
Mentre un file non frammentato non ha bisogno dei puntatori o perlomeno ne avrà bisogno di solo 2 che gli dicono l'inizio e la fine del file.
Quindi l'affermazione: che con la deframmentazione non si recupera spazio per me è falsa.
Qualcuno mi può chiarire le idee?
Antonio55

[URANIO]

Non ricordo sinceramente come funziona, forse si recupera spazio, ma veramente in maniera minimale.
Probabilmente guadagni spazio se TUTTI i file sono PESANTEMENTE frammentati, ma è un caso praticamente impossibile.
Voglio dire, un file da 1GB frammentato in 1000 parti occuperà magari 1K in piu'....

[optime]

teoricamente potrebbe recuperare spazio, ma visto che i puntatori sono in una tabella che viene comunque allocata, lo spazio recuperato è zero o risibile. Quello che guadagni è la velocità di lettura: o meglio, guadagnavi, perché con gli attuali SDD la deframmentazione è inutile se non dannosa.

[Franzsoft]

è tutto relativo
risparmiare in bit su un byte è tanta roba 1k su un tera è una goccia nell'Oceano
per quanto riguarda lo spazio adesso ne recuperi poco ma per quanto riguarda le prestazioni la deframmentazione aiuta molto perchè il tempo maggiore che un applicazione spreca è proprio nell'accesso al'IO e l'hardisk in primis
Per il sistema operativo infatti assicurarsi un file contiguo per la memoria chache era (forse lo è ancora) importantissimo

[Antonio55]

teoricamente potrebbe recuperare spazio, ma visto che i puntatori sono in una tabella che viene comunque allocata, lo spazio recuperato è zero o risibile. Quello che guadagni è la velocità di lettura: o meglio, guadagnavi, perché con gli attuali SDD la deframmentazione è inutile se non dannosa.

Io penso che non serva una tabella grande per un file contiguo, ma ne serva una grande per un file frammentato. E poi concordo sulle prestazioni migliori di un file contiguo.

[optime]

è tutto relativo
risparmiare in bit su un byte è tanta roba 1k su un tera è una goccia nell'Oceano
per quanto riguarda lo spazio adesso ne recuperi poco ma per quanto riguarda le prestazioni la deframmentazione aiuta molto perchè il tempo maggiore che un applicazione spreca è proprio nell'accesso al'IO e l'hardisk in primis
Per il sistema operativo infatti assicurarsi un file contiguo per la memoria chache era (forse lo è ancora) importantissimo

non con gli SSD, dove ogni operazione di deframmentazione riduce la vita del disco senza portare benefici

[optime]

Io penso che non serva una tabella grande per un file contiguo, ma ne serva una grande per un file frammentato. E poi concordo sulle prestazioni migliori di un file contiguo.

parlo di questa tabella https://it.wikipedia.org/wiki/Master_File_Table che esiste a prescindere

[optime]

per le prestazioni con/senza defrag di un SSD buttate un occhio qui https://www.crucial.com/articles/abo...-defrag-an-ssd

[URANIO]

Sugli HDD un disco frammentato è un problema perchè meccanicamente deve continuare a ruotare in cerca dello spazio da leggere(e gira solo in un senso), se i dati sono contigui il disco gira solo dello spazio che serve e quindi è più veloce, sugli SSD invece potrebbe essere anche completamente frammentato, il file viene letto per indirizzi.

[Antonio55]

parlo di questa tabella https://it.wikipedia.org/wiki/Master_File_Table che esiste a prescindere

Da quello che ho letto e se ho capito bene per ogni file allocato ci vogliono 1000 byte per tenere gli attributi e indirizzi di un singolo file. 1000 byte per 1000 file sono 1.000.000. 1 mega di spazio su disco e se sono 100.000 file, 100 mega di spazio solo per tenere gli attributi dei file. Mi sembra un po' troppo. Ma se questa è l'architettura devo ricredermi.