Devo fsck ext3 em sistemas embarcados?

Question

Temos um número de sistemas embarcados exigindo R / W o acesso ao sistema de ficheiros que reside no armazenamento flash com emulação de dispositivo de bloco. Nossas mais antigas corridas de plataforma no compact flash e estes sistemas têm sido utilizados por mais de 3 anos sem um único fsck sendo executados durante a inicialização e até agora temos nenhuma falha atribuída ao sistema de arquivos ou CF.

Na nossa mais nova plataforma que usamos USB-flash para a produção inicial e agora estão migrando para o Disk-on-Module para r / w de armazenamento. Um tempo atrás nós tivemos alguns problemas com o sistema de arquivos em muitos dos dispositivos que funcionam em USB de armazenamento de modo que eu habilitado e2fsck, a fim de ver se isso iria ajudar. Como se verificou que havia recebido um carregamento de memórias flash ruins assim uma vez que aqueles foram substituídos o problema foi embora. Eu tenho desde desativado e2fsck desde que nós tivemos nenhuma indicação de que ele fez o sistema mais confiável e historicamente temos sido muito bem sem ele.

Agora que já começou a colocar em unidades Disk-on-Module que eu comecei a ver erros do sistema de arquivos novamente. De repente, o sistema é incapaz de ler / escrever determinados arquivos e se eu tentar acessar o arquivo a partir do console de emergência eu fico " Erro de entrada / saída ". I habilitado e2fsck novamente e todos os arquivos foram corrigidos.

"Sistemas Linux Construção incorporados " O'Reilly recomenda executar e2fsck em sistemas de arquivos ext2 mas não menciona-lo em relação ao ext3 por isso estou um pouco confuso para saber se eu deveria habilitá-lo ou não.

Quais são seus assume correndo fsck em um sistema embarcado? Estamos pensando em colocar os binários no ar / o partição e apenas os ficheiros que tem de ser modificado em ar / w partição no mesmo dispositivo flash, assim fsck pode nunca excluir acidentalmente binários de sistema importantes, alguém tem alguma experiência com esse tipo de configuração (bom / mau)?

Answer 1

Eu acho que a resposta à sua pergunta mais se relaciona com o que tipos de requisitos de coerência sua aplicação tem em relação aos seus dados. Ou seja, o que tem de ser garantida se a energia é perdida sem um encerramento formal do sistema? Em geral, nenhum dos sistemas de arquivos do desktop operacional tipo de sistema lidar com isso tão bem sem fechar aplicação específica / sincronização de arquivos e rubor dos caches de disco, etc. em pontos de transação-chave na aplicação para garantir o que você precisa para manter está em fato comprometidos com os meios de comunicação.

executando correções fsck o sistema de arquivos, mas sem os cuidados acima, não há nenhuma garantia sobre o que alterações feitas vão realmente ser mantido. isto é: Não é exatamente determinística o que você vai perder, como resultado da falha de energia

.

Eu concordo que colocar seus binários ou outros dados importantes somente leitura em uma partição só de leitura separada faz ajudar a garantir que eles não podem erroneamente se jogou devido a uma correção fsck às estruturas do sistema de arquivos. No mínimo, colocando-os em um subdiretório diferente fora da raiz de onde os dados R / W é realizada vai ajudar. Mas em ambos os casos, se você oferecer suporte a atualizações de software, você ainda precisa ter plano para lidar com a escrever os "read-only" áreas de qualquer maneira.

Em nossa aplicação, nós realmente manter um par de diretórios para coisas como binários e o sistema está configurado para arrancar a partir de uma das duas áreas. Durante atualizações de software, nós atualizamos o primeiro diretório, tudo sync para a mídia e verificar os checksums MD5 no disco antes de passar para a atualização da segunda cópia. Durante a inicialização, eles são usados ??somente se a soma de verificação MD5 é bom. Isso garante que você está inicializando uma imagem coerente sempre.

Answer 2

Dave,

Eu sempre recomendo a execução do fsck após um número de reinicializações, mas não o tempo todo.

A razão é que, o ext3 é revista-ed. Então, se você habilitar o write-back (jornal-less), então a maior parte do tempo, sua tabela de metadados /-sistema de arquivos devem estar em sintonia com os seus dados (arquivos).

Mas, como Jeff mencionado, ele não garante a camada acima do sistema de arquivos. Isso significa, você ainda receber arquivos "corrompidos", porque alguns dos registros provavelmente não são escritos para o sistema de arquivos.

Eu não estou seguro de qual dispositivo embutido que está sendo executado, mas quantas vezes é que se reiniciado? Se ele é controlado reinicialização, você sempre pode fazer "sync; sync; sync". Antes de reiniciar

Estou usando o CF-me durante anos, e ocasião muito rara eu tenho erros do sistema de arquivos. fsck não ajuda nesse caso.

E sobre a separação sua partição, eu duvido que a vantagem disso. Para cada dados / arquivos no sistema de arquivos, há uma metadados associados a ele. Na maioria das vezes, se você não alterar os arquivos, por exemplo. arquivos binários / sistema, então este metadados não deve mudar. A menos que você tem um hardware defeituoso, como cross-falando de gravação e leitura, esses arquivos somente leitura deve ser seguro.

A maioria dos problemas surge quando você tem algo gravável, e independentemente onde você coloca isso, ele pode causar problemas se o aplicativo não lidar bem com isso.

Espero que ajude.