Por que o sistema de arquivos do Linux foi projetado como uma única árvore de diretórios?

Alguém pode explicar por que o Linux foi projetado como uma única árvore de diretórios?

Enquanto no Windows podemos ter várias unidades como C:\, e D:\, há uma única raiz no Unix. Algum motivo específico aí?

Como o sistema de arquivos Unix é anterior ao Windows há muitos anos, pode-se reformular a pergunta para "por que o Windows usa um designador separado para cada dispositivo?".

Um sistema de arquivos hierárquico tem a vantagem de encontrar qualquer arquivo ou diretório como filho do diretório raiz. Se você precisar mover dados para um novo dispositivo ou dispositivo de rede, o local no sistema de arquivos poderá permanecer o mesmo e o aplicativo não verá a diferença.

Suponha que você tenha um sistema em que o sistema operacional seja estático e que exista um aplicativo que tenha altos requisitos de E / S. Você pode montar / usr somente leitura e colocar / opt (se o aplicativo estiver lá) nas unidades SSD. A hierarquia do sistema de arquivos não muda. No Windows, isso é muito mais difícil, principalmente em aplicativos que insistem em viver em C: \ Arquivos de Programas \

Isso ocorre em parte por razões históricas e em parte porque faz mais sentido dessa maneira.

Multics

Multics foi o primeiro sistema operacional a introduzir o sistema de arquivos hierárquico como o conhecemos hoje, com diretórios que podem conter diretórios. Citando "Um sistema de arquivos de uso geral para armazenamento secundário" por RC Daley e PG Neumann:

A seção 2 do artigo apresenta a estrutura hierárquica dos arquivos, o que permite o uso flexível do sistema. Essa estrutura contém recursos suficientes para garantir versatilidade. (…)

Para facilitar o entendimento, a estrutura do arquivo pode ser pensada como uma árvore de arquivos, alguns dos quais são diretórios. Ou seja, com uma exceção, cada arquivo (por exemplo, cada diretório) encontra-se diretamente apontado por exatamente uma ramificação em exatamente um diretório. A exceção é o diretório raiz, ou raiz, na raiz da árvore. Embora não seja explicitamente apontado em nenhum diretório, a raiz é apontada implicitamente por um ramo fictício conhecido pelo sistema de arquivos. (…)

A qualquer momento, considera-se que um usuário está operando em algum diretório, chamado diretório de trabalho. Ele pode acessar um arquivo efetivamente apontado por uma entrada em seu diretório de trabalho simplesmente especificando o nome da entrada. Mais de um usuário pode ter o mesmo diretório de trabalho ao mesmo tempo.

Como em muitos outros aspectos, o Multics buscava flexibilidade. Os usuários podem trabalhar em uma subárvore do sistema de arquivos e ignorar o restante, e ainda se beneficiar dos diretórios para organizar seus arquivos. Diretórios também foram usados ​​para controle de acesso - o atributo READ permitiu que os usuários listassem os arquivos em um diretório, e o atributo EXECUTE permitiu que os usuários acessassem arquivos nesse diretório (isso, como muitos outros recursos, residia no unix).

Multics também seguiu o princípio de ter um único pool de armazenamento. O artigo não aborda esse aspecto. Um único pool de armazenamento combinava bem com o hardware da época: não havia dispositivos de armazenamento removíveis, pelo menos nenhum que os usuários se importassem. O Multics tinha um pool de armazenamento de backup separado, mas isso era transparente para os usuários.

Unix

O Unix se inspirou bastante no Multics, mas buscou a simplicidade, enquanto o Multics buscou a flexibilidade.

Um único sistema de arquivos hierárquico era adequado ao Unix. Como no Multics, os pools de armazenamento geralmente não eram relevantes para os usuários. No entanto, havia dispositivos removíveis e o Unix os expôs aos usuários, através dos comandos mounte umount(reservados ao "superusuário", ou seja, o administrador). Em "O sistema de compartilhamento de tempo UNIX" , Dennis Ritchie e Ken Thompson explicam:

