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

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

Em sistemas de arquivos pequenos, essa verificação é apenas um inconveniente. No entanto, dados sistemas de arquivos maiores, essa verificação pode levar horas e horas para ser concluída. Quando seus usuários dependem desse sistema de arquivos para obter sua produtividade, digamos que ele esteja servindo seus diretórios pessoais via NFS, você desabilitaria a verificação agendada do sistema de arquivos?

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

O tempo fsck padrão de 180 dias é uma solução alternativa 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. Não sei se existe algum sistema de arquivos maduro. É uma verdadeira tragédia. Talvez o btrfs nos salve um dia.

Eu respondi à questão do surpreendente tempo de inatividade 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 enfrentar uma corrupção menor durante o horário de produção e transformá-la em uma falha 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 incentivar o xfs por padrão em grandes sistemas de arquivos. Ainda assim, na maioria dos sistemas, isso não é problema. Mudar para xfs permitiria pelo menos um fsck razoavelmente rápido. Isso pode facilitar a execução do fsck como parte da manutenção normal.

Se você estiver executando o RedHat e pensando em usar o xfs, você deve ter cuidado com o quão fortemente eles desencorajam o uso do xfs e o fato de que provavelmente existem poucas pessoas usando o xfs no kernel que você está executando.

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

Eu diria que esse é apenas outro motivo pelo qual os servidores de produção não devem ser executados sozinhos e sempre têm um backup a quente / frio ou participam 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.

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

Depende .. Por exemplo, tivemos um servidor inativo para manutenção de rotina que estava executando uma pilha do 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 economizado muito desempenho fora do negócio, mas no final suponho que você pudesse argumentar que o sistema de arquivos era mais saudável. Realmente valeu o caos que se seguiu? Não. At. Todos.

XFS é interessante. É um FS sempre consistente. Não precisa do fsck. 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 defeituosos do HDD.

O XFS não tem o recurso de colocar na lista negra os blocos defeituosos quando o sistema operacional começa a saber sobre os blocos defeituosos e a lista de blocos defeituosos do hardware do HDD está cheia.

ext2 / 3/4, fat, ntfs, etc (teste offline) podem colocar na lista negra os blocos defeituosos, mas não o XFS.

Portanto, para instalações não corporativas, o XFS provavelmente não se adequa bem. Estou usando o XFS com o software linux raid1 para partições de backup, nas quais o conteúdo contém muitos arquivos pequenos, sem muitas alterações ao longo do tempo.