Eu tenho um HDD que ainda roda em um sistema Debian Stretch com kernel 4.9. O HDD também foi mkfs naquele kernel. Quando monto manualmente o HDD nele, há alguns ruídos de acesso curtos e quase inaudíveis.
Quando eu inicializo um Linux com kernel 5.15 ou 6.2 e monto o HDD lá, ele fica muito barulhento e barulhento por cerca de 8 segundos, aparentemente causado por acessos em todo o HDD, como uma espécie de verificação rápida intensiva.
Qual é a razão para isto? E se for possível: isso pode ser desabilitado ou pelo menos limitado a todas as X startups sem desvantagens?
Versões mais recentes do kernel Linux irão pré-buscar bitmaps de bloco quando o sistema de arquivos for montado para leitura/gravação. Isso é feito em segundo plano com uma prioridade mais baixa, para evitar que qualquer tarefa em primeiro plano fique lenta. O objetivo desta pré-busca é evitar gravações síncronas --- por exemplo, se você estiver executando uma carga de trabalho de banco de dados ou um servidor NFS, o fsync ou o requisito para a gravação do sistema de arquivos será persistente antes de poder ser reconhecido pelo cliente NFS --- pode levar muito tempo, se o espaço livre do sistema de arquivos estiver muito fragmentado, quando o sistema de arquivos for montado pela primeira vez.
Isso tendia a ser um problema para usuários mesquinhos que deixavam o dispositivo de bloco da nuvem chegar a 99% cheio e, em seguida, aumentavam-no em uma pequena quantidade de espaço - digamos, 10 GB, e então esperavam até que o dispositivo de bloco chegasse a 99% e, em seguida, forneça mais 10 GB e assim por diante. Isso não apenas causou quedas graduais de desempenho, mas depois que a VM foi reinicializada e o sistema de arquivos foi reinicializado recentemente, agora, na primeira vez que uma alocação de bloco síncrona é tentada, o alocador de bloco pode precisar ler potencialmente milhares de bitmaps de bloco para encontre um conjunto contíguo de blocos para posicionamento ideal de dados --- ou comprometa-se usando um monte de blocos singleton livres de 4k, resultando em um arquivo muito fragmentado.
Para corrigir isso, primeiro, tentamos passar a mensagem de que tentar economizar até o último centavo esperando até o último minuto e depois aumentar o dispositivo de bloco em uma quantia realmente pequena é uma ideia incrivelmente estúpida, já que os poucos centavos que você tem em custos de armazenamento, é inundado pelo custo da CPU e pela redução de transações por segundo. Em seguida, fazemos a pré-busca em segundo plano dos bitmaps de bloco e, finalmente, se nem todos os bitmaps de bloco forem lidos no momento em que precisamos fazer uma alocação, ajustamos o alocador de bloco para tentar ser menos perfeccionista ao encontrar o melhor possível alocação de blocos e opte por um arquivo um pouco mais fragmentado como sendo preferível a um fsync que leva vários minutos (em alguns piores casos espetacularmente patológicos).
A pré-busca de bitmap de bloco praticamente não tem desvantagens e muitas vantagens, por isso está habilitada por padrão. Mas se esses poucos segundos de atividade do disco forem ofensivos para você, você pode desativá-los por meio da opção de montagem no_prefetch_block_bitmaps. (A opção de montagem servia principalmente para depuração, para que pudéssemos fazer experimentos A/B enquanto o recurso estava sendo desenvolvido.) No entanto, não recomendo desativá-la.