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

Question

Eu tenho algumas placas incorporadas executando o BIOS da Megatrends americana com o Linux incorporado como sistema operacional. O problema que tenho é que o ide flash industrial será corrompido na perda de energia. Eu tenho eles formatados como ext4. Sempre que isso acontece, geralmente consigo consertar o flash com o fsck, mas isso não será possível em nossas implantações. Ouvi dizer que a desativação do cache de gravação deve ajudar, mas não consigo descobrir como fazê-lo. Além disso, há mais alguma coisa que eu deveria fazer?

Mais informações

O drive é um módulo flash de 4gb ide. Eu tenho uma partição que é ext4. O.S. está instalado nessa partição e o grub é o meu bootloader.

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

Depois de uma perda de energia, normalmente não consigo fazê-lo totalmente através dos scripts init de inicialização.

Quando eu montei a unidade em outra P.C. Eu corro fsck / dev / sda1. Ele sempre mostra mensagens como

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

Eu os corrijo e inicializo bem até a próxima perda de potência.

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

Isso é tudo o que sei sobre como o sistema funciona. Eu não sou um cara de sistemas, eu sou um engenheiro de software que tem o hábito de entrar em situações difíceis que estão fora da descrição do seu trabalho. Eu sei como formatar drives, instalar um bootloader, escrever software e hackear um sistema operacional.

Aqui está a saída de 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

    

Answer 1

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

A configuração é persistente, portanto, se você não tiver o hdparm para brincar em seus sistemas de produção, deverá ser capaz de desativar o cache de gravação de disco em um sistema diferente e reconfigurar o disco.

BTW: Eu apoiaria a ideia de um sistema de arquivos raíz não gravável (assim seu sistema poderia inicializar em uma espécie de "modo de recuperação" e permitir acesso remoto mesmo se o sistema de arquivos gravável não fosse montável por algum motivo). E se você puder alterar o design do hardware, considere o uso de dispositivos mtd em vez de discos IDE / SATA com um sistema de arquivos com reconhecimento de flash, como jffs2 . Temos usado essa combinação com vários dispositivos incorporados (principalmente soluções de roteadores VPN no campo) por 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_journal está faltando na lista Filesystem features . Basta desligar todos os serviços, verificar se algo ainda tem arquivos abertos usando lsof +f -- / , remontar sua partição raiz somente leitura com mount -o remount,ro / , ativar o diário com tune2fs -O has_journal /dev/sda1 e configurar o modo de diário "ordenado" como a montagem padrão opção usando tune2fs -o journal_data_ordered /dev/sda1 - você terá que re-executar fsck (de preferência de um sistema de recuperação) e remontar root / reboot após esta operação.

Com essas configurações, os metadados têm a garantia de serem recuperados do diário, mesmo no caso de uma falha de energia repentina. Os dados reais também são consistentemente gravados no disco, embora você possa ver dados de vários segundos antes da perda de energia durante a inicialização. Se isso não for aceitável, você pode considerar o uso da opção tune2fs -o journal_data /dev/sda1 mount com seu sistema de arquivos - isso incluiria todos os dados gravados no disco no diário - isso obviamente lhe proporcionaria melhor consistência de dados, mas ao custo de uma penalidade de desempenho e maior nível de desgaste em seu SSD.

    

Answer 2

A sugestão do cache de gravação é um bom começo, mas isso parece uma falha no design arquitetônico. Em um sistema embarcado, o flash interno provavelmente não deve ser montado em R / W, exceto em raras circunstâncias. Você deve estar realmente fazendo a maior parte do trabalho em um sistema de arquivos de memória e sincronizando as alterações de volta ao flash RW com algum comando do usuário ou intervalo regular. É realmente incomum que um sistema embarcado 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 a possibilidade de ter sua partição de sistema diferente e projetá-la de modo 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 verificaria como as pessoas configuram os sistemas Linux sem disco:

link

e comece a partir daí. A idéia geral é que os binários e dados do sistema podem ser montados somente para leitura, para que seu sistema de arquivos não seja corrompido. No entanto, você precisa ser capaz de escrever para certas áreas, então você precisa de algo para memória, geralmente, o sistema de arquivos / tmp, / var / tmp. Mesmo que certas coisas precisem ser graváveis, basta criar um script para montar a partição como r + w e, em seguida, confirmar as alterações e, em seguida, voltar para somente leitura.

Um ótimo exemplo disso é o hardware da Cyclades, seu Linux embutido e sempre que você fizer alterações de configuração, você terá que executar um script de salvamento que realmente reconfigura as configurações e as grava no flash.