Como nos deparamos com o sistema de arquivos (hierárquico) como estrutura básica de dados?

Sou autodidata e não tenho um diploma em CS. Quanto mais aprendi sobre estrutura de dados, mais me pergunto, nos dias de hoje, como ainda estamos sobrecarregados com o sistema de arquivos, com diretórios e arquivos, como a estrutura básica de armazenamento de dados no sistema operacional?

Entendo a simplicidade, mas parece que hoje em dia pode haver mais opções disponíveis nativamente. Tanto quanto sei, o único projeto para melhorar a funcionalidade básica do sistema de arquivos foi o ReiserFS, onde você pode dizer qual linha de um arquivo foi alterada por quem e quando.

Por exemplo, se eu pudesse ter tags nativas para arquivos, onde eu poderia marcar imagens, diagramas, documentos de processamento de texto, um repositório de códigos inteiro, todos pertencentes a um único projeto, isso seria realmente útil para mim. Como estou preso ao paradigma do sistema de arquivos, sei que poderia colocar todos eles em uma única pasta / diretório, mas e se eles já existirem em diretórios diferentes e precisarem ficar lá? Eu sei que existem programas por aí que podem fazer isso, mas por que eles não estão no sistema de arquivos?

Algo que seria bom ter é algum tipo de recurso relacional no sistema de arquivos, como você obtém com RDBMSes. Entendo que isso deveria fazer parte do Vista / 7, mas também caiu na lista de recursos.

Certamente, qualquer programa pode armazenar um arquivo binário e ter qualquer estrutura de dados que deseje, por que o sistema operacional não poderia oferecer maneiras mais complexas de armazenar dados, além da simples hierarquia do sistema de arquivos?

Comece com isso: http://en.wikipedia.org/wiki/Unix_File_System

Leia isto: http://www.unix.org/what_is_unix/history_timeline.html

Em seguida, leia o seguinte: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Há uma resposta simples para "por que o sistema operacional não poderia oferecer maneiras mais complexas de armazenar dados, além da simples hierarquia do sistema de arquivos?"

Porque é demais para o sistema operacional fazer.

É para isso que servem as bibliotecas e os pacotes de aplicativos.

A Oracle, por exemplo, venderá a você um conjunto de recursos semelhantes ao sistema de arquivos que você gerencia com o conjunto de ferramentas Oracle.

O Python usa a biblioteca DBM para criar estruturas de armazenamento em disco muito sofisticadas.

CouchDB e Mongo (e outros) são estruturas de armazenamento muito sofisticadas que oferecem alguns recursos semelhantes a bancos de dados.

O ponto é que o sistema operacional deve fazer o mínimo e tudo é um complemento.

A resposta curta é: As pessoas comuns entendem o sistema de arquivos. Isso lembra um arquivo de gabinete. Pense em páginas da web e até em aplicativos Fat, por que você acha que Tabssão tão populares? As pessoas podem se identificar com elas e entendê-las rapidamente.

Imagem tentando ensinar a vovó a procurar um arquivo de banco de dados com base em tags de propriedade. Com o sistema de arquivos, a vovó sabe que o arquivo é simplesmente onde ela o colocou .

Mesmo com o WinFS, não acho que a MS se livraria da aparência do sistema de arquivos.

Há um pouco de verdade em todas as respostas aqui, mas não acho que seja toda a verdade.

O que você lista são principalmente recursos que fazem muita falta todos os dias por usuários e desenvolvedores.

As pessoas não entendem o sistema de arquivos baseado em árvore mais do que entenderiam um sistema baseado em DAG.

E não há absolutamente nenhuma desculpa para os apêndices patéticos de nomes de arquivos chamados extensões. Eles não são apenas completamente inadequados para a sua finalidade (identificação do tipo de arquivo), mas também uma fonte inesgotável de usuários.

A razão pela qual ainda os estamos usando é uma mistura de uma atitude "que funcionará" e a real necessidade de manter a compatibilidade com códigos mais antigos. Uma nova abordagem para armazenar arquivos significaria uma mudança radical na API básica de E / S de arquivos, tornando a maioria dos códigos existentes inúteis. Ou você tem que andar na ponta dos pés, mantendo a API herdada. Lembre-se de PROGRA ~ 1.

Penso pelas razões acima, embora o futuro possa ter sistemas de arquivos mais especializados para aplicativos especiais, mas enquanto as arquiteturas de desktop e laptop atuais sobreviverem, estamos presos ao sistema de arquivos amplamente baseado em árvore, com sua falta de metadados e suas horríveis pequenas extensões.

Agora eu vou mudar de lado.

Como está ao nosso redor, nunca realmente apreciamos o quão espantosamente poderosa é a metáfora da árvore. No meu disco rígido, tenho várias centenas de milhares de arquivos. Se preciso encontrar um, raramente leva mais de um minuto, mesmo que eu saiba muito pouco sobre o arquivo. Agora imagine a mesma tarefa sem nenhuma estrutura, apenas uma lista simples de nomes, rolando sem parar.

No entanto, todas as operações são diretas, não há ação assustadora à distância, nada que me faça ir embora.

