In che modo siamo stati caricati con il filesystem (gerarchico) come struttura dati di base?

Inizia con questo: link

Leggi questo: link

Quindi leggi questo: link

C'è una semplice risposta a "perché il sistema operativo non può offrire modi più complessi di memorizzazione dei dati, al di là della semplice gerarchia del filesystem?"

Perché è troppo per il sistema operativo.

Ecco a cosa servono le librerie e i pacchetti di applicazioni.

Oracle, ad esempio, ti venderà un set di funzionalità simile al file system che gestisci con il set di strumenti Oracle.

Python utilizza la libreria DBM per creare strutture di archiviazione su disco molto sofisticate.

CouchDB e Mongo (e altri) sono strutture di storage molto sofisticate che offrono alcune funzionalità simili a quelle del database.

Il punto è che il sistema operativo dovrebbe fare il minimo e tutto è un componente aggiuntivo.

La risposta breve è: la gente comune capisce il file system. Ricorda loro un cabinet di file. Pensa alle pagine web e persino alle app grasse, perché pensi che Tabs sia così popolare? Le persone possono identificarsi con loro e comprenderle rapidamente.

Imaging che tenta di insegnare a nonna a cercare un DB per File in base a tag di proprietà. Con il file system, nonna sa che il file è semplicemente dove lo mette .

Anche con WinFS non penso che MS abbia intenzione di eliminare l'aspetto del file system.

C'è una piccola verità in ogni risposta qui, ma non penso che sia tutta la verità.

Ciò che elencherai sono per lo più funzioni che sono quotidianamente perse da utenti e sviluppatori.

Le persone non capiscono il file system basato sull'albero più di quanto non ne capirebbero uno basato su DAG.

E non ci sono assolutamente scuse per le appendici patetiche dei nomi di file chiamati estensioni. Non solo sono completamente inadatti al loro scopo (identificando il tipo di file) ma anche una fonte inesauribile di fastidi per gli utenti.

Il motivo per cui li stiamo ancora utilizzando è un misto di un atteggiamento "che farò" e la reale necessità di mantenere la compatibilità con il vecchio codice. Un nuovo approccio alla memorizzazione dei file significherebbe un cambiamento radicale nell'API I / O di file di base, rendendo inutilizzabile la maggior parte del codice esistente. O quello o devi andare in punta di piedi intorno a loro, mantenendo l'API legacy. Ricorda PROGRA ~ 1.

Penso per le ragioni di cui sopra, anche se il futuro potrebbe contenere file system più specializzati per applicazioni speciali, ma mentre le architetture di PC desktop e laptop del presente sopravvivono, siamo bloccati con il file system in gran parte ad albero con la sua mancanza dei metadati e delle sue orribili estensioni.

Ora ho intenzione di cambiare lato.

Dato che è tutto intorno a noi, non apprezziamo mai quanto sia strabiliante la metafora dell'albero. Sul mio disco fisso ho diverse centinaia di migliaia di file. Se devo trovarne uno, raramente ci vuole più di un minuto, anche se so molto poco del file. Ora immagina lo stesso compito senza alcuna struttura, solo una lista di nomi piatta, scorrendo all'infinito.

Eppure tutte le operazioni sono semplici, non c'è azione spettrale a distanza, nulla che possa farmi finire wtf.

In realtà, ho implementato un archivio documenti con metadati ricchi e una gerarchia basata su DAG una volta. (Non era nemmeno un DAG a forma libera, era strettamente una metastruttura a due livelli e i documenti, che potevano essere figli di una raccolta di livello 1 o di livello 2. Quindi è molto semplice.)

Ovviamente, il requisito che i nomi dei documenti dovrebbero essere unici all'interno di una collezione doveva rimanere.

E poi i problemi hanno iniziato a fluire. Cosa succede se si apre una raccolta e si modifica il nome del documento in qualcosa che si scontra in una collezione diversa a cui appartiene anche il documento? Abbiamo visualizzato un messaggio di errore, ma gli utenti erano completamente sconcertati. (Questi sono gli stessi utenti che hanno richiesto questo requisito).