Embora a raiz do sistema de arquivos esteja sempre armazenada no mesmo dispositivo, não é necessário que toda a hierarquia do sistema de arquivos resida nesse dispositivo. Há uma solicitação de sistema de montagem com dois argumentos: o nome de um arquivo comum existente e o nome de um arquivo especial cujo volume de armazenamento associado (por exemplo, um pacote de disco) deve ter a estrutura de um sistema de arquivos independente contendo sua própria hierarquia de diretórios . O efeito da montagem é fazer com que as referências ao arquivo comum até agora se refiram ao diretório raiz do sistema de arquivos no volume removível. Com efeito, mount substitui uma folha da árvore da hierarquia (o arquivo comum) por uma nova subárvore inteira (a hierarquia armazenada no volume removível). Após a montagem, praticamente não há distinção entre os arquivos no volume removível e os do sistema de arquivos permanente. Em nossa instalação, por exemplo, o diretório raiz reside em uma pequena partição de uma de nossas unidades de disco, enquanto a outra unidade, que contém os arquivos do usuário, é montada pela sequência de inicialização do sistema. Um sistema de arquivos montável é gerado gravando em seu arquivo especial correspondente. Um programa utilitário está disponível para criar um sistema de arquivos vazio ou pode-se simplesmente copiar um sistema de arquivos existente.

O sistema de arquivos hierárquico também tem a vantagem de concentrar a complexidade do gerenciamento de vários dispositivos de armazenamento no kernel. Isso significava que o kernel era mais complexo, mas todos os aplicativos eram mais simples como resultado. Como o kernel precisa se preocupar com dispositivos de hardware, mas a maioria dos aplicativos não, esse é um design mais natural.

janelas

O Windows rastreia sua linhagem até duas linhagens: o VMS , um sistema operacional originalmente projetado para o minicomputador VAX , e o CP / M , um sistema operacional projetado para os primeiros microcomputadores Intel.

O VMS tinha um sistema de arquivos hierárquico distribuído, Arquivos-11 . No Arquivo-11, o caminho completo para um arquivo contém um nome de nó, uma designação de conta nesse nó, um nome de dispositivo, um caminho de árvore de diretório, um nome de arquivo, um tipo de arquivo e um número de versão. O VMS tinha um poderoso recurso de nome lógico , permitindo que os atalhos fossem definidos para diretórios específicos; portanto, os usuários raramente precisavam se preocupar com o local "real" de um diretório.

O CP / M foi projetado para computadores com 64kB de RAM e uma unidade de disquete, por isso foi simplificado. Não havia diretórios, mas uma referência de arquivo poderia incluir uma indicação de unidade ( A:ou B:).

Quando o MS-DOS 2.0 introduziu diretórios, o fez com uma sintaxe compatível com o MS-DOS 1, que seguia o CP / M. Portanto, os caminhos estavam enraizados em uma unidade com um nome de uma letra. (Além disso, o caractere de barra /foi usado no VMS e no CP / M para iniciar as opções de linha de comando; portanto, um caractere diferente teve que ser usado como um separador de diretório. É por isso que o DOS e o Windows posterior usam barra invertida, embora alguns componentes internos também suportem barra )

O Windows manteve a compatibilidade com o DOS e a abordagem VMS, mantendo a noção de letras de unidade, mesmo quando elas se tornaram menos relevantes. Hoje, sob o capô, o Windows usa caminhos UNC ( originalmente desenvolvidos pela Microsoft e IBM para OS / 2 , de ascendência relacionada). Embora isso seja reservado para usuários avançados (provavelmente devido ao peso do histórico), o Windows permite a montagem através de pontos de nova análise .

Não há preocupações de segurança por trás de uma única árvore de diretórios.

Os caras que criaram o Unix tinham muita experiência com sistemas operacionais que exigiam que os usuários soubessem qual dispositivo físico continha um determinado recurso. Como parte do objetivo de um sistema operacional é criar uma máquina abstrata sobre o hardware real, eles acharam muito mais fácil dispensar os recursos de endereçamento por sua localização física e decidiram colocar tudo em uma única árvore de nomes.