Na verdade, eu implementei um repositório de documentos com metadados avançados e uma hierarquia baseada em DAG uma vez. (Não era nem mesmo um DAG de formato livre, era estritamente uma metástrutura de dois níveis e os documentos, que poderiam ser filhos de uma coleção de nível 1 ou 2. Portanto, é realmente simples.)

Obviamente, o requisito de que os nomes dos documentos fossem únicos em uma coleção tinha que permanecer.

E então os problemas começaram a fluir. E se você abrir uma coleção e alterar o nome do documento para algo que colide com uma coleção diferente à qual o documento também pertence? Exibimos uma mensagem de erro, mas os usuários ficaram completamente confusos. (Esses são os mesmos usuários que solicitaram esse requisito.)

Eles tentaram excluir um documento, mas tudo o que foi feito foi removê-lo da coleção. Por isso, ele ainda apareceu nos resultados de pesquisa. Também tentamos o contrário, mas eles estavam reclamando que excluíram um documento da coleção A e desapareceu magicamente da coleção B. Portanto, precisávamos de uma operação de "desvinculação" e de exclusão rígida.

Por fim, sofremos derrota, felizmente ainda a tempo.

As facetas extras de pesquisa que os metadados tornaram possível, funcionaram como um tratamento absoluto.

Para ser sincero, mal toco os metadados dos meus arquivos no Mac. Acho que nos últimos 5 anos usando o OSX (que suporta comentários e assim por diante), usei metadados em talvez 2 arquivos. Não estou dizendo que é uma má ideia.

Só não tenho certeza de como a sobrecarga da marcação é pragmática para mim.

Eu acho que o melhor recurso do sistema de arquivos que eu conheço seria um sistema de versão no nível do sistema de arquivos ... que funcione entre partições. Isso foi feito no VAXen nos anos 70 e início dos 80, sem saber por que não pegou o Unix e o NTFS / Windows.

Trabalhei com sistemas de arquivos não hierárquicos em minis mais antigos, como HP3000 e Encore / Gould. Você não tinha diretórios; você tinha um grupo e uma conta, e os arquivos foram nomeados como " grupo . conta . arquivo ", como "users.jbode.myfile1", "dev.jbode.main" etc.

Agora, esses são sistemas antigos , onde as cotas individuais de espaço em disco estavam em megabytes únicos; portanto, não é necessário ter muitos níveis para organizar suas coisas, mas, na perspectiva de um usuário e programador, os sistemas hierárquicos são muito melhores.

Não vejo onde (pelo menos alguns) sistemas de arquivos atuais realmente precisam fazer muito [Editar: qualquer coisa, para ser honesto] para oferecer suporte a tags. Quando você começar a ele, apoiando Etiquetas de meios pouco mais do que alguns dados adicionais associados com um arquivo, mas não está escrito no fluxo de bytes para esse arquivo.

O NTFS (para escolher um exemplo amplamente utilizado) pode fazer isso perfeitamente: tanto quanto o NTFS se importa, um arquivo não é necessariamente um único fluxo de bytes. No NTFS, você pode associar um número arbitrário de fluxos de dados a um único nome de arquivo. Cada arquivo possui um "fluxo primário" (possivelmente vazio) que não possui um nome. No entanto, também pode ter um número arbitrário de outros fluxos, cada um dos quais deve ter um nome. Usando isso, seria realmente trivial adicionar um fluxo denominado (apenas por exemplo) "tags" a um arquivo existente e (obviamente, o suficiente) gravar suas tags nesse fluxo.

Depois disso, vem a parte um pouco mais difícil: fazer com que suas ferramentas utilizem as tags que você coloca lá. Idealmente, você provavelmente desejaria indexá-los para pesquisa rápida, para poder fazer coisas como criar um "diretório virtual" de todos os arquivos com uma tag específica.

Pelo menos da minha perspectiva, o sistema de arquivos já possui o que é necessário - ele deve armazenar e recuperar os dados, e pode fazer isso perfeitamente bem agora. Utilizar esses dados é o trabalho de outras ferramentas. Atualmente, essas ferramentas não existem, mas a infraestrutura do sistema de arquivos para suportá-las existe.

Se eu puder ser cínico por um momento, diria que é inevitável que esse recurso do NTFS permaneça quase completamente ignorado e desconhecido. Afinal, é simples de usar e não requer nenhuma API especial ou qualquer outra coisa. Você pode usá-lo perfeitamente em C, C ++ ou qualquer outra coisa que permita especificar um nome de arquivo arbitrário. Aqui está um código rápido para demonstrar a criação de um arquivo com um 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 aqui está um código para ler e exibir as tags:

#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;
}

Tudo muito simples e fácil. Observe que, embora eu tenha escrito apenas alguns dados triviais lá, você pode tratar um AFS como qualquer outro arquivo - todas as "coisas" comuns funcionam como qualquer outra coisa. Em uma exibição normal de diretório, tudo o que será exibido é o fluxo primário (por exemplo, o tamanho mostrado para o arquivo será o tamanho do fluxo primário), mas se você quiser vê-lo, também dir poderá mostrar informações sobre fluxos alternativos. com a /Rbandeira Por exemplo, uma lista para o arquivo criado acima é assim:

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