Sistema de Arquivos Sistema de arquivos otimizado

Transcrição

1 CAPA Sistema de Arquivos Sistema de arquivos otimizado A escolha de um sistema de arquivos depende das necessidades de cada um. Conheça as diferenças entre os sistemas de arquivos Linux mais populares e faça uma escolha consciente. por Ben Martin A possibilidade de escolha é uma coisa boa, e o moderno kernel do Linux certamente oferece uma ampla seleção de sistemas de arquivos para seus preciosos dados. Neste artigo, examinaremos algumas questões das estruturas dos sistemas de arquivos mais populares, e mostraremos como cada um deles lida com esses pontos de estrutura. Essa perspectiva de um projetista oferecerá alguma compreensão sobre qual sistema funcionará melhor em seu ambiente. Problemas, problemas... Os sistemas de arquivos são enganadoramente simples à primeira vista o que queremos é inserir dados em locais do disco e recuperá-los mais tarde, correto? Por essa definição, tudo que queremos que o sistema de arquivos faça é localizar os metadados dos nomes de um arquivo e um diretório e os relacionamentos entre um e outro (subdiretórios dentro de diretórios), e possivelmente, armazenar bytes contínuos de cada arquivo como seu conteúdo. Ou talvez, o sistema de arquivos possa somente armazenar os metadados em uma tabela, listar o nome dos arquivos, seu tamanho, data de modificação, e assim por diante, além da localização do conteúdo em bytes desses arquivos. Até aqui, o sistema de arquivos ainda parece moderadamente simples. Haverá alguns bloqueios primitivos na tabela de metadados para garantir sua consistência, mesmo com muitos processos fazendo isso ao mesmo tempo, mas a necessidade de alguma forma de bloqueio não irá atrapalhar o espetáculo. Além disso, seria bom que houvesse um tipo de índice na tabela de metadados para que um diretório possa ser lido rapidamente. Mas, espere um pouco... Se o computador for desligado, é bom que o sistema de arquivos se mantenha útil e contenha todos os dados na hora que a máquina for ligada de novo. E tudo estará bem se no momento que o PC foi desligado, o usuário estava escrevendo dados no disco. Talvez não seja possível recuperar tudo que estava sendo escrito na hora do desligamento, mas todo o resto tem que estar em perfeita ordem. Além disso, ninguém quer ficar esperando que uma operação de checagem fsck do sistema de arquivos leve horas e horas para completar uma varredura em um novíssimo disco de 2TB. Logicamente, alguns segundos já são suficientes para que o pobre sistema de arquivos perceba que já estava a meio caminho de completar 50 coisas quando o computador desligou, e que deve voltar ao estado normal. Agora, as coisas já estão ficando um pouco mais complexas. Se o sistema de arquivos tentar atualizar os metadados no mesmo lugar no disco, como ele poderá determinar se um bloco na tabela de metadados é válido ou se estava incompleto quando a máquina desligou? E o índice na tabela de metadados? É possível que metade desse índice tenha sido escrito no disco e a outra metade ainda estava na RAM esperando ser escrita no disco quando o computador foi desligado. Esses metadados não podem ser perdidos de maneira alguma, não importa 40

2 Sistema de arquivos CAPA como. O índice também precisa ser válido; caso contrário, o sistema de arquivos não poderá contar com ele, como se ele nunca houvesse existido. Mas, mesmo que o sistema de arquivos possa detectá-lo, ele não foi finalizado corretamente; retomar o índice pode levar muito tempo, e isso começa a se parecer com o cenário do fsck que precisaria ser evitado. Então, o sistema de arquivos poderia manter um registro das mudanças ocorridas com os metadados e, em um certo momento de conferência, ele montaria uma nova tabela de metadados e um índice com as atualizações, e mudaria a velha estrutura de dados para uma nova. O sistema sempre terá pelo menos um índice e uma tabela de metadados válidos no disco desse modo, e se a máquina desligar, ele poderá usar a versão atual e o registro para ir para o estado mais próximo possível àquele de quando o computador falhou. Esse plano pode funcionar, porém, montar o índice toda vez que for preciso sincronizar as mudanças do sistema de arquivos com o disco será um processo bem lento. Além da consistência dos dados, espera-se também que o sistema de arquivos seja rápido. Na hora de descompactar um arquivo de 50MB ou executar uma compilação distribuída, quanto mais rápido tudo acontecer melhor. Felizmente, não é necessário tentar implementar seu próprio sistema de arquivos rápido e seguro; vários sistemas de arquivos no kernel do Linux já cuidam desses problemas de várias maneiras. Armazenamento de metadados Até agora, percebemos que é uma boa ideia armazenar os metadados de arquivos e diretórios em algum tipo de tabela abstrata e possuir um índice nessa tabela para encontrarmos entradas rapidamente. Ao considerarmos como um diretório pode ser tratado, o índice torna-se uma parte vital para o bom funcionamento de um sistema de arquivos. Normalmente, cada arquivo recebe um número único chamado de inode. Um diretório provavelmente listará os inodes de todos os arquivos nele contidos. Portanto para saber qual o proprietário, qual o grupo e quais as permissões dos arquivos em um diretório, o sistema de arquivos examinará a tabela de metadados usando os números dos inodes. Esses exames dos metadados do arquivo com a utilização do número do inode é uma operação bem frequente, desde conferir as permissões dos arquivos até a execução de um simples comando ls -l em um diretório. Se o projeto do sistema de arquivos limita o número de inodes disponível e aloca uma tabela contígua para todos os inodes no momento de criação do sistema de arquivos, o número do inode pode ser diretamente usado para encontrar a entrada na tabela de metadados. A desvantagem desse esquema é que a tabela tem que ser contígua e pré-alocada, caso contrário, usar uma árvore binária (b-tree) para armazenar a tabela de metadados e o índice torna-se uma solução atraente. Uma árvore binária pode ser útil para implementar um índice que permita o exame dos metadados de um arquivo pelo inode. Para quem não sabe, a árvore binária é um método de indexação que permite examinar uma chave ou uma gama de chaves rapidamente. A estrutura de dados da árvore binária vem desde os anos 70, e funciona bem nos discos porque é possível procurar uma chave sem a necessidade de várias buscas no disco, e, conforme dados vão sendo acrescentados à árvore binária, ela se mantém equilibrada. Uma árvore binária é uma estrutura de dados paginados, o que quer dizer que várias chaves de exame estão agrupadas em uma única página no disco (normalmente 4KB), e uma chave em uma página faz referência a outra página. Então, se os números de uma página e as chaves possuem, cada um, 8 bytes, a página de 4KB da raiz da árvore pode se referir a 256 outras páginas, e cada uma dessas a outras 256 páginas. Como podemos perceber, não são necessárias muitas páginas para conter milhões de chaves. Essa progressão em cada página da árvore significa que é possível achar uma única chave em uma árvore binária de milhões de chaves olhando apenas três páginas. Cada página exigirá que a cabeça do disco faça uma busca, operação esta extremamente lenta; minimizar o número de páginas que precisam ser acessadas é a ideia central aqui. Claro que a regra de buscas infinitas está mudando, agora que discos em estado sólido chegam ao mercado, mas o custo de armazenamento por gigabyte ainda é o fator que provavelmente será mantido por alguns anos. As páginas de níveis mais baixos na árvore binária armazenam os dados de uma chave, que podem ser o ponteiro para alguma outra estrutura de dados ou para os dados propriamente ditos, se estes forem pequenos. Para um sistema de arquivos, os dados são a data de modificação, o proprietário, as permissões etc., coisas pequenas que podem ser armazenadas diretamente na árvore binária. O sistema de arquivos XFS aloca e armazena inodes em grupos de 64; o inode da árvore binária referencia um desses grupos de inodes. As árvores binárias também são ordenadas, o que pode ser explorado pelo sistema de arquivos para oferecer um bom desempenho. Por exemplo, quando 50 arquivos são criados em um diretório, se o sistema de arquivos utiliza números de inodes sequenciais para esses arquivos, eles serão armazenados na árvore binária juntos, e uma busca por esses 50 arquivos Linux Magazine #68 Julho de

3 CAPA Sistema de arquivos usaria a mesma página. Porque os números estão reunidos, as páginas necessárias que levam para a base da árvore também estarão assim, e será possível encontrar todos os 50 arquivos com apenas três ou quatro buscas no disco. Apesar de toda essa indexação ser maravilhosa, o problema do que acontece com a árvore binária quando a força é interrompida ainda existe. Lembre-se que a ideia é evitar remontar o índice da árvore binária, e é preciso saber que isso é válido sempre. Journal e COW Duas grandes estratégias existem para manter a consistência dos metadados do sistema de arquivos: usar um journal (registro) para manter uma lista de alterações e o uso da árvore binária COW (Copy On Write). Quando o journal é usado, é preciso periodicamente fazer mudanças na estrutura de dados primária e graválas no próprio journal. Um processo de checagem similar é usado no esquema da árvore binária COW (também conhecida como B COW), onde há a migração para um outro nó da raiz. A abordagem de journaling para manter os metadados é adotada pelo XFS, ext3 e ext4 (figuras 1 e 2). As árvores binárias COW são usadas pelo Btrfs (figura 3). A série ext de sistema de arquivos utiliza uma tabela de inodes pré-alocada. O XFS usa uma árvore binária de inodes e o Btrfs usa inodes da árvore binária COW. Árvores binárias COW Normalmente, quando uma árvore binária é atualizada, a página contendo a chave é lida na RAM, atualizada lá e depois enviada de volta para o disco. Se a adição de uma chave aumenta muito uma página de modo que ela não caiba mais no lugar para onde vai, ela é dividida em duas páginas e uma outra chave é adicionada. Em uma árvore binária COW, a inclusão de uma chave mantém a velha árvore intacta e gera uma cópia da página a ser atualizada. Para ligar essa página à árvore, uma cópia de todas as páginas pais também é feita. Lembre-se que só pode haver entre três e cinco páginas pais para cada página da árvore binária, pois a estrutura de dados se ramifica rapidamente, portanto, copiar todos os pais não é Figura 1 Os sistemas de arquivos extented (ext) passaram por várias gerações de desenvolvimento. uma operação tão cara. Nesse ponto, haverá uma árvore binária usando quatro ou cinco novas páginas e compartilhando todas as outras com a árvore binária original. A inclusão copia todas as páginas pais, por isso, toda vez haverá um novo nó de raiz na árvore, o que gera uma imagem eficiente do sistema de arquivos na hora de cada modificação. Por motivos de desempenho, um sistema de arquivos que utiliza árvores B COW tentará realizar muitas operações na árvore binária na RAM, e apenas periodicamente sincronizar as páginas copiadas, criando assim, um novo nó de raiz persistente na árvore. Se as mudanças forem interrompidas, muitas ainda podem ser feitas nos nós copiados na RAM sem a necessidade de copiá-los de novo, reduzindo os acessos ao disco. Essas imagens permitem montar o sistema de arquivos somente para leitura como ele estava em um determinado ponto no tempo (para ver seu diretório home de um mês atrás). Uma imagem com permissão de escrita é chamada de clone e permite fazer coisas como experimentar diferentes mudanças no sistema antes de decidir qual dos clones será mantido. Apesar de parecer que todas essas cópias ocupam espaço em disco, estamos falando aqui em duplicar páginas de apenas 4KB, então mesmo que milhões delas sejam duplicadas, ainda estamos falando de um pequeno espaço em disco. Quando as páginas antigas não são mais necessárias, elas podem ser reutilizadas para que a árvore não continue crescendo e acabe ocupando todo o disco. O Btrfs usa árvores COW para tudo. Portanto, é possível conseguir uma imagem de todo o sistema de arquivos de qualquer ponto no tempo. Exclusão (Flushing) Em algum momento, o sistema de arquivos vai querer saber se um dado específico está salvo no disco por 42

