1 Disco rígido hospedando 4 sistemas de arquivos EXT4, vamos chamá-los de A (1,2,3,4), cada um deles recebendo uma entrada em meu fstab, mas muito raramente montado, mesmo sendo desligado via udiskctl no momento da inicialização.
1 Disco rígido hospedando 8 sistemas de arquivos EXT4, cada um deles recebendo uma entrada no meu fstab, 4 deles, digamos B(1,2,3,4) sendo montados automaticamente no momento da inicialização, os outros quatro, digamos C( 1,2,3,4) sendo ocasionalmente montado sob demanda.
Nestas condições (A(1,2,3,4) não montado e unidade associada desligada; nenhum sistema de arquivos C(1,2,3,4) montado) e por qualquer motivo (falta de energia, kernel panic, hard reset…) o sistema não é desligado normalmente.
Na próxima reinicialização, cada um desses sistemas de arquivos será verificado.
Todos os sistemas de arquivos que não foram montados em um momento de desligamento anormal são rapidamente considerados limpos:
P1:Esta conclusão é motivada apenas pela leitura do texto do superbloco?estado_scampo ou há outras verificações feitas?
Q2:Depende dos motivos que desencadearam o desligamento anormal, do fato de a unidade subjacente estar ligada ou não?
Q3:Essas verificações comandarão o fsck para montar o sistema de arquivos?
Q4:Embora esses status de limpeza sejam relatados no console, por que não consigo encontrar esses relatórios ecoados nos logs do meu kernel (ou qualquer outro), enquanto os rastreamentos dos sistemas de arquivos que realmente precisavam de reparo e, eventualmente, de recuperação do diário são?
No Linux-5.4/e2fsck 1.46.5/openrccomo sistema init emetalogramaagindo como daemon syslog, se isso for importante.
As regras mais relevantes do metalog:
Kernel messages :
facility = "kern"
logdir = "/var/log/kernel"
break=1
Fallback:
facility = "*"
minimum = 6
logdir = "/var/log/fallback"
Responder1
Por favor, não faça várias perguntas.
Quando uma partição é mounteditada, o código do sistema de arquivos copia as tabelas de alocação de blocos da partição na memória e marca as tabelas do disco como "precisam de recuperação".
O código do sistema de arquivos gerencia a alocação de blocos na velocidade da memória, que é MUITO mais rápida que a velocidade do disco.
Periodicamente, as tabelas na memória são gravadas de volta no disco, tanto para mantê-las relativamente atualizadas quanto para evitar a necessidade de mantê-las todas na memória de uma só vez.
Quando a partição é umounteditada, as tabelas na memória são gravadas no disco (limpando o sinalizador "precisa de recuperação"). As tabelas na memória são descartadas.
Quando o sistema trava, as tabelas atualizadas na memória são perdidas e o sinalizador "precisa de recuperação" ainda está definido no disco.
Se o sistema de arquivos for necessário para inicialização ( /etc/fstabentrada has auto), e o sinalizador "precisa de recuperação" estiver definido no disco, um sistema de arquivos específico fsckserá executado (por exemplo, fsck.ext4para ext4sistemas de arquivos) para "recuperar" o sistema de arquivos - torne as tabelas de alocação de blocos "corretas " (minimizar a perda de dados, garantir que nenhum bloco esteja livre ou usado, ...), preserve os blocos que foram gravados enquanto "precisa de recuperação", etc. Como o fsckestá construindo suas próprias tabelas, o disco não pode ser mounteditado, e , além disso, o disco tem o sinalizador "precisa de recuperação" definido até fsckser bem-sucedido.
Essa fsckatividade de pré-montagem causada pelo sistema ocorre antes que o processo de inicialização esteja "ativo" o suficiente para realmente registrar as mensagens, mas tente dmesg.
Obrigado LustreOne,
No momento da montagem, o e2fsck verificará o sinalizador "precisa de recuperação" do diário, bem como fará uma verificação básica do superbloco e dos blocos descritores de grupo necessários para montar o sistema de arquivos. Se "precisa de recuperação" estiver definido, o diário será reproduzido novamente. Se outros erros forem encontrados, ele executará um e2fsck completo do sistema de arquivos. – LustreOne