L'evoluzione dei file system

Prima che i computer siano stati sviluppati per funzionare nei sistemi operativi su disco, ogni computer è stato creato per eseguire una singola applicazione proprietaria, che aveva il controllo completo ed esclusivo dell'intera macchina. L'applicazione scriverà i dati persistenti direttamente in un disco o tamburo inviando comandi direttamente al controller del disco. L'applicazione è stata responsabile della gestione dei percorsi assoluti dei dati sul disco, assicurandosi che non sovrascrivesse i dati già esistenti. Poiché nel computer era in esecuzione una sola applicazione in qualsiasi momento, questa attività non era troppo difficile.

L'avvento dei sistemi informatici che poteva eseguire più di un'applicazione richiedeva un meccanismo per garantire che le applicazioni non scrivessero i dati degli altri. Gli sviluppatori di applicazioni hanno risolto questo problema adottando un unico standard per distinguere i settori del disco in uso da quelli liberi contrassegnandoli di conseguenza. Nel tempo, questi standard si unirono per diventare un sistema operativo su disco, che forniva vari servizi alle applicazioni, incluso un file system per la gestione dell'archiviazione permanente. Con l'avvento di un file system, le applicazioni non dovevano più occuparsi direttamente del supporto di archiviazione fisica. Al contrario, hanno semplicemente detto al file system di scrivere blocchi di dati sul disco e lasciare che il file system si preoccupi di come farlo. Inoltre, il file system ha consentito alle applicazioni di creare gerarchie di dati tramite un'astrazione nota come directory. Una directory potrebbe contenere non solo file, ma anche altre directory, che a loro volta potrebbero contenere i propri file e directory e così via.

Il file system ha fornito un singolo livello di riferimento indiretto tra le applicazioni e il disco e il risultato è che ogni applicazione ha visto un file come un singolo flusso contiguo di byte sul disco anche se il file system archiviava effettivamente il file in settori non contigui. L'indiretto ha liberato le applicazioni dalla necessità di tenere traccia della posizione assoluta dei dati in un dispositivo di archiviazione.

Attualmente, praticamente tutte le API di sistema per l'input e l'output dei file forniscono applicazioni per la scrittura di informazioni in un file flat. Le applicazioni vedono questo file come un singolo flusso di byte che può diventare più grande finché il disco non è pieno. Da molto tempo queste API sono sufficienti per le applicazioni per archiviare le informazioni persistenti. Le applicazioni hanno apportato innovazioni significative nel modo in cui gestiscono un singolo flusso di informazioni per fornire funzionalità come i salvataggi incrementali "veloci".

Tuttavia, in un mondo di oggetti componente, l'archiviazione dei dati in un singolo file flat non è più efficiente. Proprio come i file system nascevano dalla necessità di più applicazioni di condividere lo stesso supporto di archiviazione, quindi, ora, gli oggetti componente richiedono un sistema che consente loro di condividere l'archiviazione all'interno del framework concettuale di un singolo file. Anche se è possibile archiviare gli oggetti separati usando l'archiviazione file flat convenzionale, se uno degli oggetti aumenta di dimensioni o se si aggiunge semplicemente un altro oggetto, diventa necessario caricare l'intero file in memoria, inserire il nuovo oggetto e quindi salvare l'intero file. Questo processo può richiedere molto tempo.

La soluzione fornita da COM consiste nell'implementare un secondo livello di riferimento indiretto: un file system all'interno di un file. L'archiviazione file flat richiede che una grande sequenza contigua di byte sul disco venga manipolata tramite un unico handle del file con un unico puntatore di ricerca. Al contrario, l'archiviazione strutturata COM definisce come trattare una singola entità di file system come una raccolta strutturata di due tipi di oggetti, ovvero archivi e flussi, che agiscono come directory e file.