Quais são os sistemas de arquivos utilizados pelo sistema operacional Linux?

Artigos File Systems: Comparando os sistemas de arquivos do Linux

Por que eu devo ler este artigo:Este artigo tem como objetivo apresentar um comparativo de desempenho entre os principais sistemas de arquivos dispon�veis para a plataforma Linux. � muito importante conhecer as vantagens e desvantagens destas op��es para que seja poss�vel estabelecer par�metros que sirvam como um guia, possibilitando a cria��o de uma rela��o entre a tecnologia a ser adota da (se a op��o ext3, ext4, XFS ou JSF) e o cen�rio em que ela ser� empregada, fundamentando de forma t�cnica e precisa a decis�o tomada.

Nos �ltimos anos foi poss�vel observar um crescimento vertiginoso no desempenho dos processadores com o surgimento das tecnologias multi-core e hyperthreading. Um fen�meno parecido ocorreu com as mem�rias, cuja velocidade de acesso aumentou significativamente.

No entanto, n�o se pode dizer o mesmo para as tecnologias de disco r�gido. Apesar do aumento da capacidade de armazenamento, em termos de desempenho a evolu��o foi bem menor. Para constatar isso, basta observarmos que os discos rotativos mais r�pidos da atualidade, de 15.000 RPM, j� existem h� mais de 10 anos.

As interfaces de conex�o tamb�m evolu�ram, desde o SCSI, at� SAS e FC, mas o meio f�sico continua fundamentalmente o mesmo. Neste cen�rio, a tecnologia SSD (Solid-state Disk) possibilita alt�ssimas velocidades de acesso, mas o seu custo ainda � proibitivo para grande parte das aplica��es, e a sua confiabilidade ainda n�o est� no mesmo n�vel dos discos de tecnologia tradicional.

Ou seja, ainda ser� necess�rio convivermos com os discos rotativos por algum tempo e, portanto � preciso aprender a extrair deles o m�ximo desempenho.

Quando falamos de armazenamento em geral, existem diversos fatores a serem analisados, como velocidade do disco, capacidade, interface de conex�o, n�vel de RAID e, em um n�vel mais alto, o tipo de filesystem adotado.

Neste artigo focaremos nesse �ltimo aspecto. Em particular, analisaremos este conte�do relacionado � plataforma Linux, que oferece diversas op��es nesta �rea; diferentemente de outros sistemas operacionais, como o Windows, que oferece basicamente uma op��o de sistema de arquivos de alta performance, o NTFS.

A seguir s�o apresentados, com brevidade, os diferentes tipos de sistemas de arquivos que ser�o analisados:

� ext3: sigla para �Third Extended Filesystem�. Foi criado por Stephen Tweedie em 1999 e integrado ao kernel em 2001. At� hoje � o filesystem mais comum em distribui��es Linux. O grande diferencial do ext3 para o seu antecessor, o ext2, est� no fato dele incorporar a tecnologia de journaling, que permite ao filesystem ser recuperado rapidamente em caso de falha (ver BOX 1);

� ext4: sigla para �Fourth Extended Filesystem�, � o sucessor do ext3. Criado em 2008, tem como objetivo prover um melhor desempenho que o ext3;

� XFS: o XFS foi criado pela SGI (Silicon Graphics Inc.) em 1994 para a sua distribui��o de Unix, o IRIX. Seu c�digo fonte foi liberado em 2000 e integrado ao kernel do Linux em 2002. O XFS possui caracter�sticas interessantes, como redimensionamento e desfragmenta��o online e capacidade de �congelamento� do I/O para a execu��o de c�pias consistentes;

� JFS: sigla para �Journaling Filesystem�, foi criado pela IBM em 1990 para a sua distribui��o de Unix, o AIX. Posteriormente foi incorporado no OS/2 (sistema operacional para processadores Intel x86, comum nos anos 1990), e em 1999 seu c�digo fonte foi liberado para a comunidade, para que fosse portado para Linux. O filesystem conhecido como JFS no Linux � equivalente ao JFS2 do IBM AIX, e n�o deve ser confundido com o JFS1, tamb�m do AIX, por�m mais antigo.

BOX 1. Journaling

Journaling � uma tecnologia utilizada por filesystems modernos, onde todas as solicita��es de grava��o em disco s�o realizadas primeiro em uma estrutura chamada journal, e s� depois s�o efetivamente gravadas em disco. Isto serve para garantir uma recupera��o r�pida em caso de falhas de disco ou do servidor, como quedas de energia. O journal funciona como um log das transa��es realizadas no filesystem, e os dados permanecem ali somente at� serem persistidos em disco.

