Esquemas de particionamento e sistemas de arquivos

Este artigo traz uma abordagem teórica sobre esquemas de particionamento de disco e sistemas de arquivos no GNU/Linux. Ele trás a história e a teoria destes dois temas, mostrando, principalmente, vantagens e desvantagens de se usar várias partições para a instalação do GNU/Linux e benchmarks dos sistemas de arquivos mais utilizados neste sistema operacional.

[ Hits: 133.774 ]

Por: José Lopes em 21/07/2006 | Blog: https://lopes.id


Sistemas de arquivos



3.1. Definição


Conforme [Bauer & Bowden 2006], a maneira mais simples de se armazenar dados em um disco, consiste em, simplesmente, gravá-los na mídia. Entretanto, isto torna o acesso a estes dados muito inconveniente, pois não há informações sobre o tipo dos dados gravados, seu tamanho ou sua identificação no disco. Além disso, o fato de gravar um novo conjunto de dados na mesma mídia, torna-se complicado, pois deve-se saber em qual parte do disco os últimos dados foram gravados, para que não haja risco de perda acidental de informações.

Através desta breve análise, fica evidente que é necessária a existência de uma estrutura para armazenagem dos dados e informações referentes a eles. É neste contexto que surgem os sistemas de arquivos. Neste ponto deve-se deixar claro o sentido que deve ser dado à expressão "sistema de arquivos". De acordo com [Bauer & Bowden 2006], muitas pessoas utilizam a expressão sistema de arquivos para relacionar duas coisas distintas. A primeira delas diz respeito à estrutura hierárquica dos diretórios do sistema e a segunda diz respeito ao formato de baixo nível usado para armazenar dados. Este segundo entendimento é justamente o tópico que esta seção enfoca e o primeiro é referenciado, neste artigo, como "hierarquia de diretórios".

Segundo [LSAG 2006], sistemas de arquivos são os métodos e estruturas de dados que um sistema operacional utiliza para manter o acompanhamento de arquivos em um disco ou partição, isto é, a maneira com que os arquivos são armazenados em disco. Pode-se dizer que os sistemas de arquivos criam uma camada entre os programas e a mídia que eles gerenciam, de forma com que eles controlem as operações de Entrada e Saída (E/S, em português ou I/O, em inglês - Input/Output) de dados na mídia, com o intuito de manter a integridade e a segurança dos dados lá armazenados, além de buscar trazer uma boa performance às operações de acesso ao disco.

3.2. História dos sistemas de arquivos no GNU/Linux


A história da evolução dos sistemas de arquivos para o GNU/Linux é bem interessante e ajuda a compreender alguns conceitos interessantes dos sistemas de arquivos deste sistema operacional.

Conforme [DISEFS 2006], o GNU/Linux, no seu início, era desenvolvido sob o sistema operacional Minix, um sistema operacional para fins acadêmicos, desenvolvido pelo Dr. Andrew S. Tanenbaum, para uso em disciplinas que ensinam a implementação de sistemas operacionais. Era mais fácil compartilhar discos entre os dois sistemas, do que escrever um novo sistema de arquivos, então Linus Torvalds, o criador do GNU/Linux, decidiu implementar suporte para o sistema de arquivos do Minix, no GNU/Linux. Apesar de eficiente e, relativamente, livre de erros, o MinixFS (Minix Filesystem) era muito limitado e, com a disseminação do GNU/Linux, seus usuários começaram a pensar e trabalhar em um novo sistema de arquivos para ele [DISEFS 2006].

Neste ponto, foi criado o Virtual Filesystem (VFS), que é uma camada entre o sistema de arquivos e o kernel (núcleo do sistema operacional - o Linux, de fato), com o objetivo de facilitar a integração e o uso de vários tipos de sistemas de arquivos [DISEFS 2006]. Segundo [Bauer & Bowden 2006], a camada VFS é que permite aos usuários do GNU/Linux montar diferentes tipos de sistemas de arquivos ao mesmo tempo.

Em abril de 1992, após a integração do VFS ao Linux, um novo sistema de arquivos, chamado Extended Filesystem (Ext), foi implementado e integrado ao Linux, versão 0.96c. Este novo sistema de arquivos, que era um melhoramento do MinixFS, removeu muitas limitações do MinixFS, mas ainda possuía muitos problemas [DISEFS 2006].

Como resposta a estes problemas, dois novos sistemas de arquivos foram criados em janeiro de 1993: o Xia Filesystem e o Second Extended Filesystem (Ext2). O primeiro era altamente baseado no código do kernel para o MinixFS, adicionando poucas melhorias. Já o segundo era baseado no código do Ext, com muitas reorganizações e melhorias. O Ext2 foi desenvolvido com sua evolução em mente, pois continha espaço para futuras melhorias [DISEFS 2006].

