Un'altra possibile procedura, più operativa, potrebbe essere quella che in gergo informatico si definisce reverse engineering, che consisterebbe in questo caso nel "disassemblare" il programma di deframmentazione fornito da Windows 98 ed "osservare" quella parte di codice che effettua la deframmentazione. Ma ciò è sia illegale (perché l'accordo di autorizzazione di Windows 98 non permette di "smontare" quel programma; in realtà poi, la fattibilità di questa operazione dipende anche dalle leggi della nazione dove il programma è in uso) sia molto difficile e dispendioso dal punto di vista tecnico.

In generale, è possibile dire che líalgoritmo di deframmentazione del disco è un processo di "riarrangiamento" di tutte le parti che compongono i file su di esso memorizzati, in modo tale che questi vengano riletti in un periodo di tempo più breve, migliorando così anche líefficienza del computer.

È difficile dire complessivamente come migliorare le prestazioni dellíalgoritmo stesso, tanto meno quelle relative a Windows 98, per gli argomenti suddetti.

Per avere più informazioni sulla deframmentazione del disco, nel caso sia in uso il Windows 98, può consultare il libro di Craig Stinson, Running Microsoft Windows 98, Microsoft Press (1998). Alcuni riferimenti al capitolo 16 di questo testo (che contiene una spiegazione su cosa sia e su come agisca la deframmentazione) li può trovare consultando in rete la pagina:

http:// www.microsoft.com/ mspress/books/ sampchap/ 1359.asp

Per comprendere il problema della frammentazione, dobbiamo capire come vengono memorizzati i file in un disco. L'argomento è alquanto tecnico per cui procederò con una metafora. In prima approssimazione, possiamo paragonare un disco a un archivio composto da centinaia, migliaia di quaderni ad anelli, quelli con i fogli rimovibili. Ogni foglio corrisponde a un blocco di disco, ogni quaderno corrisponde a un cilindro. Quando l'archivista deve scrivere un documento (un file) nel nostro archivio, cerca un quaderno con un foglio libero, e comincia a riempire le pagine una di seguito all'altra. Tuttavia, può succedere che così facendo incontra una pagine già scritta, occupata da un altro file. L'archivista deve quindi interrompere la scrittura sequenziale, cercare un altro foglio libero (eventualmente anche su un altro quaderno) e riprendere la scrittura. è chiaro che, procedendo in questo modo, il documento non è stato scritto tutto di seguito (contiguamente), ma a "spezzoni" (i frammenti), potenzialmente molto distanti fra di loro. Una successiva lettura del file diventa quindi problematica perché anche sapendo dove inizia il file, l'archivista deve sapere quante pagine contigue deve leggere, e a quale pagina di quale quaderno deve poi continuare. Per risolvere il primo problema, l'archivista mantiene un quaderno speciale, il primo del primo scaffale più alto, intitolato FAT (File Allocation Table). In tale quaderno viene annotata la sequenza delle pagine componenti ogni file; quindi il nostro archivista per leggere un documento fa continuamente riferimento all'indice scritto nella FAT, che gli indica quali pagine di quali quaderni deve andare a reperire.

Ovviamente, questo modo di procedere è assai faticoso, perché per leggere o scrivere i documenti, l'archivista deve continuamente cercare, aprire, scorrere, leggere, e chiudere quaderni a ogni salto di frammento, facendo continuamente delle letture o modifiche sul quaderno FAT (che ricordiamo, è a una estremità dell'archivio, lontano da tutto il resto per giunta) per mantenere traccia di ciò che sta facendo. E l'archivio diventa rapidamente una intricata accozzaglia di pagine disordinate e scollegate l'una dall'altra. Per ridurre questa fatica, l'archivista ogni tanto decide di riorganizzare l'intero archivio: appende fuori della porta un cartello "chiuso per riordino", chiama una decina di baldi inservienti e comincia a scambiare le pagine tra i vari quaderni, in modo da ricollocare contiguamente i frammenti separati di ogni file. Scorre le righe del quaderno FAT, riconoscendo quali documenti non sono stati scritti contiguamente. Ogni volta che trova un frammento, scambia un po' di pagine tra due file, in modo da ricollegare il frammento al resto del documento che lo precede; la modifica viene immediatamente scritta nel quaderno FAT, per non renderlo inconsistente. L'archivista continua così, rilocando un file dopo l'altro, uno in coda all'altro dall'inizio alla fine dell'archivio. Quando arriva alla fine, i documenti sono in gran parte contigui e le pagine bianche sono raccolte tutte alla fine, ma alcuni file possono essere ancora frammentati (per esempio, quelli che erano in uso da altri archivisti, sia in lettura che in scrittura - ecco perché è bene non usare il computer mentre si deframmenta il disco); quindi, il nostro archivista riorganizzatore ricomincia dall'inizio e ripete fino a che non si stanca, o non trova più nessun file da deframmentare. Naturalmente, questa situazione così pulita dura poco: non appena un file tutto bello contiguo deve essere modificato (per esempio, allungato), ecco che si crea un nuovo frammento lontano dal resto del file, e siamo daccapo.

Uscendo dalla metafora, dovrebbe essere chiaro a questo punto che il problema della frammentazione dipende dal file system, e di come gestisce lo spazio del disco. File system diversi adottano politiche diverse, più o meno efficienti. I file system di Windows (FAT prima e NTFS poi) sono particolarmente soggetti al fenomeno della frammentazione, in quanto non c'è a priori nessun legame tra le posizioni dei frammenti e della loro distanza dalla FAT (Questa caratteristica ha fatto fiorire, tra l'altro, una fruttuosa industria di costose utility di deframmentazione).

I sistemi Unix, d'altro canto, hanno affrontato radicalmente il problema seguendo il principio che è meglio prevenire che curare. Circa 20 anni fa venne sviluppato il Berkeley Fast File System, così avanzato che è stato la base di file system di uso odierno come UFS (Unix File System) e EXT2 (il file system di Linux). Fra le molte innovazioni, vale la pena citare che l'indice delle pagine allocate non viene mantenuto in un quaderno a parte, separato, bensì ogni quaderno ha il suo indice locale, per le sue pagine. Inoltre, quando un file viene scritto, se non può essere scritto tutto contiguamente, si cerca di allocare i frammenti nei cilindri contigui a quello di partenza. Statisticamente si è visto che se un file system UFS viene mantenuto occupato per non più dell'80 %, la quantità di file frammentati rimane attorno al 2-3 %, rendendo praticamente irrisorio ogni miglioramento ottenibile da una costosa deframmentazione ed infatti, non esistono strumenti per deframmentare un EXT2 o un UFS.