Conceitos gerais

Antes de apresentarmos os testes realizados, � importante compreender, ao menos de forma breve, alguns conceitos. Vamos iniciar esse estudo analisando os diferentes tipos de acesso:

� Sequencial: � o acesso realizado em uma ordem pr�-estabelecida. Normalmente utilizado quando se precisa ler ou gravar um conjunto grande de dados, isto �, quando � menos custoso para o disco fazer poucos acessos sequenciais do que milhares de acessos rand�micos. Por exemplo, quando um banco de dados precisa ler uma tabela inteira (�full table scan�), este se utiliza de uma leitura sequencial;

� Rand�mico: � o acesso realizado por meio de um endere�o espec�fico de um dado no disco. Normalmente utilizado para acessos pontuais, em pequenas quantidades. Por exemplo, quando um banco de dados faz uma busca de um registro por �ndice, ocorre uma leitura sequencial no �ndice, e uma vez que o ponteiro para o dado foi encontrado, ocorre uma leitura rand�mica para buscar o registro inteiro.

A seguir explicamos a diferen�a entre I/O s�ncrono e ass�ncrono, que s�o particularmente relevantes para aplica��es que efetuam grande volume de escritas em disco:

� I/O S�ncrono (sync): � aquele em que o kernel s� responde para a aplica��o que o acesso foi conclu�do ap�s este ter sido confirmado no disco. A aplica��o fica bloqueada naquele ponto at� que a confirma��o seja recebida. No caso de escritas, isso ajuda a garantir que o dado de fato est� no disco, ao pre�o de tornar a escrita potencialmente mais lenta;

� I/O Ass�ncrono (libaio): � aquele em que o kernel confirma a conclus�o do acesso assim que este for recebido, sem bloquear a aplica��o. No caso de leituras, existem mecanismos para informar a aplica��o de que o dado est� dispon�vel, como as fun��es select e poll do Linux, e no caso de escritas, o dado � colocado em mem�ria pelo kernel para ser processado posteriormente.

Isso ajuda a tornar as aplica��es mais responsivas, ao pre�o de uma pequena probabilidade de perda de dados em caso de falha de energia.

Por padr�o, todas as solicita��es de leitura e escrita realizadas pelas aplica��es em sistemas Linux passam primeiro pela mem�ria, antes de chegar no disco. Essa �rea de mem�ria � chamada de cache de filesystem, e tem a finalidade principal de tornar mais r�pido o acesso a arquivos muito utilizados.

Os sistemas Linux por padr�o utilizam boa parte da mem�ria livre como cache de filesystem. Quando executamos o comando free para verificar a quantidade de mem�ria livre no servidor, podemos perceber que existe uma coluna de nome cached, que indica a quantidade de mem�ria alocada para o cache de filesystem no momento. Conforme as aplica��es demandam mais mem�ria, o kernel dinamicamente devolve mem�ria do cache para ser utilizada por estas.

Para algumas aplica��es espec�ficas, contudo, pode ser ben�fico pular a etapa de cache. Por exemplo, bancos de dados normalmente possuem uma estrutura pr�pria de cache de dados, que por ter sido constru�da tendo em mente as suas estruturas internas de dados, s�o mais eficientes do que o cache de filesystem, que � gen�rico e idealizado somente para acesso a arquivos. Nesses casos, podemos configurar a aplica��o para realizar o acesso diretamente ao disco (direct I/O), sem passar pelo cache.

� comum em bancos de dados, como o MySQL, Oracle e Sybase, a op��o de utilizar os dispositivos de disco diretamente, em vez de filesystems tradicionais. Nesse caso, o acesso ser� realizado diretamente no disco, sem passar pelo cache do sistema operacional.

Nos nossos testes, utilizamos filesystems tradicionais, e configuramos o acesso com ou sem cache como um par�metro.

Metodologia dos Testes

Para realiza��o dos nossos testes, foram utilizados os seguintes cen�rios:

� Leitura Sequencial;

� Escrita Sequencial;

� Misto de Leitura/Escrita Sequenciais;

� Leitura Rand�mica;

� Escrita Rand�mica;

� Misto de Leitura/Escrita Rand�micas.

Para cada cen�rio de teste, foram inclu�das tr�s vari�veis, com todas as combina��es poss�veis. A seguir podemos verificar as vari�veis:

� I/O s�ncrono ou ass�ncrono;

� I/O com cache ou direto;

� Poucos arquivos grandes x muitos arquivos pequenos.

Tudo isso somado nos d� 48 casos de teste para cada um dos filesystems selecionados. Al�m destes cen�rios, foram criados outros dois, nos quais foi simulada uma carga de quatro processos em paralelo, realizando um misto de leituras e escritas rand�micas, poucos arquivos grandes e I/O direto, s� alternando entre I/O s�ncrono e ass�ncrono.

Para os testes, foi utilizada uma m�quina virtual com CentOS 6.5 de 64 bits, 8GB de RAM, 2 vCPUs e 4 discos virtuais pr�-alocados de 8GB, sendo um para cada filesystem em teste. A m�quina virtual foi criada em ambiente VirtualBox, sobre Windows 7 em um computador com CPU i7-3520, 16GB de RAM e disco SATA de 500GB e 7200 RPM. Al�m disso, os discos foram formatados com o tamanho de bloco default de 4KB e montados com suas op��es padr�o, sem otimiza��es.

Ferramenta de Testes

Para este comparativo, foi utilizada a ferramentafio (Flexible I/O Tester), criada por Jens Axboe, que � um dos mantenedores do kernel do Linux. Esta ferramenta possui dezenas de op��es e permite grande flexibilidade nos testes.

Para instalar o fio � preciso ter os pacotes libaio, gcc e make instalados, pois ele � distribu�do na forma de c�digo fonte. � poss�vel baixar o pacote deste a partir do site do projeto (veja a se��o Links). No nosso teste foi utilizada a vers�o 2.1.5, cujo pacote se chama fio-2.1.5.tar.gz.

Para compilar o pacote, utilize os comandos apresentados na Listagem 1.

Listagem 1. Compilando e instalando o pacote do fio.

$ tar zxvf fio-2.1.5.tar.gz $ cd fio-2.1.5 $ ./configure $ make $ sudo make install

Uma vez que o programa esteja compilado e instalado, podemos come�ar a explorar suas funcionalidades. Tipicamente, criamos um arquivo de configura��o com os par�metros do teste que desejamos executar.

A seguir, apresentamos alguns dos principais par�metros do fio:

� rw: indica o perfil de I/O que ser� realizado no teste. Pode ter os valores read (leitura sequencial), write (escrita sequencial), rw (leitura e escrita sequenciais), randread (leitura rand�mica), randwrite (escrita rand�mica) e randrw (leitura e escrita rand�mica);

� blocksize: indica o tamanho do bloco a ser utilizado nos testes, em bytes;

� ioengine: indica o tipo de I/O a ser realizado. Valores comuns s�o sync (s�ncrono) e libaio (ass�ncrono);

� nrfiles: indica a quantidade de arquivos que ser�o criados no filesystem de teste;

� size: indica o volume total de dados a ser criado no filesystem para os testes;

� directory: indica o caminho do diret�rio onde ser� executado o teste;

� runtime: indica a dura��o do teste em segundos;

� direct: indica se o I/O deve utilizar cache ou n�o (0 ou 1).

Na Listagem 2 podemos ver um exemplo de arquivo de configura��o do fio. Com este arquivo, o teste executar� um job de nome �my_job� que faz somente leituras sequenciais, com blocos de 4 KB, de forma s�ncrona, com 200 arquivos totalizando 256 MB, no diret�rio /mnt/myfs, por 60 segundos.

Listagem 2. Exemplo de arquivo de configura��o do fio.

[my_job] rw=read blocksize=4096 ioengine=sync nrfiles=200 size=256m directory=/mnt/myfs runtime=60

Para submeter dois jobs em paralelo, basta colocar dois blocos de configura��o no mesmo arquivo.

Para executar o teste, grave as configura��es em um arquivo (aqui chamado de my_job.conf) e utilize o comando a seguir:

$ fio my_job.conf

Os resultados da execu��o do fio s�o bastante detalhados, e por isso podem ser dif�ceis de interpretar em um primeiro momento. Na Listagem 3 podemos verificar um exemplo.

Listagem 3. Exemplo de resultado gerado a partir da execu��o do fio.

my_job: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 fio-2.1.5 Starting 1 process my_job: Laying out IO file(s) (2 file(s) / 256MB) Jobs: 1 (f=2): [R] [100.0% done] [29714KB/0KB/0KB /s] [7428/0/0 iops] [eta 00m:00s] my_job: (groupid=0, jobs=1): err= 0: pid=20620: Tue Mar 4 14:00:23 2014 read : io=262144KB, bw=30330KB/s, iops=7582, runt= 8643msec clat (usec): min=0, max=27853, avg=118.78, stdev=1053.20 lat (usec): min=0, max=27857, avg=122.89, stdev=1053.25 clat percentiles (usec): | 1.00th=[ 3], 5.00th=[ 3], 10.00th=[ 3], 20.00th=[ 5], | 30.00th=[ 5], 40.00th=[ 5], 50.00th=[ 5], 60.00th=[ 5], | 70.00th=[ 5], 80.00th=[ 6], 90.00th=[ 6], 95.00th=[ 6], | 99.00th=[ 5728], 99.50th=[ 9664], 99.90th=[13376], 99.95th=[14144], | 99.99th=[18816] bw (KB /s): min=23133, max=34471, per=99.25%, avg=30101.18, stdev=3315.97 lat (usec) : 2=0.01%, 4=13.76%, 10=83.38%, 20=0.59%, 50=0.10% lat (usec) : 100=0.63%, 250=0.10%, 500=0.01%, 750=0.02%, 1000=0.02% lat (msec) : 2=0.05%, 4=0.11%, 10=0.75%, 20=0.44%, 50=0.01% cpu : usr=0.24%, sys=15.46%, ctx=955, majf=0, minf=29 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=65536/w=0/d=0, short=r=0/w=0/d=0 latency : target=0, window=0, percentile=100.00%, depth=1 Run status group 0 (all jobs): READ: io=262144KB, aggrb=30330KB/s, minb=30330KB/s, maxb=30330KB/s, mint=8643msec, maxt=8643msec Disk stats (read/write): sdb: ios=1054/3, merge=1/0, ticks=24369/47, in_queue=24403, util=98.67%

Para os nossos testes, estamos interessados apenas na informa��o de IOPS (I/O por segundo), que indica a capacidade de vaz�o (throughput) de um determinado sistema de arquivos.

Na Listagem 3 podemos ver na linha em negrito o valor �iops=7582�, o que indica que o filesystem foi capaz de entregar 7.582 I/O por segundo durante o teste.

Resultados dos testes

Ap�s a execu��o dos 50 casos de teste para os quatro sistemas de arquivo selecionados, analisaremos a partir de agora, separados pelo perfil de I/O realizado em cada teste, os gr�ficos com o comparativo entre estes filesystems.

Na Figura 1 podemos ver os resultados do teste para leitura sequencial. A partir do gr�fico apresentado � poss�vel observar alguns fatos interessantes, a saber:

1. A diferen�a causada pelo uso de cache nos testes. No caso de m�ltiplos arquivos pequenos, o acesso com cache foi 40 vezes mais r�pido do que o acesso direto;

2. Certa vantagem do ext3 e do JFS na leitura de poucos arquivos grandes, quando utilizando cache. Vantagem esta que desaparece quando utilizado I/O direto;

3. Pequena vantagem do ext3 e do XFS na leitura de m�ltiplos arquivos pequenos, quando utilizando cache, mas que tamb�m desaparece quando utilizado I/O direto;

4. O acesso direto a poucos arquivos grandes � aproximadamente 10 vezes mais r�pido do que o acesso a m�ltiplos arquivos pequenos.

Como pudemos observar, de modo geral os resultados s�o equivalentes, isto �, sem aparentes vencedores.

Figura 1. IOPS por filesystem, leitura sequencial.

Na Figura 2 podemos verificar os resultados dos testes para escrita sequencial.

Novamente o cache tem papel fundamental no desempenho, mas � poss�vel observar um padr�o diferente neste caso. O ext3 foi muito mais lento nas escritas com arquivos grandes do que os demais e nas escritas utilizando I/O ass�ncrono, mas foi mais r�pido no caso de acesso a m�ltiplos arquivos pequenos, com I/O s�ncrono. J� os demais filesystems tiveram desempenho equivalente.

Figura 2. IOPS por filesystem, escrita sequencial.

Na Figura 3 podemos ver os resultados do teste para um misto de leitura e escrita sequenciais.

Figura 3. IOPS por filesystem, leitura e escrita sequenciais.

Neste teste podemos perceber um padr�o similar ao encontrado no teste de escritas sequenciais, onde o ext3 � razoavelmente mais lento com arquivos grandes, e uma pequena vantagem para o ext4 e o xfs em alguns casos.

Na Figura 4 podemos ver os resultados do teste para leitura rand�mica.

Figura 4.IOPS por filesystem, leitura rand�mica.

Neste caso podemos perceber que o cache teve participa��o quase nula no desempenho, inclusive causando degrada��o de desempenho em alguns casos. Tanto para arquivos grandes como pequenos, o I/O direto e ass�ncrono se mostrou quase duas vezes mais r�pido.

Na Figura 5 s�o apresentados os resultados do teste para escrita rand�mica.

Figura 5. IOPS por filesystem, escrita rand�mica.

Neste caso percebemos o cache fazendo o seu papel novamente, elevando os n�meros significativamente. Como pode ser observado, em quase todos os testes o ext4 mostrou certa vantagem em rela��o aos demais, e o ext3 apresentou resultados inv�lidos (0) em dois casos, o que pode indicar algum bug no fio.

Foi poss�vel observar tamb�m um padr�o interessante, similar ao do teste de escritas sequenciais, no qual o ext3 teve um desempenho muito abaixo dos demais com cache e arquivos grandes, mas se saiu muito melhor com m�ltiplos arquivos pequenos.

Na Figura 6 s�o apresentados os resultados do teste para leitura e escrita rand�micas.

Figura 6. IOPS por filesystem, leitura e escrita rand�micas.

Neste caso, novamente o cache n�o teve papel importante e o ext3 foi o mais lento em quase todos os testes.

Por fim, na Figura 7 podemos ver os resultados do teste para leitura e escrita rand�micas, com quatro processos em paralelo, I/O s�ncrono e ass�ncrono.

Figura 7. IOPS por filesystem, leitura e escrita rand�micas e quatro processos.

Este teste pode ser considerado como um de perfil mais pr�ximo do real para um servidor, onde tipicamente ocorrem requisi��es de acesso ao disco em paralelo. Nele, podemos observar que o JFS foi ligeiramente melhor na maioria dos testes, com o ext4 e o XFS mostrando n�meros parecidos.

Al�m disso, podemos constatar que o cache fez pouca diferen�a e o ext3 mais uma vez se mostrou mais lento com cache do que com I/O direto.

� v�lido ressaltar que os testes foram realizados em condi��es gen�ricas, sem ter um caso de uso espec�fico em mente, e com hardware simples, com o �nico prop�sito de mostrar as diferen�as entre as principais op��es de sistemas de arquivos. Ao optar por um ou outro filesystem, � preciso ter em mente a finalidade a que ele se destina e o hardware que o suportar�.

Da� a import�ncia de se pensar em uma metodologia de testes e aprender a execut�-los por conta pr�pria. Neste contexto, o fio se mostrou uma �tima ferramenta, trazendo extrema flexibilidade e suporte a diversos cen�rios. Como p�de-se constatar, grande parte do trabalho de utiliz�-lo resume-se a definir os testes que s�o relevantes para o problema em quest�o.

Ap�s a an�lise dos resultados, podemos afirmar, de modo geral, que ext4, JFS e XFS apresentaram resultados consistentemente melhores do que os apresentados por ext3, com poucas exce��es, e muitas vezes equivalentes entre si. O JFS, relativamente pouco utilizado e conhecido, a n�o ser por quem conhece AIX, surpreendeu com �timos n�meros, compar�veis aos do XFS e ext4, que v�m se tornando refer�ncia no mundo Linux.

Como o JFS � um filesystem pouco difundido, e provavelmente possui uma comunidade menor ao seu redor, � preciso que se tenha uma justificativa muito boa para adot�-lo em ambientes cr�ticos de produ��o.

Por outro lado, tanto o XFS quanto o ext4 cada vez mais est�o se tornando os l�deres de aceita��o na plataforma Linux, e de acordo com os nossos testes, com raz�o, pois apresentaram resultados consistentes com a sua fama. A escolha por um ou outro se dar� mais por conta de alguma funcionalidade espec�fica que somente um ofere�a.

Como orienta��o final, fa�a seus pr�prios testes, adequados �s suas necessidades, e tire suas pr�prias conclus�es. Nestas situa��es, testes e comparativos s�o insubstitu�veis.

• Linux