No início, o XiaFS era mais estável que o Ext2, mas com o tempo, erros foram corrigidos no Ext2 e muitas melhorias foram feitas nele, até que ele se tornou muito estável e passou a ser padrão de fato para o GNU/Linux [DISEFS 2006].

A partir de então, novos conceitos surgiram, dentre eles o Journal. O sistema de journaling de dados divide a fase de escrita dos dados em duas partes: agendamento e escrita. Caso ocorra uma interrupção inesperada do sistema, como uma queda de luz, durante a fase de agendamento, o arquivo não é atualizado, continuando intacto. Caso esse problema ocorra durante a fase de escrita, o sistema possui a agenda (journal), onde estão os dados necessários para fazer as alterações no arquivo. O fato do sistema escrever várias vezes a mesma alteração em arquivos, não torna a operação lenta, pois ele também otimiza o movimento das cabeças de leitura do disco rígido [Conectiva 2006].

A utilização desta estrutura permite que, em caso de desligamento acidental do sistema, não seja necessário executar o programa fsck no disco (o que pode levar muito tempo, dependendo do tamanho do sistema de arquivos) [Conectiva 2006].

Com a criação do sistema de journaling de dados, o Ext2 recebeu suporte para esta nova tecnologia e foi relançado como Third Extended Filesystem (Ext3) [FSHowTo 2006].

Atualmente, os sistemas de arquivos mais usados e mais famosos do GNU/Linux, junto com o Ext3, são o Reiser Filesystem, criado por Hans Reiser; o Journaled Filesystem (JFS), criado pela IBM para o AIX, a versão do Unix da mesma empresa e o Extended Filesystem (XFS), criado pela Silicon Graphics Incorporated (SGI) para o Irix, sua variação do Unix.

3.3. Blocos


A menor unidade de armazenamento de um disco rígido é o setor. Cada setor possui 512 bytes e pode armazenar dados de apenas um arquivo. Pelo fato deste valor ser muito pequeno para a maioria dos arquivos, o sistema de arquivos agrupa vários setores, de forma com que este agrupamento seja a menor unidade de armazenamento de dados. Para este agrupamento de setores é dado o nome de cluster ou bloco [GdH 2006].

Durante o processo de formatação do disco, é criada toda a estrutura necessária ao funcionamento do sistema de arquivos e todo o disco é dividido em blocos de mesma capacidade de armazenamento. Cada um destes blocos poderá armazenar dados de um e somente um arquivo. Assim, caso um arquivo de 12 KB precise ser armazenado numa partição com blocos de tamanho igual a 8 KB, serão alocados dois blocos para a armazenagem deste arquivo, implicando numa perda de 4 KB na partição (por isso é comum haver dois tamanhos para um arquivo: tamanho real e tamanho em disco) e esta perda de espaço recebe o nome de fragmentação interna.

Fica claro que, quanto maior o tamanho dos blocos, maior será a fragmentação interna, sendo assim, poder-se-ia sugerir a divisão do disco em blocos de tamanho mínimo (512 bytes), o que diminuiria ao máximo este problema. Entretanto, o tamanho dos blocos determina a quantidade de dados que pode ser lida ou escrita pelo sistema operacional de cada vez. Então, tem-se que quanto menor o tamanho dos blocos, mais acessos precisarão ser feitos ao disco, o que diminui o desempenho do sistema.

A solução encontrada para estes problemas, é definir os blocos em tamanhos onde eles não sejam grandes demais, para diminuir a fragmentação interna e nem pequenos demais, para não prejudicar o desempenho do sistema. Dessa forma, ao se definir o tamanho dos blocos, o administrador deve ter total consciência do uso que será dado ao sistema, para definir um tamanho adequado para eles. Para usuários comuns, que não têm muita preocupação com relação a isto, sugere-se que deixe o programa formatador escolher o tamanho dos blocos (caso este programa permita que se altere o tamanho dos blocos).

3.4. Armazenamento dos dados em disco


Os sistemas de arquivos onde o GNU/Linux pode ser instalado, seguem um padrão de funcionamento para manter a compatibilidade entre si e o sistema, apesar de poderem variar um pouco [LSAG 2006]. Basicamente, o que ocorre é que os dados a serem gravados são associados a um elemento do sistema de arquivos, chamado inode.

