Para fsck ou não fsck após 180 dias

Question

Por padrão, após 180 dias ou algum número de montagens, a maioria dos sistemas de arquivos Linux forçam uma verificação do sistema de arquivos (fsck). Claro que isso pode ser desligado usando, por exemplo, tune2fs -c 0 -i 0 no ext2 ou ext3.

Em sistemas de arquivos pequenos, essa verificação é apenas uma inconveniência. No entanto, dados sistemas de arquivos maiores, essa verificação pode levar horas e horas para ser concluída. Quando seus usuários dependem deste sistema de arquivos para sua produtividade, digamos que ele está servindo seus diretórios home via NFS, você desabilitaria a verificação do sistema de arquivos agendados?

Eu faço esta pergunta porque atualmente são 02:15 e estou aguardando um fsck muito longo para completar (ext3)!

    

Answer 1

O tempo fsck padrão de 180 dias é uma solução para a falha de design que o ext3 não suporta uma verificação de consistência online. A solução real é encontrar um sistema de arquivos que suporte isso. Eu não sei se algum sistema de arquivos maduro faz. É uma tragédia real. Talvez btrfs nos salve um dia.

Respondi à questão do tempo de inatividade surpresa de várias horas do fsck fazendo reinicializações programadas com um fsck completo como parte da manutenção padrão. Isso é melhor do que se deparar com uma pequena corrupção durante as horas de produção e transformá-lo em uma interrupção real.

Uma grande parte do problema é que o ext3 tem um fsck excessivamente lento. Embora o xfs tenha um fsck muito mais rápido, ele usa muita memória para distribuições para encorajar o xfs por padrão em sistemas de arquivos grandes. Ainda assim, na maioria dos sistemas, isso não é um problema. Mudar para o xfs pelo menos permitiria um fsck razoavelmente rápido. Isso pode tornar mais fácil programar o fsck como parte da manutenção normal.

Se você está rodando RedHat e considerando o uso do xfs, você tem que tomar cuidado com o quão strongmente eles desencorajam o uso do xfs e o fato de que provavelmente há poucas pessoas usando o xfs no kernel que você está rodando.

Meu entendimento é que o projeto ext4 tem um objetivo de melhorar um pouco o desempenho do fsck.

    

Answer 2

Eu diria que essa é apenas outra razão pela qual os servidores de produção não devem ser executados sozinhos e sempre ter um backup quente / frio ou participar de um cluster de dois nós. Nestes dias de virtualização, você pode facilmente ter um servidor principal físico e um servidor virtual, que é apenas uma cópia do físico feito a cada X dias, pronto para assumir o controle.

Outra resposta não tão útil, eu diria que você deve equilibrar a importância dos seus dados ... Se este é apenas um nó do cluster, pule-o. Se este for um servidor da Web não-backup de um cliente, talvez você queira planejar com antecedência da próxima vez: -)

    

Answer 3

Depende .. Por exemplo, tivemos um servidor desligado para manutenção de rotina que estava executando uma pilha QMail. O QMail cria e mata muitos arquivos com o passar do tempo, e era um servidor de correio muito ocupado. O fsck levou cerca de 36 horas. Não é como se tivéssemos salvado um monte de desempenho do negócio, mas no fim das contas eu suponho que você poderia argumentar que o sistema de arquivos era mais saudável. Valeu a pena o caos que se seguiu? Não. Em. Tudo.

    

Answer 4

O XFS é interessante. É um FS sempre consistente. Não precisa de fsck. Isso não causará tempo de inatividade devido ao fsck.

Mas tem outro problema. Você precisa de um controlador RAID com suporte para lidar com blocos ruins do disco rígido.

O XFS não tem o recurso para bloquear blocos ruins na lista negra quando o SO começa a ficar sabendo sobre blocos defeituosos e a lista de blocos danificados do hardware da HDD está cheia.

ext2 / 3/4, fat, ntfs, etc (teste offline) são capazes de colocar blocos ruins na lista negra, mas não no XFS.

Portanto, para instalações não corporativas, o XFS provavelmente não combina bem com isso. Eu estou usando o XFS com o software linux raid1 para partições de backup, onde o conteúdo é um monte de pequenos arquivos com pouca mudança ao longo do tempo.