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!