Quanto tempo o fsck pode suportar um volume de 30 TB?

Em meados de novembro, um VPS que estou alugando de uma empresa de hospedagem parou de responder. Quando entrei em contato com o suporte, eles explicaram que uma queda de energia no datacenter causou uma reinicialização forçada e um fsck. Por fim, perguntei por que estava demorando tanto e me disseram que o tamanho do volume é de 30 TB. A última vez que recebi uma atualização foi em fevereiro e eles não responderam à minha consulta mais recente.

Entendo que o fsck pode ser muito lento para alguns sistemas de arquivos, mas é possível que o fsck demore 6 meses em um volume de 30 TB ou devo assumir que essa empresa de hospedagem está mentindo para mim para continuar pagando minha conta a cada mês?

fscka velocidade depende principalmente do número de arquivos e de como eles estão espalhados no respectivo diretório. Dito isto, 6 meses por um fscké absolutamente absurdo: ele deveria ter sido concluído em algumas horas, no máximo, especialmente se o uso xfstiver o xfs_repairutilitário rápido . Aqui você encontra algumas fsckcorridas em escala - todas concluídas em menos de uma hora (3600s). Portanto, não é possível que você fsckainda esteja em execução.

De qualquer forma, uma perda inesperada de energia não causará um golpe completo fsck, mas apenas uma repetição de diário muito rápida (alguns segundos) . No entanto, se alguns arquivos principais foram danificados, o sistema operacional pode não ser inicializado.

Mas eles provavelmente só mentiram para você. Você deve parar de pagar imediatamente, pedir uma explicação e solicitar um reembolso total.

Conjectura: seu sistema usa um RAID sem BBU / FBWC (ou mesmo RAID de software) com todos os caches de gravação possíveis (incluindo os próprios discos rígidos) definidos nas configurações mais agressivas, para obter o máximo desempenho por um custo mínimo. Uma falta de energia nessa configuração pode deixar um sistema de arquivos de registro em diário em uma condição em que o diário não pode ser confiável e não pode ser usado para recuperação. O problema é que esse sistema reordena e adia de maneira agressiva as gravações, o que significa que uma entrada no diário pode ser gravada com o efeito de perda da ação de dados ... ou a entrada no diário sendo perdida em uma ação de dados que foi consequente.

Recuperar esse sistema de uma interrupção na pior das hipóteses pode significar que você precisa executar um reparo / reparo "lento" que realmente examine todas as estruturas do sistema de arquivos como elas são, o que pode levar um dia ou dois para 30 TB ... e não é improvável que você precise executar vários ciclos de reparo. Acrescente a isso que nem sempre o pessoal está disponível para monitorar isso; você pode facilmente reduzir um fsck por semana. Eles provavelmente desistiram e esqueceram.

Para a maioria dos sistemas de arquivos, será muito mais rápido, mesmo quando houver erros, pois normalmente apenas os metadados são verificados.

Na pior das hipóteses, ele pode ler o disco inteiro ( por exemplo, algo como fsck.ext4 -cc /dev/sda, que faz um teste de gravação não destrutivo em cada bloco), que pode levar alguns dias para 30 TB. Se você souber a velocidade das unidades, poderá calcular o tamanho / velocidade . Para um disco rígido de consumidor com cerca de 100 MB / s, copiar alguns TB pode levar mais horas do que a maioria das pessoas esperaria.

Se fosse o seu servidor, você poderia ter o problema de inicializar e, em seguida, travar quando fsckperguntado se você deseja corrigir um erro. Mas o administrador do datacenter não ficará fsckparado por 6 meses enquanto todos os VPS estiverem offline.

Então, eles estão mentindo para você ou há um enorme mal-entendido. Ou eles estavam executando o fsck há algum tempo e não atualizavam você sobre o novo problema após a conclusão.