UNIX vs sistema de arquivos do Windows; Por que o UNIX atribui um espaço finito para cada diretório?

Question

Tudo,

Estou finalmente me adaptando às complexidades do NIX, mas uma coisa que ainda estou tentando descobrir é por que o UNIX atribui espaço em disco rígido a cada diretório em seu sistema de arquivos.

Eu descobri isso ao tentar criar um novo diretório na raiz onde eu poderia colocar ISO's para executar máquinas virtuais

/ isos /

Como mostrado abaixo usando o comando df; alguns diretórios têm mais espaço que outros

por exemplo. root tem apenas 700mb atribuído a ele enquanto / export / home tem 65gb

    /dev/fd            (fd                ):       0 blocks        0 files
/tmp               (swap              ): 7724392 blocks   576352 files
/var/run           (swap              ): 7724392 blocks   576352 files
/export/home       (/dev/dsk/c0d0s7   ):138187048 blocks  8350700 files
/mnt       

Nas janelas, não acredito nisso; cada diretório ocupa o espaço necessário nesse momento.

Qual é a vantagem do UNIX gerenciar o espaço desta forma, parece um pouco inflexível na minha opinião ou talvez eu esteja apenas acostumado com o Windows.

    

Answer 1

DF não mostra pastas.
Ele mostra as partições e como elas são "montadas" (vinculadas) dentro do sistema de arquivos geral.

A primeira coluna é o lugar no sistema de arquivos onde a partição é anexada.
2 dá uma referência à própria partição.
E as outras colunas mostram informações adicionais como tamanho usado / livre.

Você está confundindo o tamanho fixo de um sistema de arquivos e a partição subjacente com a noção de uma pasta dentro desse sistema de arquivos.

Para turvar ainda mais as águas: Algumas dessas partições são virtuais e existem apenas na memória (/ proc, às vezes / tmp) e, portanto, não se relacionam com nenhuma partição física no disco.

    

Answer 2

Eu acredito que você esteja enganado sobre o significado desses sistemas de arquivos. Na minha máquina do Kubuntu, df produz a seguinte saída (a propósito, a opção -h imprime tamanhos em human unidades, em vez de blocos):

  $ df -h
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/sda1        28G  6,9G   20G  27% /
  none            4,0K     0  4,0K   0% /sys/fs/cgroup
  udev            2,9G  4,0K  2,9G   1% /dev
  tmpfs           585M  1,4M  584M   1% /run
  none            5,0M     0  5,0M   0% /run/lock
  none            2,9G  820K  2,9G   1% /run/shm
  none            100M   20K  100M   1% /run/user
  /dev/sda6       202G   96G   97G  50% /home

Sua confusão nasce do fato de que o que você chama de finite space directories não são sistemas de arquivos reais em um disco, mas são Virtual Sistemas de arquivos , i.e. partes da hierarquia de sistemas de arquivos comuns , que são hospedados diretamente dentro do computador RAM. Os sistemas de arquivos RAM são hospedados diretamente na memória principal do PC para permitir acesso mais rápido a eles, de modo que você encontrará entre eles /tmp e /proc . Eles têm um tamanho definido porque a RAM é limitada em sua capacidade e porque nem todo espaço de RAM pode ser alocado para esses sistemas de arquivos. O uso de discos RAM não está limitado ao sistema operacional, mas está aberto também a um usuário (competente): você pode aprender como gerar um desses sistemas de arquivos em nesta página da Web acessível . Também deve ficar claro que, sob a infeliz hipótese de que o espaço alocado na RAM se tornaria insuficiente, o sistema expandiria o sistema de arquivos virtual na área de swap.

    

Answer 3

Na verdade, é mais parecido com o modo como o Windows ( CP / M , ao contrário) é inflexível.

No DOS e Windows (incluindo a linha do Windows NT que gerou, por exemplo, Windows NT 3.x, Windows 2000, Windows XP e Windows 8), até bem recentemente havia um mapeamento um-para-um entre partições de disco e arquivo sistemas. (Isso foi alterado pela introdução de pontos de montagem de volume no Windows 2000, embora esse ainda seja um recurso raramente usado, talvez fora da área especializada. situações.)

Sistemas semelhantes ao Unix fazem uma distinção clara entre o dispositivo de armazenamento que contém um sistema de arquivos, o sistema de arquivos em si e o ponto de montagem no qual o sistema de arquivos está acessível. Isso faz parte do design subjacente e cada peça desempenha um papel importante.

No Windows, normalmente o sistema de arquivos em uma partição é acessado por meio da letra de unidade da partição (por exemplo, C: ou E: ). Em * nix, um sistema de arquivos é normalmente acessado por meio de um caminho de diretório (por exemplo, /export/home possivelmente relativo ao diretório atual).

O último é mais flexível porque, em um caminho, não há hipóteses codificadas sobre o armazenamento subjacente. Falta de espaço em uma partição? Basta mover um sistema de arquivos grande que existe atualmente nessa partição para outro, atualizar a tabela de montagem (no Linux / etc / fstab, pode ser diferente em outros * nixes) para apontar o diretório relevante para um novo dispositivo físico e chamá-lo de dia. Ou divida um sistema de arquivos em dois movendo um diretório grande para um sistema de arquivos em um novo dispositivo de armazenamento e, novamente, atualize a tabela de montagem. Alternando para uma arquitetura de armazenamento baseada em SAN em vez de armazenamento por host? Mesma coisa. No que diz respeito aos usuários, isso pode ser feito sem a aparente interrupção de qualquer outra coisa além do curto período de tempo durante o qual a movimentação real dos dados ocorre. Especialmente antes dos pontos de montagem de volume, o mesmo não poderia ser feito facilmente em um ambiente centrado na Microsoft.

Quando você cria um diretório /isos , está criando um diretório dentro do sistema de arquivos raiz, e o armazenamento do que entra nesse diretório deve ser suportado pelo sistema de arquivos raiz. Se você perceber posteriormente que esse armazenamento é inadequado, poderá executar etapas para atenuar ou corrigir essa situação sem precisar mover arquivos de maneira lógica, criando um sistema de arquivos separado e montando-o no /isos e movendo os arquivos para o diretório raiz desse sistema de arquivos, tornando-os visíveis sob /isos quando esse sistema de arquivos é montado lá.

Tenha em mente que o Unix foi projetado como um sistema multiusuário, enquanto o Windows (e muitas das opções de design subjacentes do Windows) rastreiam sua linhagem de volta para sistemas essencialmente individuais. Embora esse tipo de flexibilidade provavelmente não seja necessário em um sistema de usuário único, isso ajuda bastante em uma configuração de vários usuários. (Não é necessário que o administrador fixe um aviso na entrada da sala do terminal dizendo "ok, todo mundo, o que estava anteriormente em D :, exceto D: \ STUFF, agora está em Q :, exceto pelo que estava em D: \ JOGOS que estão agora sob R: \ WASTE e D: \ MATH agora estão em E: \ ALGEBRA, oh, e espero não ter esquecido nada "; apenas embaralhe os arquivos, mas mantenha os diretórios lógicos iguais.)