Hanno provato a eliminare un documento, ma tutto ciò che è stato fatto è stato rimuoverlo dalla raccolta. Quindi è ancora presente nei risultati di ricerca. Abbiamo provato anche il contrario, ma poi si sono lamentati del fatto che hanno cancellato un documento dalla raccolta A e che è scomparso magicamente dalla raccolta B. Quindi avevamo bisogno sia di un "link" che di un'operazione di cancellazione.

Alla fine abbiamo ammesso la sconfitta, fortunatamente ancora in tempo.

Le sfaccettature extra di ricerca rese possibili dai metadati hanno comunque funzionato.

Per essere onesti, tocco a malapena i metadati sui miei file sul Mac. Penso che negli ultimi 5 anni di utilizzo di OSX (che supporta i commenti e così via), ho utilizzato i metadati su 2 file. Non dire che sia una cattiva idea.

Non sono sicuro di come il sovraccarico del tagging sia pragmatico per me.

Penso che la caratteristica di filesystem più bella che conosca sia un sistema di controllo delle versioni a livello di file system ... che funziona con le partizioni incrociate. È stato fatto su VAXen negli anni '70 e nei primi anni '80, non so perché non ha avuto problemi con Unix e NTFS / Windows.

Ho lavorato con file system non gerarchici su vecchi minis come HP3000 e Encore / Gould. Non hai avuto directory; hai avuto un gruppo e un account e i file sono stati nominati come " gruppo . account . file ", come "users.jbode.myfile1" , "dev.jbode.main", ecc.

Ora, questi sono vecchi sistemi, dove le singole quote di spazio su disco erano nei singoli megabyte, quindi non è che avessi bisogno di troppi livelli per organizzare le tue cose, ma dal punto di vista gerarchico di un utente e programmatore i sistemi sono molto più belli.

Non vedo dove (almeno alcuni) i file system attuali debbano davvero fare molto [Modifica: qualsiasi cosa, per essere onesti] per supportare i tag. Quando ci arrivi, i tag di supporto significano poco più di alcuni dati aggiuntivi associati con un file, ma non sono scritti nello stream di byte per quel file.

NTFS (per scegliere un esempio in wide use) può farlo bene: per quanto riguarda NTFS, un file non è necessariamente un singolo flusso di byte. Su NTFS è possibile associare un numero arbitrario di flussi di dati con un singolo nome di file. Ogni file ha uno "stream primario" (eventualmente vuoto) che non ha un nome. Può anche, tuttavia, avere un numero arbitrario di altri flussi, ognuno dei quali deve avere un nome. Usando questo, sarebbe veramente banale aggiungere un flusso chiamato (solo per esempio) "tag" a un file esistente e (ovviamente abbastanza) scrivere i tag su quel flusso.

Dopo questo arriva la parte un po 'più difficile: ottenere i tuoi strumenti per utilizzare i tag che hai inserito. Idealmente, probabilmente vorrai indicizzarli per una ricerca veloce, così saresti in grado di fare cose come creare una "directory virtuale" di tutti i file con un tag specifico.

Almeno dal mio punto di vista, il file system ha già ciò che è necessario, però - si suppone di archiviare e recuperare i dati, e può farlo perfettamente bene al momento. Fare uso di quei dati è il lavoro di altri strumenti. Quegli strumenti non esistono al momento, ma l'infrastruttura del file system per supportarli fa.

Se posso essere cinico per un momento, direi che era inevitabile che questa funzionalità di NTFS rimanesse quasi completamente ignorata e sconosciuta. Dopo tutto, è semplice da usare e non richiede alcuna API speciale o altro. Puoi usarlo abbastanza bene in C, C ++ completamente portatile o qualsiasi altra cosa che ti permetta di specificare un nome di file arbitrario. Ecco un breve codice per dimostrare la creazione di un file con un AFS:

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

E, ecco un codice per leggere e visualizzare i tag:

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

Tutto molto semplice e facile. Nota che sebbene io abbia scritto solo un piccolo bit di dati, puoi trattare un AFS come qualsiasi altro file - tutte le solite "cose" funzionano come con qualsiasi altra cosa. In una normale visualizzazione di directory, tutto ciò che verrà visualizzato è lo stream primario (ad esempio, la dimensione mostrata per il file sarà la dimensione del flusso principale), ma se si desidera vederlo, dir può mostra anche informazioni sugli stream alternativi con il flag /R . Ad esempio, un elenco per il file creato sopra appare come segue:

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes