Português do Brasil English
Devin no Facebook  Devin no Twitter  RSS do Site 
Linux    

Verificação automática dos sistemas de arquivos (auto-fsck)


Comentários  15
Visualizações  
76.980

Não importa que sistema ou distribuição Linux você esteja usando, sempre há um sistema de arquivos armazenando os seus dados. Há alguns anos atrás, os sistemas de arquivos (ou filesystems, em inglês) não eram tão modernos e precisam de alguns cuidados. Por exemplo: ao usar o sistema de arquivos ext2, se o computador fosse reiniciado ou desligado de forma forçada (o famoso dedoff, ou seja, mete o dedo no botão), logo na inicialização do Linux era feita a verificação de todo o sistema de arquivos, procurando por inconsistências, erros, arquivos e dados perdidos, essas coisas. Dependendo do tamanho do disco, isso poderia demorar vários minutos ou até horas…

Com os sistemas de arquivos mais modernos isso não acontece. Exemplo: ext3, ext4, XFS, ReiserFS, brtfs, entre outros. Todos esses sistemas de arquivos possuem uma funcionalidade muito útil chamada de journaling, uma espécie de meu querido diário. Com o journaling, as operações do sistema de arquivos são gravadas em um log, antes de começar e depois que acabou a operação. Assim, se algo falhar no caminho, o sistema de arquivos lê o log e sabe exatamente como consertar ou refazer (ou não fazer). Isso evita termos que ficar esperando uma verificação completa em todo o sistema de arquivos….

Mas mesmo assim, pode acontecer algum erro! E nesse caso, a verificação se torna necessária. Às vezes é até bom fazer uma verificação, depois de alguns anos rodando… Assim você pode até encontrar alguma falha e corrigí-la antes de dar algum problema.

Muitas vezes os administradores possuem máquinas que funcionam apenas como servidores. Essas máquinas geralmente ficam ali encostadas, sem ninguém mexer, sem monitor, teclado, ou mouse. Depois de configuradas corretamente, podem ser muito bem usadas via acesso remoto (SSH), então não importa o estado dela. Isso é verdade principalmente em cloud computing e servidores dedicados em data centers externos, onde o acesso físico a máquina é inexistente aos administradores.

Se acontecer alguma coisa com o sistema de arquivos por acaso… Se o faxineiro que não entende de nada resolve desligar a máquina porque parece que não está sendo usada? E se a energia cair? Quando o Linux voltar, o sistema de arquivos dele pode estar corrompido, e então começar a fazer uma verificação completa (no caso dos sistemas de arquivos mais antigos)…

É aí que entra o fsck e o nosso assunto (auto-fsck)!

Verificando automaticamente na inicialização (genérico)

Precisamos fazer com que o sistema verifique o disco sem a intervenção do usuário, toda vez que ele for desligado de forma incorreta. Para fazer isso, usamos o comando fsck e alguns macetes divertidos. Podemos até usar esses métodos para, de vez em quando, programar uma verificação após um reboot esperado.

Primeiro vamos ao método genérico, que acredito que funcione em todas as distribuições. Toda vez que o Linux é iniciado e monta suas partições, ele verifica se o disco foi desmontado da última vez de forma correta ou não. Dependendo da severidade, ele faz a verificação completa ou não. Para forçar a verificação no próximo boot, independente dele ser considerado bom ou não, é só criar um arquivo assim:

touch /forcefsck

Com o arquivo /forcefsck, no próximo boot a partição raiz (/) será verificada automaticamente, independente de ter desligado natoralmente ou não. Note que para cada partição criada, você pode forçar a verificação de cada uma. Por exemplo, se meu sistema tem as partições:

/dev/sda1 no /boot
/dev/sda2 no /
/dev/sda3 no /home

Então, pra verificar todos os sistemas de arquivos, eu crio um arquivo para cada partição:

touch /boot/forcefsck
touch /forcefsck
touch /home/forcefsck

Ah, mas mesmo assim o sistema pode ter erros cabeludos e necessitar que um usuário com acesso à console e teclado diga ao sistema para corrigir os erros. Para solucionar isso, a gente deve dizer ao fsck para corrigir tudo automaticamente e sem intervenções, criando outro arquivo assim:

echo '-p' > /fsckoptions

O parâmetro -p, de acordo com a página de manual do fsck diz ao programa para corrigir todos os erros automaticamente. O comando acima colocou um -p dentro do arquivo /fsckoptions, que será lido pelo fsck no próximo boot. Dessa forma a verificação na partição raiz vai ser feita de forma totalmente automática, mesmo encontrando aquele pau gozado de sistema de arquivos que costuma dar nas piores horas.

Criando esses arquivos, a verificação fica sempre automática! Legal não?

Não! Isso quer dizer que vamos ter que esperar essa verificação toda vez que o Linux for iniciado, mesmo ele tendo sido desligado corretamente. As distribuições mais modernas apagam o arquivo forcefsck logo depois que a verificação foi feita forçadamente e é uma boa para fazer uma verificação programada em um próximo reboot. Mas e pra deixar isso automático?

A solução genérica para este problema é colocar os dois comandos citados acima, que criam os arquivos forcefsck e fsckoptions em um arquivo de inicialização. No RHEL/Fedora seria no /etc/rc.d/rc.local, e no Debian/Ubuntu seria no /etc/rc.local. Depois basta colocar dois comandos de remoção dos arquivos na hora de desligar o sistema. Em outras palavras:

Na inicialização:

#!/bin/bash
touch /forcefsck
echo '-p' > /fsckoptions

E ao reiniciar/desligar a máquina:

#!/bin/bash
rm -f /forcefsck
rm -f /fsckoptions

Com esses comandos nos lugares certos, toda vez que o sistema for iniciado, ele vai criar os dois arquivos. Mas se o sistema for reiniciado ou desligado corretamente, no processo de desligamento estes arquivos serão removidos, e no próximo boot a verificação não ocorrerá. Caso ele desligue ou reinicie abruptamente, os comandos de remoção não irão ocorrer e os arquivos estarão lá na próxima inicialização, forçando a verificação.

Nota: Aqui no Devin temos tutoriais de como incluir comandos/serviços na inicialização e desligamento. Confira nos artigos: Scripts Init no Linux – Parte 1 e Upstart – Scripts Init no Linux – Parte 2.

O script dos comandos de reinicialização/desligamento podem ser colocados como um link simbólico no sistema tradicional de init (SystemV). Supondo que o arquivo seja o /usr/local/bin/apagar-arquivos-fsck, execute o comando como root:

# permissão de execução para o script
chmod 755 /usr/local/bin/apagar-arquivos-fsck

# link simbolico para executar o script no desligamento:
ln -s /usr/local/bin/apagar-arquivos-fsck /etc/rc0.d/K99apagar-arquivos-fsck
# link simbolico na reinicialização
ln -s /usr/local/bin/apagar-arquivos-fsck /etc/rc6.d/K99apagar-arquivos-fsck

Usando a automatização das distribuições

Agora o método usado pelas distribuições!

Para fazer o mesmo processo descrito acima em sistemas RHEL/Fedora, basta apenas criar o arquivo /etc/sysconfig/autofsck com o conteúdo:

AUTOFSCK_TIMEOUT=5
AUTOFSCK_DEF_CHECK=yes
AUTOFSCK_OPT="-p"

Assim o padrão para quando o sistema for desligado incorretamente será fazer a verificação com o fsck (AUTOFSCK_DEF_CHECK), com a opção -p (AUTOFSCK_OPT). É só salvar este arquivo que as modificações já entram em vigor.

Em sistemas Debian/Ubuntu, basta editar o arquivo /etc/default/rcS e configura a seguinte variável:

FSCKFIX=yes

Dessa forma, ele vai usar a opção -p para não necessitar de intervenção manual.

Configurações do sistema de arquivos com o tune2fs

Antes de acabar o artigo, uma informação relacionada muito interessante, um bônus! Todo sistema de arquivo tem seus metadados, que podem ser considerados suas configurações. Essas configurações incluem coisas como: nome e label do volume, tamanho do inode, tamanho dos blocos, quantidade de blocos reservados pro root, quando foi criado, montado ou modificado, qual as funcionalidades suportadas, tipo de journal, e muito mais.

Para visualizar, usamos o comando tune2fs. Por exemplo, minha partição /boot aqui na máquina:

[eitch@tyrion ~]$ sudo tune2fs -l /dev/sda1
 
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /boot
Filesystem UUID:          ac4fbd99-d6d6-4cbc-8544-2f67d5374eae
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              128016
Block count:              512000
Reserved block count:     25600
Free blocks:              385569
Free inodes:              127646
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2032
Inode blocks per group:   254
RAID stride:              4
RAID stripe width:        4
Flex block group size:    16
Filesystem created:       Fri Mar 15 10:15:28 2013
Last mount time:          Wed Sep 25 04:19:17 2013
Last write time:          Wed Sep 25 04:19:17 2013
Mount count:              150
Maximum mount count:      -1
Last checked:             Fri Mar 15 10:15:28 2013
Check interval:           0 (<none>)
Lifetime writes:          136 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      adab03b5-9415-4563-9c05-715bb172a70c
Journal backup:           inode blocks
[eitch@tyrion ~]$ sudo tune2fs -l /dev/sda1
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /boot
Filesystem UUID:          ac4fbd99-d6d6-4cbc-8544-2f67d5374eae
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              128016
Block count:              512000
Reserved block count:     25600
Free blocks:              385569
Free inodes:              127646
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2032
Inode blocks per group:   254
RAID stride:              4
RAID stripe width:        4
Flex block group size:    16
Filesystem created:       Fri Mar 15 10:15:28 2013
Last mount time:          Wed Sep 25 04:19:17 2013
Last write time:          Wed Sep 25 04:19:17 2013
Mount count:              150
Maximum mount count:      -1
Last checked:             Fri Mar 15 10:15:28 2013
Check interval:           0 (<none>)
Lifetime writes:          136 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      adab03b5-9415-4563-9c05-715bb172a70c
Journal backup:           inode blocks

As informações interessantes para nós nesse momento, relacionadas à verificação de disco são essas:

  • Mount count: Quando esse sistema de arquivos for montado essa quantidade de vezes, na próxima vez ele força uma verificação. No exemplo anterior, depois que eu montar 150 vezes a partição /boot, na vez número 151 ele vai forçar a verificação e recomeçar a contagem. 0 ou -1 significa nunca forçar.
  • Check interval: De quanto em quanto tempo ele força a verificação. O número mostrado está em dias. 0 (no exemplo) ou -1 significa nunca forçar.

Pra configurar esses parâmetros, basta usar o mesmo tune2fs, assim:

# configura para forçar a verificação a cada 50 montagens
tune2fs -c 50 /dev/sda1

# configura para forçar a verificação a cada 30 dias
tune2fs -i 30 /dev/sda1

# configura para forçar a veriricação a cada 3 meses (repare o 'm' no numero)
tune2fs -i 3m /dev/sda1

# configura para nunca forçar a verificação!
tune2fs -c 0 /dev/sda1
tune2fs -i 0 /dev/sda1

Interessante, não? :)

Referências

  • man 8 fsck
  • man 8 tune2fs
  • Dica do /etc/default/rcS no Debian/Ubuntu apontada pelo Maxwel Leite. Obrigado!
76.980

Comentários  15
Visualizações  
76.980


TagsLeia também

Apaixonado por Linux e administração de sistemas. Viciado em Internet, servidores, e em passar conhecimento. Idealizador do Devin, tem como meta aprender e ensinar muito Linux, o que ele vem fazendo desde 1997 :-)


Leia também



Comentários

15 respostas para “Verificação automática dos sistemas de arquivos (auto-fsck)”

  1. Altair disse:

    Muito legal. sempre me ligam dizendo que o sistema pifou , que não inicia mais… Quando na verdade só passo o fsck e tudo volta a funcionar!

    Queria saber se funciona no Linux Educacional.

  2. Daniel disse:

    E se for ext4 ? Quando há problemas o fsck.ext4 reinicia automaticamente … ai é problema.

    Mas para o ReiserFS e EXT3 funciona perfeitamente.

  3. neri disse:

    ver estorico do msn

  4. Carlos disse:

    Dica de 2005 me ajudando em 2011, isso é LINUX!!!

    Parabéns pela explicação!!!

    Abraços

  5. Alex disse:

    tenho uma duvida sobre um detalhe no arquivo que é criado no redhat, com a opçao "-p" ele faz so se eu desligar incorretamente, mas e se eu quiser fazer msmo que for delisgado normal. como faço?

    abraço

  6. Maxwel Leite disse:

    Para o Ubuntu/Debian, basta editar o arquivo /etc/default/rcS que equivale ao /etc/sysconfig/autofsck:

    sudo nano /etc/default/rcS

    Ótimo artigo, ajudou muito. Obrigado!

  7. sidney3 disse:

    E aí Eitch! Há quanto tempo!!! Tem notícias do pessoal do #linuxall ?

    Abração e sucesso!!!

  8. Charles disse:

    Olá pessoal !
    Tenho um servidor SLES 11SP2 que monta via iSCSI uma storage de 4TB. Estou com um problema, pois o sistema de arquivos(reiserfs) desmonta sozinho e depois ele monta a partição como somente leitura. Segue o fstab:

    /dev/dm-1 /bkp reiserfs user,hotplug 0 0

    Meu problema é que ele fica funcionando por um tempo, depois quando começo a enviar dados para ele, o servidor remonta, sozinho, o mapeamento somente como leitura.
    Alguém já teve esse problema….

  9. iluy sperry disse:

    Parabéns cara. Muito sucesso pra ti. Ótima dica. Melhor forma de rodar fsck sem usar um disco de boot.

  10. Leandro disse:

    Sinceramente meu caro o seu blog é um dos melhores que já li na minha modesta opinião e leio muito.
    Você tem um linguagem simples e que serve pra níveis soft ou hard :-), são de conteúdos assim que precisamos no mundo linux parabéns.
    Queria deixar isso registrado e fazer justiça a bons conteúdos se precisar de alguma ajuda com postagem ou algo envolvendo algum projeto linux me contacte.

    Sucesso.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *