Evitar a corrupção de dados na unidade ext4 / Linux com perda de energia

Eu tenho algumas placas incorporadas executando bios American Megatrends com linux incorporado como o sistema operacional. O problema que tenho é que os flash ide's industriais serão corrompidos com a perda de energia. Eu os tenho formatado como ext4. Sempre que isso acontece, geralmente posso corrigir o flash com o fsck, mas isso não será possível em nossas implantações. Ouvi dizer que desabilitar o cache de gravação deve ajudar, mas não consigo descobrir como fazê-lo. Além disso, há mais alguma coisa que devo fazer?

Mais informações

A unidade é um módulo flash ide de 4GB. Eu tenho uma partição que é ext4. O sistema operacional está instalado nessa partição e o grub é meu gerenciador de inicialização.

O fdisk -l mostra / dev / sda como meu módulo flash com / dev / sda1 como minha partição principal.

Após uma perda de energia, geralmente não consigo fazer isso completamente através dos scripts de inicialização.

Quando monto a unidade em outro PC, executo fsck / dev / sda1. Sempre mostra mensagens como

"zero datetime on node 1553 ... fix (y)?"

Eu os conserto e ele inicializa bem até a próxima perda de energia.

Quando chegar ao escritório amanhã, publicarei a saída real do fdisk -l

É tudo o que sei sobre como o sistema funciona. Eu não sou um cara de sistemas, sou um engenheiro de software que tem o hábito de entrar em situações que estão fora da descrição de seu cargo. Eu sei como formatar unidades, instalar um gerenciador de inicialização, escrever software e invadir um sistema operacional.

Aqui está a saída do dumpe2fs

#sudo dumpe2fs /dev/sda1
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name:   VideoServer
Last mounted on:          /
Filesystem UUID:          9cba62b0-8038-4913-be30-8eb211b23d78
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              245760
Block count:              977949
Reserved block count:     48896
Free blocks:              158584
Free inodes:              102920
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      239
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Feb  4 15:12:00 2011
Last mount time:          Sun Oct  2 23:48:37 2011
Last write time:          Mon Oct  3 16:34:01 2011
Mount count:              2
Maximum mount count:      26
Last checked:             Tue Oct  4 07:44:50 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Apr  1 07:44:50 2012
Lifetime writes:          21 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      249d2b79-1e20-49a3-b324-6cb631294a63
Journal backup:           inode blocks

O cache de gravação geralmente não tem nada a ver com o BIOS, principalmente não há opção para alternar as configurações de cache de disco. Com o linux, usar hdparm -W 0deve ajudar.

A configuração é persistente; portanto, se você não tiver o hdparm para brincar nos seus sistemas de produção, poderá desativar o cache de gravação de disco em um sistema diferente e reconectá-lo.

BTW: Gostaria de sugerir um sistema de arquivos raiz não gravável (para que seu sistema possa inicializar em um tipo de "modo de recuperação" e permitir acesso remoto, mesmo que o sistema de arquivos gravável não seja montável por algum motivo). E se você pode alterar o design do hardware, considere usar dispositivos mtd em vez de discos IDE / SATA com um sistema de arquivos compatível com flash, como o jffs2 . Usamos essa combinação com vários dispositivos incorporados (principalmente soluções de roteadores VPN em campo) há vários anos, com bons resultados.

Atualização: a raiz do seu problema parece ser que você está executando um sistema de arquivos ext4 com o diário desativado - has_journalestá ausente na Filesystem featureslista. Apenas encerre todos os serviços, verifique se alguma coisa ainda possui arquivos abertos usando lsof +f -- /, remonte sua partição raiz somente leitura mount -o remount,ro /, habilite o diário tune2fs -O has_journal /dev/sda1e configure o modo de diário "ordenado" como a opção de montagem padrão usando tune2fs -o journal_data_ordered /dev/sda1- você precisará execute fsck (de preferência a partir de um sistema de recuperação) e remonte a raiz / reinicialize após esta operação.

Com essas configurações, os metadados são garantidos para serem recuperados do diário, mesmo no caso de uma repentina falta de energia. Os dados reais também são consistentemente gravados no disco, embora você possa ver dados de vários segundos antes da falta de energia perdida na inicialização. Se isso não for aceitável, você pode considerar usar a tune2fs -o journal_data /dev/sda1opção de montagem com seu sistema de arquivos - isso incluiria todos os dados gravados em disco no diário - isso obviamente forneceria melhor consistência dos dados, mas ao custo de uma penalidade de desempenho e um nível de desgaste mais alto no seu SSD.

A sugestão do cache de gravação é um bom começo, mas isso soa como uma falha no projeto de arquitetura. Em um sistema embutido, o flash interno provavelmente NÃO deve ser montado em R / W, exceto em raras circunstâncias. Você realmente deveria estar realizando a maior parte do trabalho em um sistema de arquivos de memória e sincronizando as alterações de volta para o flash RW mediante algum comando do usuário ou intervalo regular. É realmente incomum que um sistema incorporado use um sistema de arquivos regular (como ext4) no modo rw durante a operação normal. Se houver algum requisito de aplicativo em que você precise de muito espaço de armazenamento, considere que a partição do sistema seja diferente e projete-a para que a partição de dados possa ser fsck-y'ed como parte da inicialização.

Se você precisar de alguns pontos de partida, eu veria como as pessoas configuram os sistemas Linux sem disco:

http://frank.harvard.edu/~coldwell/diskless/

e começar a partir daí. A idéia geral é que os binários e dados do sistema possam ser montados somente leitura, para que o sistema de arquivos não seja corrompido. No entanto, você precisa ser capaz de gravar em determinadas áreas, portanto, é necessário algo para armazenar na memória o sistema de arquivos / tmp, / var / tmp. Mesmo que certas coisas precisem ser graváveis, você apenas cria um script para montar a partição como r + w e, em seguida, confirma as alterações, depois volta para somente leitura.

Um exemplo realmente ótimo disso é o hardware Cyclades, seu linux incorporado e sempre que você faz alterações na configuração, é necessário executar um script de salvamento que realmente reorganiza as configurações e as grava no flash.