O que o reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_POWER_OFF, NULL)
syscall faz com os sistemas de arquivos exatamente?
Eu sei que alguns dados de cache na memória ainda serão perdidos, mas se eu nunca chamar umount()
(ou umount failed) antes reboot()
, é possível que eu acabe com um sistema de arquivos quebrado que não pode ser mount()
tão rw novamente diretamente?
Eu sei que isso depende do tipo de sistema de arquivos, então gostaria de saber mais detalhes sobre sistemas de arquivos de diário e sistemas de arquivos mais simples como ext2.
A desmontagem de um sistema de arquivos sincronizará todos os dados de cache na memória associados. A chamada reboot() pode perder dados, exatamente porque não desmonta os sistemas de arquivos de forma limpa. (lennart é salgado sobre isso :-).
No entanto, eu só chamaria o sistema de arquivos de "quebrado" se não estivesse usando journalling (ou equivalente). Além desse caso, por exemplo, ext4/xfs/btrfs deve ser reparado de forma 100% confiável usando o journal. Isso pode ser (e é) realizado automaticamente. Ao contrário de uma verificação/reparo completo, não envolve a varredura de todo o sistema de arquivos, por isso é bastante rápido. A menos que você tenha muitas alterações de metadados não sincronizadas que precisam ser resolvidas.
Você pode ver algumas mensagens de exemplo do ext4 aqui: O "recovering journal" prova um desligamento/desmontagem sujo?
No exemplo vinculado, parece que
fsck.ext4
recupera o diário. No entanto, acho que o kernel também pode recuperar o diário ext4 automaticamente quando o sistema de arquivos é montado. Para xfs/btrfs,fsck
nunca faz nada (veja asman
páginas relevantes), então sempre é tratado pelo kernel.Em contrapartida,
ext2
não tinha um diário.fsck.ext2
tem uma boa reputação, mas pelo que entendi, não cobre todos os casos possíveis que o journaling pode. Pode acabar perdendo nomes de arquivos e soltando seu conteúdo nolost+found
diretório. Ou a correção correta pode não ser 100% inequívoca, portanto, seria necessário pedir permissão ao usuário antes de aplicar seu melhor palpite.O acima pressupõe que seu dispositivo de armazenamento atende às expectativas do sistema de arquivos. Por exemplo, há um caso conhecido sobre falhas de energia que interrompem as operações de gravação: alguns armazenamentos estilo cartão SD podem perder todo o bloco de apagamento flash de 128 KB, que continha o bloco de disco (por exemplo, 4 KB) no qual você estava gravando. Os sistemas de arquivos acima não são projetados para sobreviver a tal perda de dados :-).
Pedantemente, não. Eventos de reinicialização e desligamento são conceitos de espaço do usuário, não conceitos de kernel. O desligamento ou reinicialização gracioso é tratado pelo systemd na maioria das distribuições Linux modernas. É também a ferramenta userpace que verifica os sistemas de arquivos na inicialização e os monta se estiverem em um estado utilizável.
Sim, na medida em que os drivers do sistema de arquivos implementam journalling para manter os sistemas de arquivos consistentes, mesmo no caso de um desligamento ou reinicialização desagradáveis.
Sim, na medida em que o kernel fornece a API pela qual as ferramentas do espaço do usuário podem verificar e gerenciar os sistemas de arquivos.