Esta é apenas uma parte do gênio por trás do design do Unix .

Observe que os nomes das letras de unidade do MS-DOS que persistem no Windows moderno são um arenque vermelho aqui. Os nomes das letras de unidades não são a melhor representação de uma estrutura de sistema de arquivos com várias raízes. Eles são uma implementação simples desse sistema.

Um sistema de arquivos implementado adequadamente, que suporta múltiplas raízes, permitiria nomes arbitrários para os volumes, como dvdrom:/path/to/file.avi. Tal como o sistema, livrar-se-ia dos problemas risíveis da interface do usuário que assolam o Windows. Por exemplo, se você conectar um dispositivo como uma câmera, a interface do usuário do Windows Explorer fará com que você acredite que existe um dispositivo chamado Câmera (ou qualquer outra) e que você possui um caminho semelhante Computer\Camera\DCIM\.... No entanto, se você recortar e colar a versão textual desse caminho no Explorer, ele não funcionará porque alguns componentes do nome do caminho são uma ficção da interface do usuário, desconhecida pelo sistema operacional subjacente. Em um sistema adequadamente implementado, com múltiplas raízes, seria bom: haveria umacamera:\DCIM\...caminho que é reconhecido uniformemente em todos os níveis do sistema. Além disso, se você portasse um disco rígido antigo a partir de um PC ANTIGO, não ficaria preso a um nome de letra de unidade como F:, mas seria capaz de nomeá-lo como quiser old-disk:.

Portanto, se o Unix tivesse várias raízes na estrutura do sistema de arquivos, isso seria feito da seguinte maneira: não no MS-DOS e no Windows com nomes de unidades de uma letra. Em outras palavras, vamos comparar apenas o esquema Unix com um bom design multi-raiz.

Então, por que o Unix não tem uma implementação sã de múltiplas raízes, em favor da implementação sã de uma raiz? Provavelmente é apenas por simplicidade. Os pontos de montagem fornecem toda a funcionalidade de poder acessar volumes por nomes. Não há necessidade de estender o espaço para nome com uma sintaxe de prefixo adicional.

Matematicamente falando, qualquer gráfico de árvore separado ("floresta") pode ser associado adicionando um nó raiz e transformando as partes separadas em filhos.

Além disso, é mais flexível que os volumes não precisem estar no nível raiz. Como não há sintaxe especial que denota volume (é apenas um componente do caminho), os pontos de montagem podem estar em qualquer lugar. Se você levar em três discos antigos para sua máquina, você pode tê-los como /old-disk/one, /old-disk/two, etc. Você pode organizar discos como quiser, a maneira como você organiza os arquivos e diretórios.

Podem ser gravados aplicativos que dependem de caminhos, e a validade dos caminhos pode ser mantida quando os dispositivos de armazenamento são reconfigurados. Por exemplo, os aplicativos podem usar caminhos conhecidos como /var/loge /var/lib. Depende de você estar /var/loge /var/libestar no mesmo volume de disco ou em volumes separados. Você pode migrar um sistema para uma nova topologia de armazenamento, preservando os caminhos.

Os pontos de montagem são uma boa ideia, e é por isso que o Windows os possui desde o Windows 2000.

Os pontos de montagem de volume são robustos contra as alterações do sistema que ocorrem quando os dispositivos são adicionados ou removidos de um computador. Microsoft Technet

* Nix e Windows montam suas unidades. No Windows, eles são montados automaticamente em pontos de montagem que, por padrão, estão em ordem alfabética crescente. Esses padrões são:

• A:e B:=> disquetes
• C: => primeira partição do primeiro disco rígido
• D: => próxima partição ou próximo disco rígido ou unidade de CD / DVD, se nenhuma outra partição estiver presente.

Cada um desses pontos de montagem é um diretório.

No * nix, os pontos de montagem são decididos pelo usuário. Por exemplo, eu tenho uma partição montada como /e outra como /home. Portanto, /homeé uma unidade separada, seria o equivalente a dizer E:no Windows.

Nos dois casos, Windows e * nix, os pontos de montagem são diretórios separados. A única diferença é que, no * nix, esses diretórios separados são subdiretórios de /, C:enquanto no Windows, todos os pontos de montagem são montados diretamente sob o /, My Computerdigamos.

Do ponto de vista do usuário, a principal vantagem é que as montagens são completamente transparentes. Não preciso saber que o diretório /homeestá realmente em uma partição separada. Eu posso apenas usá-lo como um diretório normal. Em vez disso, no DOS, eu teria que chamá-lo explicitamente pelo nome do ponto de montagem, digamosE:\home

As unidades externas são montadas da mesma maneira nos dois sistemas. Diga D:para Windows e /mnt/cdromLinux. Cada um deles é um diretório, eu realmente não vejo a diferença. Quando você coloca um CD-ROM em sua unidade no Windows, o disco é montado D:exatamente como no Linux.

Concordo com as respostas acima, especialmente a resposta de Doug O'Neal, mas acho que todas elas perdem um pouco, assim como os pontos de montagem explícitos do dispositivo, como o MS-DOS "C:" ou "A:".

Rob Pike escreveu The Hideous Name sobre sintaxe de nomes, mas Russ Cox resumiu :

Os espaços para nome ... são mais poderosos quando novas semânticas podem ser adicionadas sem adicionar nova sintaxe.

Um único espaço de nome onde os dispositivos podem ser montados arbitrariamente permite operações realmente flexíveis. Uso regularmente /mnt/sdb1e /mnt/cdromcoloco temporariamente um disco ou CD atualmente não utilizado no sistema geral de arquivos. Não é incomum ter diretórios pessoais em um servidor NFS; portanto, independentemente da máquina em que você efetua login, você obtém o mesmo em $HOMEtodos os lugares.

Tudo se resume a isso: ter uma sintaxe especial para coisas especiais impõe limites definidos ao que você pode fazer. Se você pode montar apenas um disco ou CD ou DVD não utilizado, ou um sistema de arquivos de rede / "compartilhar" em "E:" ou "W:" ou qualquer outra coisa, você tem muito menos flexibilidade.

Isso é bobo. O Windows também possui um único ponto de hierarquia. Mas é oculto e não é padrão. Como a maioria das coisas, janelas.

Nesse caso, é o conceito "Meu computador". Isso é equivalente à raiz (/) no Unix. Lembre-se de que raiz é um conceito que existe no kernel. voce gosta ou nao. Assim como o Windows trata o "Meu Computador". é claro, você pode montar uma partição no root no unix, e é isso que a maioria das pessoas faz. E muitas coisas procurarão um caminho específico para as coisas (por exemplo, / etc /), mas você não está limitado por ela. Por todos os meios, monte suas unidades em / C: /. você não está proibido de fazer isso no unix.

C: \ não é uma raiz no Windows, é o ponto de montagem de uma partição. Que DEVE estar no nível superior "Meu Computador". Enquanto no unix, você pode montar uma partição sob qualquer outra árvore. Portanto, no linux, você pode ter o C: montado /enquanto você tem o D: montado /mnt/d/... ou até mesmo montado, /mas isso é complicado e depende de como os dois sistemas de arquivos se comportam ao montar no topo de um caminho já montado.

Assim, você pode obter exatamente o mesmo que o Windows, forçando-se a seguir as mesmas limitações que o Windows impõe aleatoriamente.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Então você teria que passar nas opções de montagem nas opções de inicialização. já que você não terá um / etc / ..., mas também simulará as limitações que o Windows impõe, como é o que faz.

O motivo do Windows ter letras de unidade provavelmente remonta mais ao Microsoft e DOS. A atribuição de letras a unidades removíveis era comum nos sistemas IBM; portanto, a Microsoft pode estar apenas seguindo as instruções da IBM, copiando o CP / M. E, inicialmente, o DOS não tinha diretórios de qualquer maneira.

Quando o MS-DOS era executado em computadores com um ou dois discos removíveis e sem mídia fixa, você realmente não precisava de um sistema de arquivos com diretórios. Com um, ou talvez dois discos de 180 kilobytes, você nunca teve arquivos suficientes para ter muitos problemas para organizá-los.

https://en.wikipedia.org/wiki/Drive_letter_assignment

Na verdade, o Linux é baseado no Unix (ou é o Unix, veja a discussão ) e o Unix vem do ambiente de mainframe, onde o uso de vários dispositivos era bastante óbvio. A montagem de dispositivos em uma única árvore de diretórios oferece flexibilidade máxima e não limita o número de dispositivos que o sistema operacional pode acessar.

Por outro lado, as letras DOS para unidades são um bom design para um PC com 1 ou 2 estações de disquete e unidade de disco único. O disquete grande 5,25 'é sempre A :, o pequeno 3,5' é sempre B: e a unidade de disco é sempre C :. Você sempre sabe se copiar um arquivo no disquete ou em algum lugar do disco. Você não precisa de flexibilidade se não puder conectar fisicamente mais de 2 unidades de disquete e 2 (ou 4) discos rígidos.

O design do DOS era mais amigável ao usuário final, enquanto o design do Unix era amigável ao administrador. Agora as letras das unidades são um fardo para o Windows, os usuários confiam mais em abrir automaticamente a janela do explorer com o conteúdo removível da unidade do que conhecer sua letra ... O Ubuntu faz o mesmo, na verdade.

Isso não é verdade, na verdade. O Windows usa outro esquema de caminhos (bem, não é o mesmo)

"Letras de unidade" são apenas algo para lembrar facilmente caminhos, discos e partições.

Os caminhos do ARC definem o caminho de um arquivo no Windows (mas são visíveis ao usuário apenas na inicialização):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

No Windows NT, não há relação entre discos, partições e letras de unidade: você pode "colocar" um volume inteiro em uma pasta (por exemplo: c: \ myseconddisk pode ser um disco físico inteiro!)

Duas coisas que eu gostaria de destacar -

1. Os discos rígidos no linux são de certa forma atribuídos a letras / nomes, como / dev / sdb1. Mas eles podem ser montados em qualquer lugar a partir da estrutura única / raiz
2. A razão mais comum pela qual as pessoas (inclusive eu no passado) tinham unidades separadas no Windows era ter um lugar para guardar documentos, músicas, programas etc., de modo que, quando o Windows inevitavelmente precisasse ser reinstalado ou substituído, fosse uma atualização ou vírus ou falha no sistema de arquivos, ainda havia acesso a esses arquivos. Eu não tenho esse problema no linux - o sistema de arquivos é muito mais confiável, o sistema operacional não quebra, a menos que por alguma ação direta ou erro da minha parte (ooh! Um repositório de ponta, vamos tentar isso!), E atualizações são muito mais simples. E, no caso raro, tive que reinstalar, já que todo o software estava disponível através de repositórios ou ppas que eu adicionei (e eu poderia copiar facilmente meu diretório pessoal com um disco ativo),

Se você olhar para trás no histórico, também poderá ver que o Unix foi iniciado no momento de 8 sistemas de fita de faixa para áudio e 9 sistemas de dados IBM de faixa (8 faixas / 8 bits para dados, um por paridade). Tecnicamente muito parecido.

Naquele momento, as informações sobre a localização dos arquivos eram armazenadas em partes das informações na fita e definidas para frente e para trás quando você lê dados da fita (como um arquivo, com posição inicial e assinatura final); também explica por que você não tinha apenas um FAT no início da unidade - tinha vários para acelerar a pesquisa. E se você tiver várias unidades, elas serão vinculadas dentro de / dev e pelo endereço do arquivo que você moveu entre os dispositivos.

Acredito que você possa ter a ideia de que ele começou simplesmente mais cedo e que a decisão por trás da área MS Dos (CP / M) e posterior do Windows NT está simplesmente relacionada às letras de unidade de mainframe da VM em vez de um único ponto de entrada, porque na época parecia mais moderno, a quantidade de dados de hoje não existia e eles não pensavam que você acabaria por não ter letras de unidade suficientes ou que isso seria muito confuso.

Atribuição de 9 faixas e letra de unidade