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, já que tenho um árvore de arquivos com intervalos, para que eu possa facilmente ter sistemas de arquivos separados montados em 1/ , 2/ , 3/ , 4/ , etc).
A minha dificuldade está em encontrar qualquer enumeração do que é um tamanho "razoável" para um sistema de arquivos, para manter o tempo fsck similarmente "razoável". 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 o ext3 fsck vezes com tamanhos variáveis do 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 em 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, qualquer anedota sobre essas questões deve, pelo menos, ajudar a orientar minha própria experimentação, se isso for necessário.
EDIT : Para esclarecer: independentemente do sistema de arquivos, se algo der errado com os metadados, ele precisará ser verificado. Se re-fscks baseados em tempo ou montagem são ativados ou necessários não está em questão, e a única razão pela qual eu 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 ele precisa ser uma opção robusta (afirma que "o sistema de arquivos X nunca precisa de fscking!" Será ridicularizado) . Eu 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 falha, em vez de fscking, parece realmente, realmente troca idiota.
De acordo com um paper 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 certo ponto. Se o gráfico servir de base, você será mais eficiente com sistemas de arquivos de até 10 milhões de inodes.
Mudar para o 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 a não verificar inodes marcados como não utilizados) não tem efeito perceptível.
Eu acho que você vai ter que fazer o 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 os dados. Se você puder usar dados que se pareçam com seus dados de produção, (arquivos por diretório, distribuição de tamanho de arquivo, etc.), então será melhor. Note que simplesmente copiar arquivos de outra partição do dispositivo de backup irá colocá-los no disco perfeitamente definidos e desfragmentados e, portanto, seus testes não terão muitos tempos de busca do cabeçote do disco que virão de muitos write / modify / deletes. p>
Você também precisará pensar um pouco sobre fscks paralelos. Veja o último par de campos em / etc / fstab. Partições no mesmo disco físico devem ser feitas em seqüência; vários discos no mesmo controlador podem ser feitos em paralelo, mas tome cuidado para não sobrecarregar o controlador e retardá-los.
existe alguma razão pela qual você não pode usar um sistema de arquivos que não force o tempo ou os fscks baseados em contagem de montarias em você quando você reinicia?
(o fscks baseado em tempo realmente me irrita - para um servidor de longa data, ele 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 de registro no diário que não forçam um fsck. vale uma olhada.