ext3 fsck time versus tamanho da partição


9

Estou fazendo a configuração de um farm de armazenamento em larga 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 compactada) , de modo que pode facilmente ter sistemas de ficheiros separados montados em 1/, 2/, 3/, 4/, etc.).

Minha dificuldade está em encontrar qualquer enumeração do tamanho "razoável" de um sistema de arquivos, para manter os tempos de fsck da mesma forma "razoáveis". Embora eu esteja 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 os 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 de um com 10 arquivos em cada um dos milhares de diretórios de uma árvore; arquivos grandes versus arquivos pequenos; sistema de arquivos completo versus sistema de arquivos vazio; e assim por diante).

Alguém tem referências a números bem pesquisados ​​sobre isso? Caso contrário, quaisquer histórias sobre esses problemas devem pelo menos ajudar a guiar minha própria experimentação, caso isso seja necessário.

EDIT : Para esclarecer: independentemente 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 ativados ou necessários, não está em questão, e a única razão pela qual estou pedindo números especificamente a respeito do 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 ele precisa ser uma opção robusta (as alegações de que "o sistema de arquivos X nunca precisa ser fscking!" Serão ridicularizadas e ridicularizadas) . Também estou ciente da necessidade de backups, e o desejo de fsck não é um substituto para os backups, no entanto, apenas descartar o sistema de arquivos e restaurar o backup quando ele falha, em vez de fscking, parece realmente um,

Respostas:


6

De acordo com um artigo de Mathur et al. (p. 29), o tempo do e2fsck cresce linearmente com a quantidade de inodes em um sistema de arquivos após um determinado ponto. Se o gráfico é algo que você precisa, você é mais eficiente 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 seja carregado até a borda, onde o ganho de desempenho (devido à verificação de inodes marcados como não utilizados) não tem efeito discernível.


Obrigado por essa referência, ajudou a confirmar algumas coisas para mim. Também realizei meu próprio benchmarking, que suportou o crescimento linear mostrado nesse artigo.
Womble

2

Eu 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, 100 GB, 200 GB, etc. até o tamanho do disco que você usará. Em seguida, preencha-os com dados. Se você puder usar dados que se assemelhem aos dados de produção (arquivos por diretório, distribuição de tamanho de arquivo etc.), isso será o melhor. Observe que a simples cópia de arquivos de outra partição ou dispositivo de backup os colocará no disco perfeitamente disposto e desfragmentado e, portanto, seus testes não terão muito tempo de busca na cabeça do disco que ocorrerá com muitas gravações / modificações / exclusões.

Você também precisará pensar um pouco sobre fscks paralelos. Veja os últimos campos em / etc / fstab. Partições no mesmo disco físico devem ser feitas em sequência; vários discos no mesmo controlador podem ser executados em paralelo, mas tome cuidado para não sobrecarregar o controlador e atrasá-los.



-1

existe alguma razão pela qual você não pode usar um sistema de arquivos que não force o tempo ou fscks baseados em contagem de montagem quando reinicializar?

(os fscks baseados no tempo realmente me incomodam - para um servidor de tempo de atividade, ele praticamente garante que você terá que executar um fsck completo sempre que atualizar o kernel).

de qualquer maneira, o XFS é um dos sistemas de arquivos com registro em diário que não força um fsck. vale uma olhada.


outra opção é usar o Nexenta (kernel opensolaris, debian userland), o que forneceria o ZFS. <A href=" nexenta.org/"> http://www.nexenta.org/</A >
cas

3
Quando um sistema de arquivos é corrompido, independentemente do que é (extN, XFS, ZFS, o que for), ou se você tem uma contagem de tempo / montagem, ele precisa de um fsck. Quero garantir que um único sistema de arquivos corrompido não leve muito tempo para fsck.
Womble

1
Sim, é claro que um fs precisa de um fsck se estiver corrompido. usar um fs como o XFS não os eliminará, nem você deve tentar ou mesmo querer. Não disse nada que pudesse ser interpretado de outra maneira. Meu argumento foi que forçar um fsck apenas porque já faz muitos dias ou muitas montagens desde que o último fsck é desnecessário, irritante e possivelmente até "limitador de carreira", especialmente se seus usuários ou sua empresa estão esperando o servidor chegar de volta. você pode eliminar esses fscks desnecessários, e isso é uma coisa boa.
cas

Por melhor que seja (ou não), não responde à pergunta colocada.
Womble
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.