4 Sistema de arquivos CAPA exemplo, se o journal das páginas em uma árvore binária COW está todo no disco ou se parte dele está no cache na pequena memória de cache de 16MB do disco. Um comando SATA pode ser usado para conferir a localização dos dados. Infelizmente, esse comando SATA é um flush tudo-ou-nada. Não é possível certificar-se que os dados do comando SATA 12, 45 e 99 estão no disco. Pelo menos, não é possível dizer isso com confiança em nenhum hardware. Normalmente, temos que dizer: exclua tudo o que há. Dado que o cache do disco possui apenas 16MB ou 32MB, contendo não somente dados que precisam ser escritos, e que é possível escrever no disco a 100MB/s, esse pode não parecer um problema muito grande. Mas, quando consideramos que esse cache pode não ser o único contendo dados a serem escritos por exemplo, controladores de disco podem ter um cache também e que os dados no cache podem ter que ir para locais aleatórios no próprio disco, há a possibilidade de uma demora quando o comando de exclusão SATA for dado. Diz-se que esse flushing do SATA usa barreiras do disco [1]. Os sistemas de arquivo ext4, Btrfs e XFS usam barreiras por padrão. Operações com muitos metadados, tais como criar ou excluir muitos arquivos, serão mais lentas com as barreiras, porém, o sistema de arquivos será bem mais resistente a problemas causados por falha de energia. É possível desligar as barreiras nesses sistemas de arquivos se necessário, mas saiba que as barreiras podem não funcionar no conjunto mapeador do dispositivo com versões do kernel anteriores à , dependendo dos patches que vêm com sua distribuição Linux. Provavelmente, você pode estar pensando que, caso sua máquina esteja trabalhando sem um backup de bateria e você preza muito seus dados, então as barreiras são necessárias. Percebemos que habilitar as barreiras pode diminuir as operações com metadados e fsync em 10 vezes. Essa é uma opção entre velocidade e resistência à falta de energia. Armazenamento do conteúdo Há muitas maneiras de se armazenar os bytes de um arquivo no disco, e, quando o sistema de arquivos armazena esses bytes, ele obviamente precisa saber onde eles estão para poder recuperá-los mais tarde. Com o mapeamento de blocos, o disco é dividido em blocos de tamanhos fixos e cada arquivo contém uma lista de números de blocos, para que seja possível encontrar todos os pedaços desse arquivo de novo. Em arquivos pequenos, a lista de blocos pode ser armazenada com as informações do inode. Conforme ele for aumentando, a lista dos números de blocos necessários para recuperar todos os bytes do arquivo também aumenta, então, os inodes armazenam o número do bloco, que é um bloco que contém apenas o número que localiza o conteúdo do arquivo. Se o arquivo é muito grande, o bloco intermediário contendo a lista de blocos do conteúdo do arquivo ficará lotado, gerando blocos com referências a outros blocos com referências aos dados, e assim por diante. Além de armazenar a lista de blocos, outra desvantagem da alocação de blocos é que os arquivos grandes terão muitos blocos e estes podem não estar muito próximos fisicamente no disco. Logicamente, o sistema de arquivos pode tentar usar blocos próximos uns dos outros na hora de escrever um arquivo. Por outro lado, uma solução baseada em extensão utiliza uma série contígua de bytes [2]. No mundo ideal, um filme caseiro de 10GB seria armazenado em uma série de bytes contíguos no disco (uma única extensão), e isso exigiria apenas uma pequena quantidade de metadados para saber a localização do conteúdo; esses dados também poderiam ser lidos do começo ao fim sem a necessidade de buscas extras no disco. Como dá para imaginar, se as extensões estão sendo usadas e possuem uma fragmentação mínima, seria possível excluir um arquivo grande mais rapidamente do que com o uso de alocação de blocos. Figura 2 Originalmente desenvolvido pela Silicon Graphics, o sistema de arquivos de journaling XFS é mantido agora como um projeto independente. Linux Magazine #68 Julho de

5 CAPA Sistema de arquivos Um trabalho do Projeto de Código Aberto SGI de Christoph Hellwig [3] revela que o tempo necessário para excluir um arquivo de 60GB é 50 segundos no ext3, cerca de dois segundos no ext4 e 0,04 segundos no XFS. Esses dois últimos sistemas de arquivos usam extensões, por isso há uma vantagem considerável em sistemas de arquivos baseados em extensões no caso de trabalho com grandes arquivos (produção e edição de vídeos, por exemplo). O calcanhar de aquiles na alocação baseada em extensão aparece com a fragmentação de arquivos. Um caso típico disso é quando baixamos uma distribuição Linux de uma rede peer-to-peer. Conforme o arquivo vai sendo baixado, ele chega em partes que vão sendo entregues ao sistema de arquivos. Portanto, é possível ter centenas de pequenas extensões contendo essas partes. Para evitar a fragmentação de arquivos, o sistema de arquivos pode evitar a escrita imediata de dados no disco; essa estratégia é chamada atraso de alocação (allocation delay). Por exemplo, um programa pode escrever um arquivo ao abri-lo, depois fazer um looping e escrever 64KB de dados várias vezes antes de finalmente fechá-lo. Se o sistema de arquivos mantém os dados escritos na memória até que o programa feche o arquivo, ele saberá exatamente o tamanho do arquivo antes de escrever qualquer coisa no disco. Em um sistema de arquivos baseado em extensão, haverá uma busca por uma única extensão que comporte o tamanho desejado e nela escreve os dados de uma só vez. Não só a fragmentação é evitada, mas também uma única busca no disco é feita para que os dados sejam escritos. Um esquema de alocação de bloco tentaria encontrar um grupo de blocos na mesma área no disco e escrever os dados nesses blocos de modo a reduzir a carga de busca em uma nova leitura sequencial dos dados. Funções como fallocate (função que permite verificar qual tamanho ocupado no disco pelo arquivo) permitem que o programa informe com antecedência ao sistema de arquivos o tamanho exato que o arquivo terá, mas nem todos os programas aproveitam essas funções para auxiliar o sistema de arquivos. Mesmo com a ajuda do atraso de alocação e do fallocate, ainda haverá fragmentação do conteúdo do arquivo. Por exemplo, se o sistema de arquivos estiver quase que 100 por cento preenchido e mais de uma extensão é necessária para comportar um arquivo grande, a fragmentação terá que ocorrer. Esse é um dos motivos pelos quais os sistemas de arquivos possuem ferramentas online de desfragmentação. No XFS, é possível usar a ferramenta de organização xfs_fsr para otimizar a alocação de extensão dos arquivos. Uma das boas coisas do xfs_fsr é que é possível informar seu tempo de funcionamento, e ele irá se lembrar do ponto em que foi interrompido na próxima execução. Dessa maneira, ele pode ser executado durante algumas horas no meio da noite, todos os dias e sempre começará do ponto em que parou. O ext4 está providenciando a desfragmentação online das extensões. O utilitário e4defrag permite a desfragmentação de um arquivo específico, mas até agora, esse programa não faz parte do Fedora 11, 12 ou Rawhide. Figura 3 O sistema de arquivos árvore binária (Btrfs - pronuncia-se Butter FS ) agitou o mundo do código aberto com recursos avançados de imagens simples e multi-dispositivos de extensão. Como afirma a wiki, o Btrfs é relativamente novo e ainda está sendo pesadamente desenvolvido. A escolha do sistema de arquivos Com todos esses COWs, journals e árvores, ainda é possível perguntar qual sistema de arquivo é o melhor para ser adotado. A resposta simples é: depende. E, talvez, a melhor solução seja usar mais de um em seu sistema, tirando vantagem dos pontos fortes de cada um de acordo com a carga de trabalho. A família ext armazena inodes em uma tabela, o XFS usa árvores B e o Btrfs usa árvores B COW para tudo. O ext3, ext4 e o XFS usam o journal para manter a integridade no caso de falta de energia. Os sistemas ext preferem executar uma curta ope- 44

6 Sistema de arquivos CAPA ração fsck de tempos em tempos durante a inicialização. O ext4, o XFS e o Btrfs permitem barreiras de disco por padrão, o que faz do ext3 a ovelha negra nessa lista. Uma orientação comum para um bom desempenho é que é preciso também tentar não ocupar todo o disco. Quando um sistema de arquivos está entre 90 e 95 por cento lotado, ele precisará começar a fazer escolhas que espalharão arquivos e até metadados por todo o disco. Do mesmo jeito, para criar menos contenção de locking, muitos sistemas de arquivos tem um esquema de várias subpartes. Por exemplo, o XFS é dividido em muitos grupos de alocação que, de várias maneiras, operam como pequenos sistemas de arquivos autônomos. Isso permite que o sistema de arquivos atualize muitas estruturas de dados em paralelo, porque, a grosso modo, um grupo de alocação não afeta os outros. Devemos estar cientes aqui, de que a extensão de um arquivo pode ter que ser dividida e armazenada em muitos grupos de alocação. De certo modo, evitar pouco espaço em disco é ligeiramente amplificado pelo uso dessas muitas pequenas partes. Muitos sistemas de arquivos permitem que se decida o tamanho do inode na hora em que está sendo montado. Caso planeje usar atributos de extensão com um bom desempenho às custas de um pequeno espaço em disco, é possível fazer os inodes ligeiramente maiores que o normal. O tamanho fixo de um inode pode ser dividido entre armazenamento da lista de extensão no inode além de usar atributos de extensão. Ironicamente, ao usar extensivamente os atributos de extensão, dobrar o tamanho do inode pode fazer o sistema de arquivos usar menos espaço para seus metadados e melhorar o desempenho ao mesmo tempo. Esse paradoxo ocorre devido ao fato de que a lista de extensão e os atributos de extensão podem caber no inode, evitando assim, a necessidade de fazer o sistema de arquivos mover os atributos de extensão para outro bloco de 4KB quando nem tudo couber no inode. Como exemplo concreto, no XFS uma lista de extensão de 19 entradas pode caber em um inode de tamanho padrão. Quando se começa a usar um ou mais atributos de extensão, eles compartilham o mesmo espaço que essas 19 entradas usariam, e quando ambos não couberem, os atributos de extensão são movidos para uma árvore binária em uma página própria. Dado o modo em que o Btrfs usa as árvores B COW, fica fácil compreender seu sucesso: um sistema de arquivos que utiliza alocação de extensão e permite imagens e clones do sistema de arquivo [4]. A principal desvantagem do Btrfs é sua relativa juventude. Do mesmo modo, a grande vantagem da família ext é que ela já está em uso há muito tempo. Quando se fala em diretório home, é preciso valorizar o fato de que muitos vêm usando o ext3 por muito tempo com certo grau de certeza de que os dados estarão sempre disponíveis. Mais informações Por outro lado, o XFS está presente no kernel do Linux desde a versão 2.4, e, com sua alocação baseada em extensão e desfragmentação online, ele consegue lidar com arquivos grandes muito bem. Uma desvantagem do XFS bem conhecida é que ele é lento para lidar com muitas operações de criação e exclusão de arquivos. Por isso, se for preciso expandir tarballs de arquivos relativamente pequenos como os de código fonte, o XFS pode não ser a melhor escolha. Em resumo, se houver grandes arquivos que possam ser desfragmentados, o XFS é uma grande escolha. Se a alocação dinâmica de inodes e extensões não é tão importante, então o ext3 é uma boa solução. O ext4 traz alocação de extensão ao ext3 e logo terá desfragmentação online de extensões (e4defrag). Se quiser imagens rápidas e clones de pontos de tempo específicos, fique então com o Btrfs. Para desfragmentar as extensões Btrfs, use btrffsctl -d. Se quiser velocidade e confiança, considere o armazenamento de seu journal em um SLC SSD de boa qualidade, ou invista em um backup de bateria e desligue as barreiras do sistema de arquivo. n [1] Barreiras de disco: filesystems-data-preservation-fsync-and-benchmarks-t-3 [2] ext2: [3] XFS: The Big Storage File System for Linux, por Christoph Hellwig, login:, October 2009: projects/xfs/papers/hellwig.pdf [4] Btrfs: Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: Linux Magazine #68 Julho de