Um inode armazena, exclusivamente, informações sobre um arquivo, como permissões, dono, datas e tamanho (por isso, para cada arquivo, há um inode correspondente). Apenas o nome do arquivo não é armazenado no inode, pois este é especificado no diretório, junto com o número de identificação do inode referente a ele e para esta ligação dá-se o nome de hardlink (um hardlink nada mais é do que a associação de um nome a um número identificador de inode - assim um inode pode ser referenciado por vários nomes).

Os dados referentes ao arquivo, representado pelo inode, são gravados em blocos no disco, de forma separada do inode, sendo que o inode implementa as referências para estes blocos [LSAG 2006]. Na estrutura do inode, além das informações sobre o arquivo, como tamanho, localização física, dono e grupo do dono, permissões de acesso, datas e contador de referências (hardlinks) [TLIP 2006], há dois tipos de estruturas usadas para referenciar blocos de dados do arquivo: direct blocks e indirect blocks [LSAG 2006].

Os direct blocks (blocos diretos) são blocos reservados especialmente para a utilização daquele inode (são blocos estáticos e somente o inode que os referencia pode trabalhar com eles) e por isso são poucos. Os indirect blocks (blocos indiretos) são blocos alocados dinamicamente, no caso do arquivo ser grande demais e precisar de mais blocos para ser armazenado em disco. Neste caso, após os direct blocks se esgotarem, ponteiros são usados para referenciar mais blocos em disco [LSAG 2006].

Para armazenar as características de um sistema de arquivos, como o seu tamanho, o tamanho dos blocos, os contadores dos blocos vazios e cheios e o tamanho e a localização da tabela de inodes, percebeu-se que era necessária a criação de um novo elemento do sistema de arquivos e para este elemento, que armazenaria estas informações tão relevantes do sistema de arquivos, deu-se o nome de superblock (super bloco).

A importância do superblock dentro do sistema de arquivos é tão grande, que qualquer dano causado nele, pode causar na perda de dados armazenados no sistema de arquivos. Por isso, copias do superblock são armazenadas automaticamente em intervalos do sistema de arquivos (como no início de cada grupo de blocos). Além disso, para cada sistema de arquivos montado, o GNU/Linux mantém uma cópia do seu superblock na memória [TLIP 2006].

3.5. Fragmentação


Ao se gravar um arquivo em disco, o ideal é que seus dados sejam alocados em blocos consecutivos, para melhorar a performance de recuperação do arquivo posteriormente. Contudo, nem sempre é possível que um arquivo tenha seus dados alocados desta forma no disco e para esta situação, dá-se o nome de fragmentação [LSAG 2006]. É comum também chamar este tipo de fragmentação de fragmentação externa.

Os sistemas de arquivos mais modernos do GNU/Linux utilizam técnicas especiais para a alocação de blocos, por isso não é necessária muita preocupação com este problema neste sistema operacional. Já para os sistemas de arquivos mais antigos, a fragmentação era uma realidade. Com o objetivo de desfragmentar o disco, o utilitário Defrag foi criado, mas hoje em dia é altamente recomendável que ele NÃO seja usado, pois ele foi criado para ser utilizado em versões antigas do Ext2 e não é atualizado desde o ano de 1998 [LSAG 2006].

[LSAG 2006] sugere que, caso se deseje desfragmentar uma partição, que se faça o backup dos dados lá armazenados, formate a partição e se retorne com os dados. Segundo a fonte, esta é uma medida segura e ainda reforça a idéia do backup antes de se realizar uma desfragmentação, para evitar o risco de perda de dados.

3.6. Principais tipos de sistemas de arquivos do GNU/Linux


3.6.1. MinixFS (Minix Filesystem)

Desenvolvido para o sistema Minix, este foi o primeiro sistema de arquivos do GNU/Linux. É um sistema de arquivos bastante simples e por isso contém algumas limitações sérias, como o tamanho máximo de sua partição sendo de 64 MB e o tamanho máximo de um nome de arquivo sendo de 14 caracteres [DISEFS 2006].

3.6.2. Ext (Extended Filesystem)

Criado em abril de 1992 e fortemente baseado no MinixFS, o Ext (Extended Filesystem) foi o primeiro sistema de arquivos a ser criado exclusivamente para o GNU/Linux. Suas principais vantagens com relação ao MinixFS foram o aumento do tamanho máximo de sua partição para 2 GB e o tamanho máximo dos nomes de arquivos para 255 caracteres [DISEFS 2006].

3.6.3. Ext2 (Second Extended Filesystem)

O Ext2 (Second Extended Filesystem) foi criado para solucionar alguns problemas presentes no Ext. Entre estes problemas destacam-se a falta de suporte para acesso separado, modificação de datas dos inodes, modificação das datas dos arquivos e fragmentação. Com o aumento dos usuários adeptos ao Ext2, erros foram corrigidos e muitas melhorias foram feitas neste sistema de arquivos, que se tornou padrão de facto para o GNU/Linux [DISEFS 2006].

3.6.4. Ext3 (Third Extended Filesystem)

De acordo com [FSHowTo 2006], o Ext3 (Third Extended Filesystem) nada mais é que o Ext2 com suporte a journaling.

3.6.5. ReiserFS (Reiser Filesystem)

Este sistema de arquivos, criado por Hans Reiser, utiliza em sua codificação uma variação dos algoritmos clássicos de árvores balanceadas, o que melhoraria sua performance frente à alocação convencional de blocos do Ext2 [FSHowTo 2006].

3.6.6. JFS (Journaled Filesystem)

O JFS (Journaled Filesystem) é um sistema de arquivos desenvolvido pela IBM. Inicialmente ele era desenvolvido para o sistema operacional AIX (uma variação do Unix, desenvolvido pela IBM). Com a evolução deste sistema de arquivos, a IBM passou a utilizá-lo no OS/2 (um outro sistema operacional desenvolvido pela empresa), além de utilizá-lo ainda no próprio AIX. Não demorou muito e a IBM começou a adaptar o JFS para uso no GNU/Linux e com isso foi liberando o seu código-fonte aos poucos. Assim, este sistema de arquivos foi incorporado de vez a muitas distribuições GNU/Linux [Gordon & Haddad 2006].

3.6.7. XFS (Extended Filesystem)

O XFS (Extended Filesystem - não confundir com Ext) foi criado pela empresa SGI, para ser utilizado no Irix (uma versão do Unix, desenvolvido pela própria SGI).

Desde sua concepção, o XFS era voltado para uso, desde estações de trabalho (desktops), até supercomputadores. O interessante deste sistema de arquivos é que ele tenta posicionar os inodes próximos aos arquivos que eles referenciam, além de armazenar pequenos arquivos, links simbólicos e alguns diretórios como parte dos inodes, a fim de melhorar sua performance e economizar espaço em disco [FSHowTo 2006].

3.6.8. NFS (Network Filesystem)

O NFS (Network Filesystem) não é um sistema de arquivos como os demais. Segundo [WikiNFS 2006], este é um modelo de sistema de arquivos que tem como função centralizar arquivos em um computador servidor, formando um diretório virtual. A utilização do NFS faz sentido apenas em um ambiente do tipo cliente-servidor, onde se deseje centralizar dados no servidor, fazendo com que os clientes acessem os dados lá presentes, em vez de colocá-los em cada computador cliente.

3.6.9. ISO9660

De acordo com [WikiISO 2006], o ISO9660 é o padrão internacional de armazenamento de dados, que faz a descrição da estrutura de arquivos de um CD-Rom. Este sistema de arquivos parte do princípio de que o sistema a ser montado não está no dispositivo de armazenamento do seu ponto de montagem (como os próprios CD-Roms).

3.6.10. VFAT (Volume File Alocation Table)

O VFAT (Volume File Alocation Table), é a versão para o GNU/Linux do sistema de arquivos FAT32 (File Alocation Table 32 bits) da Microsoft. Segundo [Conectiva 2006], é o sistema de arquivos dos sistemas operacionais Windows 9X e Windows NT. Na prática, este é o sistema de arquivos usado para montar partições formatadas com os sistema de arquivos FAT32. Para informações sobre outras versões do FAT (FAT12, FAT16 e etc.), veja os sistemas de arquivos msdos e umsdos (manual do programa mount).

3.6.11. NTFS (New Technology Filesystem)

O NTFS (New Technology Filesystem) é a versão para o GNU/Linux do sistema de arquivos de mesmo nome, da Microsoft. Vale lembrar que, apesar desse sistema de arquivos ser conhecido dentro do GNU/Linux como NTFS, o nome da sua implementação para este sistema operacional é Linux-NTFS. De acordo com [Conectiva 2006], este é o sistema de arquivos dos sistemas operacionais Windows 2000, XP e NT. Assim como o sistema de arquivos VFAT, na prática, este sistema de arquivos é usado para montar partições formatadas sob o sistema de arquivos NTFS.

3.7. Benchmarks de sistemas de arquivos


3.7.1. Introdução

Benchmark é um programa de testes, utilizado para avaliar o desempenho de algum dispositivo [Wenzel 2006]. Na prática, dentro da computação, quando se comparam tecnologias (hardware ou software), diz-se que foi feito um benchmark.

