Come siamo stati sellati dal filesystem (gerarchico) come struttura di dati di base?

Sono autodidatta e non ho una laurea CS. Più ho imparato a conoscere la struttura dei dati, più mi chiedo, al giorno d'oggi, come siamo ancora sellati dal filesystem, con directory e file, come struttura di archiviazione dei dati di base sul sistema operativo?

Capisco la semplicità, ma al giorno d'oggi sembra che ci potrebbero essere più opzioni disponibili in modo nativo. Per quanto ne so, l'unico progetto per migliorare la funzionalità di base del filesystem era ReiserFS, in cui si poteva dire quale riga di un file era stata modificata da chi e quando.

Ad esempio, se potessi avere una codifica nativa per i file, dove potrei etichettare immagini, diagrammi, documenti di elaborazione testi, un intero repository di codice, il tutto come appartenente a un singolo progetto, sarebbe davvero utile per me. Dato che sono bloccato nel paradigma del filesystem, so che potrei metterli tutti in una singola cartella / directory, ma cosa succede se esistono già in directory disparate e devono rimanere lì? So che ci sono programmi là fuori che possono farlo, ma perché non sono nel filesystem?

Qualcosa che sarebbe bello avere è una sorta di funzionalità relazionale nel filesystem, come si ottiene con RDBMS. Capisco che ciò avrebbe dovuto far parte di Vista / 7, ma che è caduto anche dall'elenco delle funzionalità.

Certo, qualsiasi programma può archiviare un file binario e avere qualsiasi struttura di dati in esso desiderata, perché il sistema operativo non potrebbe offrire modi più complessi di archiviazione dei dati, al di là della semplice gerarchia del filesystem?

Inizia con questo: http://en.wikipedia.org/wiki/Unix_File_System

Leggi questo: http://www.unix.org/what_is_unix/history_timeline.html

Quindi leggi questo: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

C'è una semplice risposta a "perché il sistema operativo non è in grado di offrire modi più complessi di archiviazione dei dati, oltre alla semplice gerarchia del filesystem?"

Perché è troppo per il sistema operativo.

Ecco a cosa servono le librerie e i pacchetti applicativi.

Oracle, ad esempio, ti venderà un set di funzionalità simili a 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 archiviazione molto sofisticate che offrono alcune funzionalità simili a database.

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

La risposta breve è: ogni giorno le persone capiscono il file system. Ricorda loro un file cabinet. Pensa alle pagine Web e persino alle app Fat, perché pensi che Tabssiano così popolari? Le persone possono identificarsi con loro e capirle rapidamente.

L'imaging sta cercando di insegnare alla nonna a cercare un DB per un file basato su tag di proprietà. Con il file system, la nonna sa che il file è semplicemente dove lo ha inserito .

Anche con WinFS non credo che MS si sarebbe sbarazzata dell'aspetto del file system.

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

Ciò che elenchi sono per lo più caratteristiche che ogni giorno gli utenti e gli sviluppatori sono molto persi.

Le persone non capiscono il file system basato su alberi più di quanto non capiscano uno basato su DAG.

E non ci sono assolutamente scuse per le patetiche appendici dei nomi dei file chiamati estensioni. Non sono solo del tutto inadatti al loro scopo (identificare il tipo di file) ma sono anche una fonte infinita di fastidio per gli utenti.

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

Penso per i motivi 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 basato su alberi con la sua mancanza di metadati e le sue orribili piccole estensioni.

Adesso cambierò lato.

Perché è tutto intorno a noi, non apprezziamo mai davvero quanto sia incredibilmente potente la metafora dell'albero. Sul mio disco rigido 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 un elenco piatto di nomi, che scorre all'infinito.

Eppure tutte le operazioni sono semplici, non c'è azione spettrale a distanza, niente che mi faccia andare avanti.

In realtà, una volta ho implementato un archivio documenti con metadati avanzati e una gerarchia basata su DAG. (Non era nemmeno un DAG in formato libero, era rigorosamente una metastruttura a due livelli e i documenti, che potevano essere figli di una raccolta di livello 1 o di livello 2. Quindi è davvero semplice.)

Ovviamente, il requisito secondo cui i nomi dei documenti dovrebbero essere univoci all'interno di una raccolta 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 raccolta 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 avevano richiesto questo requisito.)

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

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

Le sfaccettature di ricerca extra rese possibili dai metadati hanno funzionato in modo assoluto.

Ad essere sincero, 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 usato i metadati su forse 2 file. Non dire che è una cattiva idea.

Non sono sicuro di come il sovraccarico dell'etichettatura sia pragmatico per me.

Penso che la più bella caratteristica del filesystem che conosco sarebbe un sistema di versioning a livello di filesystem ... che funziona su più partizioni. È stato fatto su VAXen negli anni '70 e nei primi anni '80, non so perché non ha funzionato con Unix e NTFS / Windows.

Ho lavorato con file system non gerarchici su minis più vecchi come HP3000 ed Encore / Gould. Non avevi directory; avevi un gruppo e un account e i file venivano denominati " gruppo . account . file ", come "users.jbode.myfile1", "dev.jbode.main", ecc.

Ora, questi sono vecchi sistemi, in cui le singole quote di spazio su disco erano nei singoli megabyte, quindi non è come se avessi bisogno di troppi livelli per organizzare le tue cose, ma dal punto di vista dei sistemi gerarchici dell'utente e del programmatore sono molto più carini.

Non vedo dove (almeno alcuni) i file system attuali debbano davvero fare molto [Modifica: qualsiasi cosa, a dire il vero] per supportare i tag. Quando ci si arriva, i tag di supporto significano poco più di alcuni dati extra associati a un file, ma non vengono scritti nel flusso di byte per quel file.

NTFS (per scegliere un esempio ampiamente utilizzato) 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 a un singolo nome di file. Ogni file ha un "flusso primario" (possibilmente vuoto) che non ha un nome. Tuttavia, può anche avere un numero arbitrario di altri flussi, ognuno dei quali deve avere un nome. Usando questo, sarebbe davvero banale aggiungere uno stream chiamato (solo per esempio) "tag" a un file esistente e (ovviamente abbastanza) scrivere i tuoi tag su quello stream.

Dopodiché arriva la parte un po 'più difficile: ottenere i tuoi strumenti per utilizzare i tag che metti lì. Idealmente, probabilmente dovresti indicizzarli per una ricerca veloce, quindi potresti 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: dovrebbe archiviare e recuperare i dati, e può farlo perfettamente bene in questo momento. Fare uso di quei dati è il lavoro di altri strumenti. Tali strumenti attualmente non esistono, ma l'infrastruttura del file system che li supporta.

Se potessi essere cinico per un momento, direi che era inevitabile che questa funzionalità di NTFS rimanesse quasi completamente ignorata e sconosciuta. Dopotutto, è 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;
}

Ed 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 anche se ho scritto solo un po 'di dati banali lì, puoi trattare un AFS proprio come qualsiasi altro file - tutte le solite "cose" funzionano esattamente come con qualsiasi altra cosa. In una normale visualizzazione della directory, tutto ciò che verrà visualizzato è il flusso principale (ad es., La dimensione mostrata per il file sarà la dimensione del flusso primario), ma se vuoi vederlo, dir puoi mostrare anche informazioni su flussi alternativi con la /Rbandiera. Ad esempio, un elenco per il file creato sopra è simile al seguente:

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