
Estou fazendo a configuração de um farm de armazenamento em grande escala e, para evitar a necessidade de fscks de um mês, meu plano é dividir o armazenamento em vários sistemas de arquivos menores (isso é bom, pois tenho uma árvore de arquivos bem agrupada , para que eu possa facilmente ter sistemas de arquivos separados montados em 1/
, 2/
, 3/
, 4/
, etc).
Minha dificuldade é encontrar qualquer enumeração de qual é o tamanho "razoável" para um sistema de arquivos, para manter os tempos de fsck igualmente "razoáveis". Embora eu esteja plenamente ciente de que o tempo absoluto para um determinado tamanho dependerá em grande parte do hardware, não consigo encontrar nenhuma descrição da forma da curva para tempos ext3 fsck com tamanhos variados de sistema de arquivos e quais são as outras variáveis ( um sistema de arquivos cheio de arquivos em um único diretório leva mais tempo do que um com 10 arquivos em cada um dos milhares de diretórios em uma árvore;
Alguém tem referências a algum número bem pesquisado sobre isso? Caso contrário, quaisquer anedotas sobre estas questões deverão pelo menos ajudar a orientar a minha própria experimentação, caso seja necessário.
EDITAR: Para esclarecer: independente do sistema de arquivos, se algo der errado com os metadados, ele precisará ser verificado. Se os re-fscks baseados em tempo ou montagem estão habilitados ou necessários, não está em questão, e a única razão pela qual estou pedindo números especificamente em relação ao ext3 é porque esse é o sistema de arquivos mais provável a ser escolhido. Se você conhece um sistema de arquivos que possui um processo fsck particularmente rápido, estou aberto a sugestões, mas precisa ser uma opção robusta (afirmações de que "o sistema de arquivos X nunca precisa de fsck!" serão ridicularizadas e ridicularizadas longamente) . Também estou ciente da necessidade de backups, e o desejo de fsck não é um substituto para backups, no entanto, apenas descartar o sistema de arquivos e restaurar a partir do backup quando ele apresenta falhas, em vez de fsck, parece realmente,realmentetroca idiota.
Responder1
De acordo com umartigo de Mathur et al.(p. 29), o tempo de e2fsck cresce linearmente com a quantidade de inodes em um sistema de arquivos após um certo ponto. Se o gráfico servir de referência, você é mais eficaz com sistemas de arquivos de até 10 milhões de inodes.
Mudar para ext4 ajudaria - sob a condição de que seu sistema de arquivos não esteja carregado até a borda, onde o ganho de desempenho (devido à não verificação de inodes marcados como não utilizados) não tem efeito discernível.
Responder2
Acho que você terá que fazer seu próprio benchmarking. Uma pesquisa rápida no Google não revelou nada, exceto que o ext4 fscks é muito mais rápido que o ext3.
Portanto, crie algumas partições ext3, 100GB, 200GB, etc. até o tamanho do disco que você usará. Em seguida, preencha-os com dados. Se você puder usar dados semelhantes aos seus dados de produção (arquivos por diretório, distribuição de tamanho de arquivo etc.), será melhor. Observe que simplesmente copiar arquivos de outra partição ou dispositivo de backup os colocará no disco perfeitamente organizados e desfragmentados e, portanto, seus testes não terão muitos tempos de busca da cabeça do disco que virão de muitas gravações/modificações/exclusões.
Você também precisará pensar um pouco sobre fscks paralelos. Veja os últimos campos em /etc/fstab. As partições no mesmo disco físico devem ser feitas em sequência; vários discos no mesmo controlador podem ser feitos em paralelo, mas tome cuidado para não sobrecarregar o controlador e torná-los lentos.
Responder3
http://lmgtfy.com/?q=fsck+benchmark
parece que o fsck nos sistemas de arquivos ext4 é significativamente mais rápido que no ext3, com alguns relatórios de ext4 fsck sendo 10 ou até mais vezes mais rápido que o ext3.
dois artigos bastante interessantes dessa pesquisa são:
http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ehttp://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/
Responder4
existe alguma razão pela qual você não pode usar um sistema de arquivos que não force fscks baseados em tempo ou contagem de montagem quando você reinicia?
(os fscks baseados em tempo realmente me incomodam - para um servidor com longo tempo de atividade, isso praticamente garante que você terá que fazer um fsck completo sempre que atualizar o kernel).
de qualquer forma, o XFS é um dos sistemas de arquivos com diário que não força um fsck. vale a pena dar uma olhada.