Muitas pessoas não acreditam em benchmarks e assim não dão crédito aos resultados que eles descrevem. Na verdade, alguns benchmarks são realmente suspeitos, como, por exemplo, uma empresa desenvolvedora de uma placa de vídeo, que faz um benchmark de sua placa junto com uma concorrente, sem especificar com detalhes os testes feitos e os resultados obtidos com cada um deles. Entretanto há muitos benchmarks confiáveis, que podem ser levados em consideração na hora de se comparar duas ou mais tecnologias.

Cabe esclarecer que os resultados obtidos em um benchmark, por mais confiável que este seja, não devem ser tomados como verdades absolutas, devendo ser considerados dentro de um determinado contexto. Por exemplo, caso seja feito um benchmark de monitores e se chegue à conclusão de que o monitor M1 suporta resoluções maiores, gasta mais energia e é mais caro que o monitor M2, não significa que o segundo monitor deve ser descartado em uma compra, pois ele seria a opção ideal para uso onde não é necessária a utilização de resoluções muito altas e onde a economia de energia tem um peso considerável na escolha, como em estabelecimentos comerciais, computadores antigos e etc.

Benchmarks de sistemas de arquivos, normalmente, colocam à prova a velocidade com que os sistemas testados executam operações de I/O, o quanto consomem de CPU, quais recursos de configuração possuem e como reagem em caso de falhas (como desligamento acidental do sistema).

Muitos benchmarks de sistemas de arquivos do GNU/Linux já foram feitos e a maioria deles estão acessíveis via internet. Três deles chamam muito a atenção, por características interessantes e eles serão discutidos nesta seção.

3.7.2. Um benckmark técnico

[Dölle & Reitter 2006] testaram o Ext2, Ext3, ReiserFS, JFS e o XFS. O que chama a atenção neste benchmark, é que os testes foram feitos através do uso de programas específicos para benchmarks: FSBench (http://fsbench.netnation.com/), que é um script escrito em linguagem Python, que chama os outros dois programas, passando-lhes os parâmetros adequados; Bonnie++ (http://www.coker.com.au/bonie++/) e IOZone (http://www.iozone.org/).

Os testes feitos neste benchmark varias entre realizar buscas aleatórias, criar, aleatoriamente, arquivos e escrever num arquivo existente, sendo que o tamanho destes arquivos variam de um a quatro GB.

A conclusão deste benchmark foi que o JFS foi o vencedor, por ter se saído bem em todos os testes. Em segundo lugar ficou o XFS, com resultados inferiores, mas com um baixo consumo de CPU. Em terceiro ficou o ReiserFS, trabalhando muito bem com arquivos pequenos, mas consumindo muita CPU. Surpreendentemente, o Ext2 ficou em quarto lugar,com uma performance ligeiramente pior que a dos três primeiros. O Ext3 ficou em último lugar, tendo se mostrado muito lento ao trabalhar no seu modo "journal", que é o seu modo de operação mais seguro.

3.7.3. Um benchmark para usuários comuns

Com o intuito de realizar um benchmark mais próximo à realidade de usuários comuns do GNU/Linux, Justin Piszcz realizou um testes nos sistemas de arquivos Ext2, Ext3, ReiserFS, JFS e XFS [Piszcz 2006].

Foram feitos 21 testes, que incluíam criar 10000 arquivos com o comando touch em um diretório, criar 10000 diretórios com o comando mkdir, partir um arquivo de 10 MB em partes de tamanhos variados, entre outros testes.

A conclusão encontrada por Piszcz foi que os melhores sistemas de arquivos a serem utilizados, baseado no tempo total dos testes, são o JFS, o ReiserFS ou o XFS, dependendo da necessidade e dos tipos de arquivos que serão mais utilizados na aplicação. Já o Ext3 apresentou resultados muito lentos nos testes, enquanto o Ext2 apresentou resultados satisfatórios, talvez por não possuir o recurso de journaling.

3.7.4. Confirmação de Piszcz

Hans Ivers realizou um benchmark que, segundo [Ivers 2006], complementaria aquele feito por Piszcz, pois este não teria feito testes tão próximos do ambiente real de um usuário comum do GNU/Linux.

Os testes feitos por Ivers vão, desde a realização de operações com um arquivo de imagem ISO de 700 MB, até operações com uma árvore de diretórios com 7500 arquivos, 900 diretórios e 1.9 GB de tamanho. Ao todo, foram realizadas 11 tarefas, nos sistemas de arquivos Ext3, ReiserFS, JFS e XFS.

A conclusão de Ivers, foi que os resultados obtidos por Piszcz foram confirmados. Conforme [Ivers 2006], o Ext3 consome mais espaço em disco após a formatação que os outros e leva mais tempo para ser criado.

O ReiserFS leva mais tempo para ser montado, além de não trabalhar tão bem com arquivos pequenos, como sugerem os outros benchmarks citados, além de consumir muita CPU.

O JFS é o sistema de arquivos que consome menos CPU e conseguiu ótimos resultados nos testes feitos.

Já o XFS foi o melhor sistema de arquivos testado e Ivers o recomenda para qualquer perfil de aplicação, desde um computador para uso doméstico, até para um servidor de arquivos.

3.7.5. Conclusão dos testes

Através da análise dos três benchmarks apresentados, pode-se concluir que o XFS é o sistema de arquivos que vem obtendo melhores resultados, por isso é indicado para a maioria das aplicações.

Tal qual o XFS, o JFS também apresenta ótimos resultados, chegando, às vezes, a superar o XFS. Contudo, de acordo com a revista Linux Magazine, numa entrevista com Theodore T'so (nome bastante conhecido da comunidade GNU/Linux e funcionário da IBM), a IBM, principal mantenedora do JFS, vem trabalhando bastante na melhoria do Ext3, por isso pode ser que a IBM deixe o JFS de lado e passe a investir exclusivamente no Ext3 [LinMag 2006]. Assim, é bom utilizar o JFS com cautela, pois ele pode ser esquecido num futuro próximo.

O ReiserFS consome muita CPU, mas [Dölle & Reitter 2006] e [Piszcz 2006] o consideram mais eficiente no trato de arquivos pequenos. Desta forma, é aconselhável que seja utilizado apenas em aplicações onde o tamanho dos arquivos seja reduzido e haja bastante tempo ocioso de CPU, como um servidor de arquivos que armazenará documentos texto, planilhas, notas fiscais e etc. Mas mesmo assim deve ser utilizado com cuidado, verificando se ele não pode ser substituído pelo XFS.

O Ext3 é o sistema de arquivos a ser usado por usuários que não querem muita dor de cabeça ao ter que selecionar um sistema de arquivos, visto que possui suporte para todas, ou quase todas, as distribuições GNU/Linux e é totalmente compatível com o Ext2.

3.8. Conclusão - Sistemas de arquivos


Nesta seção foram vistos os principais conceitos de sistemas de arquivos, a evolução dos sistemas de arquivos no GNU/Linux, os principais sistemas de arquivos utilizados neste sistema operacional e suas particularidades e benchmarks realizados com eles.

Toda esta explanação acerca dos sistemas de arquivos, objetiva mostrar ao leitor a grande variedade de sistemas de arquivos disponíveis para utilização no GNU/Linux e que cada um tem características próprias. Por isso, a escolha e instalação de um sistema de arquivos, deve ser feita com bastante cuidado, para se obter um melhor desempenho e segurança do sistema.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Particionamento
   3. Sistemas de arquivos
   4. Conclusão final
   5. Referências
Outros artigos deste autor

Instalação e configuração do MySQL 4.0.26, Apache 2.0.54, PHP 5.0.4 e PHP-Nuke 7.8 no Slackware 10.1

Configurando o Fortune

Configuração manual dos ponteiros do mouse

Usando temas aleatórios no GDM

Compilação comentada do kernel

Leitura recomendada

GIT: Controle de versões distribuído para projetos de software

Entendendo e configurando o LVM manualmente

Cotas de Disco

Formatando Disquetes

Clonando HDs via rede com G4U (Ghost for UNIX)

  
Comentários
[1] Comentário enviado por angeloshimabuko em 21/07/2006 - 18:10h

Muito bom o seu artigo, e bem estruturado. Peço apenas a sua compreensão para algumas observações que vou fazer.

2.1: num disco ATA (IDE) podem existir até 59 (e não 60) unidades (partições) lógicas. Assim, o número máximo de sistemas de arquivos instalado será de 62 (e não 63): 3 em partições primárias e 59 em unidades lógicas. O número não é da arquitetura (seja do padrão ATA ou da x86), mas uma limitação imposta pelo Linux. Sem entrar em muitos detalhes, depende da estrutura de números maiores e menores, cujo registro é mantido por Torben Mathiasen e cuja versão mais atual encontra-se em
<http://www.lanana.org/docs/device-list/index.html>. Do registro verifica-se também que o número de unidades lógicas num disco SCSI é de 11 (e não 12), possibilitando a instalação de 14 sistemas de arquivo (3 em partições primárias e 11 em unidades lógicas).

2.4: a definição de memória virtual não está correta. O espaço de troca no disco rígido é apenas um componente da memória virtual, e nem mesmo é necessário. O Linux (e os principais sistemas operacionais: Windows, FreeBSD, Solaris) usa (e depende de) a memória virtual, que tem 3 funções principais: (i) permitir a cada processo um endereçamento próprio (na arquitetura x86, endereços na faixa de zero a 4 GiB), origem do nome memória virtual; (ii) proteção (na arquitetura x86, num sistem híbrido de segmentação e paginação); (iii) possibilitar a utilização de mais memória do que a existente fisicamente (aqui entra o espaço de troca).

Em 2.4.2, o tamanho do espaço de troca está correto (2 GiB) para a arquitetura x86 (são 128 GiB para alpha e 3 TiB para Sparc64, p.ex.), mas a quantidade de espaços, atualmente, é de 32 (v. "man mkswap"). O valor de 8 é anterior ao kernel 2.4.10.

O esquema de particionamento (2.5) faz uma recomendação inadequada: usar um espaço de troca no final do disco rígido é muito ruim para o desempenho. Como exemplo, o meu disco principal (um ST380817AS, da Seagate), segundo o hdparm, pode ler 56 MiB/s (em média) em sda2 (nos primeiros 600 MiB) e apenas atinge 34 MiB/s em sda14 (últimos 7 GiB). Num hd (ATA ou SCSI), os setores são numerados de fora para dentro. Assim, obviamente, o desempenho será melhor nos setores iniciais.

3.5. Deve haver, sim, uma preocupação com fragmentação. Use a ferramenta filefrag para verificar. Principalmente nos sistemas Ext2-3 e Reiserfs (que usam alocação por blocos), o índice de fragmentação, principalmente de arquivos grandes (maiores que 100 KiB) pode ser muito alto (já monitorei um sistema de correio mal configurado, usando Reiserfs 3, onde alguns arquivos de caixa postal, com tamanhos de 2 MiB a 14 MiB tinham entre 100 e 500 fragmentos, com desempenho de disco muito ruim). O JFS e XFS usam alocação por extensões (extents) ordenadas em árvore, e fragmentam menos. Além disso, o XFS possui uma ferramenta para desfragmentar (xfs_fsr).

O SAG, de Wirzenius e outros, da sua referência, já foi muito bom, mas além de alguns equívocos de conceito (como o de memória virtual), está muito desatualizado e muitas partes (como a que informa sobre partições). As melhores fontes de informação ainda são: os fontes do kernel, as páginas manuais, livros mais específicos.

Referências:

[1] Carrier, Brian. File system forensic analysis. 2005. Addison Wesley Professional.

[2] Bovet, Danilo P., Cesati, Marco. Undestanding the Linux kernel.3.ed. 2006. O'Reilly.

[3] Gorman, Mel. Understanding the Linux virtual memory manager. 2004. Prentice Hall.

[2] Comentário enviado por Dotti em 21/07/2006 - 22:09h

Ótimo artigo, e excelente comentário.
Sempre quis ver informações sobre sistemas de arquivos e não tinha tido oportunidade ainda, obrigado.

[3] Comentário enviado por forkd em 24/07/2006 - 00:17h

Fala Angelo!

Bom, com relação às observações feitas, tudo o que foi exposto no artigo foi exposto por alguma das referências. Neste caso, o interessante é verificar qual referência trouxe a informação e tentar entrar em contato com o(s) autor(es), para um esclarecimento ou uma correção da parte deles. No mais, agradeço pelo comentário extremamente construtivo!

Abração!

[4] Comentário enviado por rasxr3 em 25/07/2006 - 20:00h

Caro amigo, obrigado pela solidariedade de nos trazer infromações tão valiosas quanto raras. Este foi, sem sombra de dúvidas o melhor artigo que já li no VOL. Porém, existe um ponto incorreto no artigo além daqueles já apontados pelo amigo angeloshimabuko na seguinte parte do texto.

"2.1. Definição e primitivas
(...)
Para solucionar este problema, as partições estendidas foram concebidas. Este tipo de partição funciona quase como uma partição primária. A primeira grande diferença entre elas, segundo [Piropo 2006], é o fato de que partições estendidas não podem ser utilizadas para se inicializar o computador, portanto não podem conter os arquivos de inicialização de um sistema operacional.
(...)"

Na realidade, o problema é que o artigo citado data de agosto de 2005 (mais precisamente do dia 28). De lá pra cá alguns conceitos mudaram. Lembrando que o escritor em questão tem conhecimento de causa principalmente em Windows e OS2. O erro em questão é que existe sim a possibilidade de se iniciar um sistema GNU/Linux a partir de uma partição extendida. O mesmo não pode ser dito do Windows que precisa de uma partição primária para a instalação do ssitema. No aritgo citado ainda existem algumas informações desatualizadas como o fato de o ssitema operacional não conseguir utilizar as outras partições primárias, somente a utilizada no boot, o que é uma inverdade até para o próprio Windows.

Como disse, o erro parte da fonte e não do autor, e a esse cabe novamente elogiar pelo belo trabalho e pelas valiosas informações.

[5] Comentário enviado por forkd em 22/08/2006 - 01:41h

Poxa galera, fico muito feliz com o nível dos comentários. Isso é muito bom, não só pra mim, como pra todos aqueles que venham a ler o artigo! Seria legal se todas as discussões do VOL tivessem este nível!

Valew galera!

[6] Comentário enviado por elton.linux em 17/07/2007 - 15:46h

Realmente,

muito bom o nível de todo o tópico e comentários.

A única coisa desagradável foi esse assunto ter lembrado aulas de sistemas operacionais, cuja matéria quase peguei dependência semestre passado.


Estou instalando meu debian lenny com jfs.


Valeu
Abraço


[7] Comentário enviado por lucianomarques1 em 24/07/2007 - 16:42h

Gostei muito do seu artigo, gostaria de uma ajuda sua se fosse possível.

Reinstalei o Ubuntu 7.04 no meu micro no Domingo, criei a partiçãi hda1 (ext3), hda2 (reiserfs esta apenas para armazenar minhas músicas e outros) e hda3 (swap). Achei muito estranho o fato do Ubuntu não estar montando automáticamente minha partição hda2. Então postei uma pergunta mas não recebi uma resposta muito clara à respeito, segue abaixo o link da pergunta:

http://www.vivaolinux.com.br/perguntas/verPergunta.php?codigo=64465

Qualquer coisa, meu e-mail é lucianomarques1@msn.com

[ ]'s e desde já agradeço

Luciano - Barra do Piraí - RJ.

[8] Comentário enviado por forkd em 24/07/2007 - 19:33h

Fala Luciano!
Provavelmente não há a entrada para montagem desta partição no arquivo /etc/fstab. Verifique isto. Caso não tenha, a entrada seria uma linha como:

/dev/hda2 /mnt/musics ext3 defaults 1 2

Note que a segunda coluna (/mnt/musics) deve ser substituída pelo ponto de montagem da partição e a coluna ext3 deve ser substituída pelo seu sistema de aquivos.
Caso haja uma entrada para a partição hda2, envie o seu arquivo /etc/fstab pra mim, para que eu possa analisar melhor. :)

Só um detalhe: aqui não é lugar de postar dúvidas. Quando for assim, publique a sua pergunta e mande um email para alguém com a dúvida e o link da mesma.
Só uma questão de organização... ;)

Abraço!

[9] Comentário enviado por Teixeira em 02/07/2008 - 15:35h

Muito bom o artigo, e bastante abrangente.

As eventuais discrepâncias não são da parte do autor, conforme já comentado, e sim das fontes em decorrência de mudança de conceitos.

( Este artigo passa a fazer parte dos meus Favoritos ).

E por falar em conceitos, aproveito para chamar à atenção o fato de que
as pessoas sempre disseram estar formatando os HDS.

Isso é falso, pois a formatação se dá a nivel de VOLUME, e não a nível de DRIVE.

Dessa forma, o conceito de DRIVE C: somente é verdadeiro quando o HD tem um volume (=partição) único.
Isso é mera coincidência.

O certo seria dizer o VOLUME C: e não o DRIVE C:
O sistema operacional porém sempre tratou do assunto com o nome de VOLUME, mas sempre aceitamos essa história de drive, e esse conceito foi ficando em nossa mente.
Dá para entender, mas é uma falso entendimento.

A estrutura determinada pelo Linux ajuda a compreender melhor:

O drive de HD é representado geralmente por hda;
Cada partição Linux será hda1, hda2, etc.
Isso corresponde no Windows ao C:, D:, etc., sendo que nesse caso o drive de CD será a última letra disponível.

No Linux o drive de CD tem outra denominação (geralmente hdc) que não faz parte daquela mesma sequência.


[10] Comentário enviado por marcoaw em 10/02/2012 - 10:52h

Muito bom este artigo !!!

Parabéns tambem aos comentários acima !!!

Uma aula de Sistemas de Arquivos !!

Abraços a todos


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts