Sistema de arquivos do cartão SD à prova de corrupção para Linux embarcado?

Question

Recentemente, tivemos uma situação desagradável com nosso cliente - o quiosque "Raspberry Pi" usado para exibir dados de sensoriamento remoto (nada mais sofisticado do que um navegador em modo quiosque exibindo uma página da Web de atualização automática do servidor de coleta de dados) inicialização devido a corrupção do sistema de arquivos. Ext4, Manual fsck necessário, o sistema fará parte da importante apresentação de amanhã, serviço requerido imediatamente. É claro que não podemos exigir que o cliente desligue bem o sistema ao desligá-lo durante a noite; o sistema deve simplesmente suportar tais maus-tratos.

Gostaria de evitar tais situações no futuro e gostaria de mover o sistema operacional para um sistema de arquivos que impediria isso. Há um monte de sistemas de arquivos destinados a dispositivos MTD, onde fazer com que eles sejam executados no cartão SD (um dispositivo de bloco padrão) requer alguns saltos de arcos sérios. Existem também outros sistemas de arquivos (journalling etc) que possuem boa resistência contra a corrupção. Eu ainda preciso ver alguma comparação razoável de seus prós e contras.

Qual sistema de arquivos disponível no Linux forneceria a melhor resistência contra a corrupção em falhas de energia inesperadas e não exigiria saltos impossíveis como yaffs2 para instalar em SD.

O balanceamento de desgaste é uma vantagem, mas não uma exigência - os cartões SD geralmente têm seus próprios mecanismos, embora sejam menos que perfeitos, embora o sistema deva ser "suave para flash" (sistemas como NTFS podem matar um cartão SD dentro de um mês ).

    

Answer 1

A melhor resistência contra a corrupção em um único cartão SD seria oferecida pelo modo BTRFS em RAID1 com execução automática em cada período predefinido de tempo.

Os benefícios:

1. capacidade de retenção para o RW para o sistema de arquivos
2. sistema de arquivos moderno e com todos os recursos, com opções muito úteis para um RPi, como compactação transparente e instantâneos
3. projetado com memória flash em mente (entre outras coisas)

Veja como fazer isso:

Eu corro meu RaspberryPi no ArchARM linux e meu cartão está no leitor SD, então modifique essas instruções de acordo com outras distribuições e interfaces / dev.

Aqui está um exemplo de layout de partição:

/dev/mmcblk0p1: fat32 boot partition
/dev/mmcblk0p2: to be used as btrfs partition
/dev/mmcblk0p3: to be used as btrfs partition (mirrored with the above)
/dev/mmcblk0p4 (optional): swap

Para obter o btrfs no RAID1, você cria o sistema de arquivos da seguinte forma:

mkfs.btrfs -m raid1 -d raid1 /dev/mmcblk0p2 /dev/mmcblk0p3

Em seguida, você rsync -aAXv é o sistema que você salvou anteriormente.

Para conseguir inicializar a partir do BTRFS no raid1, você precisa modificar o initramfs . Portanto, você precisa fazer o seguinte enquanto ainda tem seu sistema em execução no seu antigo sistema de arquivos.

O Raspberry normalmente não usa o mkinitcpio, portanto você deve instalá-lo. Então, você precisa adicionar “btrfs” ao array MODULES no mkinitcpio.conf e recriar o initramfs com

mkinitcpio -g /boot/initrd -k YOUR_KERNEL_VERSION

Para saber o que digitar em vez de YOUR_KERNEL_VERSION, execute

ls /lib/modules

Se você atualizar o kernel, você DEVE recriar o initramfs ANTES de reinicializar.

Depois, você precisa modificar os arquivos de inicialização do RPi.

No cmdline.txt, você precisa ter

root=/dev/mmcblk0p2 initrd=0x01f00000 rootfstype=btrfs

e no config.txt, você precisa adicionar

initramfs initrd 0x01f00000

Uma vez que você tenha feito tudo isso e inicializado com sucesso no seu sistema RAID1 btrfs, a única coisa que resta é configurar a limpeza periódica (a cada 3-7 dias) com timer systemd (preferido) ou cron (dcron) como então:

btrfs scrub start /

Ele será executado em seu sistema de arquivos comparando as somas de verificação de todos os arquivos e corrigindo-os (substituindo-os pela cópia correta) se encontrar algum dano.

A combinação de BTRFS RAID1, single medium e Raspberry Pi faz essa coisa bem misteriosa. Demorou algum tempo e trabalho para juntar todas as peças, mas aqui está.

    

Answer 2

Eu iria de outra maneira e usaria apenas um sistema de arquivos somente leitura. Eu nunca fiquei estável o meu pi framboesa quando usando um sistema de arquivos raiz de leitura-escrita o sdcard. Você pode apenas inicializar sua raiz via kernel cmdline (ro) ou usar um initramfs com piggyback incluindo seu sistema completo.

Ambos são possíveis de criar com o meu sistema de compilação caseiro OpenADK. ( link )

    

Answer 3

O armazenamento em flash bem é mais desejável do que o armazenamento magnético, por várias razões, mas para esta aplicação eu vou dizer principalmente porque não há partes móveis. Dito isso, eu não acho que exista um sistema de arquivos 'à prova de corrupção', mas existem alguns sistemas de arquivos robustos (ext4 sendo um) lá fora, assim como algumas táticas para ajudar a mitigar a corrupção.

Disco RAM

Se a imagem do RPi não tiver para mudar, e parece que não, se nada vai tentar (ou deveria estar tentando) gravar no disco, tente usar um sistema de arquivos raiz criado para ser descompactado na RAM . A idéia aqui é que você tem um sistema de arquivos raiz comprimido na inicialização que é descompactado na RAM. Todas as alterações ocorrem no disco RAM, portanto, é efetivamente zero gravar no cartão SD, apenas lendo na inicialização. isso deve reduzir as leituras / gravações em seu disco, preservando a vida útil dele. Isso é semelhante ao que é feito quando você inicializa o linux de um CD e é uma das primeiras coisas que acontece quando o linux inicializa .

    

Answer 4

Bem, o problema que você está tendo aqui é que usar um sistema de arquivos "moderno", como o ext *, provavelmente usará o seu cartão SD; da minha experiência que acontece dentro de um ano, ou no próximo ano, se você tomar o maior fim.

O problema é que sistemas de arquivos modernos estão sempre movendo blocos para evitar a fragmentação de dados. O que é uma coisa boa em discos giratórios, onde você quer ter todos os seus dados reunidos ao carregá-los no cache. A desvantagem é que ele está fazendo mais gravações que não podem ser armazenadas em cache, pois a limpeza está sendo feita quando não há muita E / S acontecendo.

Também está acontecendo quando você lida com muito logging, o que você pode querer fazer ao depurar seu dispositivo incorporado. As gravações em log são o pior tipo de escrita, porque há muitas gravações minúsculas acontecendo regularmente, o que gera muita fragmentação.

Como você diz que seu sistema também está lidando com os dados do sensor, é muito provável que você os armazene no flash quando eles vierem. E eles são tão ruins quanto os dados de log.

Eu entrei no mesmo problema que você está enfrentando, e aqui estão as minhas conclusões. Eu tentei procurar cartões SD que seriam vendidos como "mais robustos", ou seja, ser capaz de lidar com mais gravações do que os outros, mas não encontrei nenhum benchmark no mercado que se concentre nisso, ao contrário dos benchmarks no SSD. Como todos eles se concentram apenas na velocidade, é impossível saber o número de gravações por bloco de memória e a tecnologia usada no SDCard.

Embora, eu notei que os sandisks de grau "industrial" tinham um tempo de vida mais longo do que os sem nome. O que não é surpreendente, quando você paga mais, você ganha mais.

Mas, no final, com o registro intensivo ativado, não encontrei nenhum cartão SD com um tempo de vida maior do que dois anos, sendo que um ano é onde ocorre a maior parte da morte.

A solução que eu criei são as soluções @ BigHomie e @wbx ': use um sistema de arquivos Read Only extX (já que o jornalismo não é mais necessário, você pode até mesmo voltar ao bom e velho ext2). E se você quiser manter os logs dentro da sessão ou gravar arquivos temporários, você sempre pode usar um RAMDISK.

Existem apenas tutoriais e scripts que ajudam a preencher o disco virtual com dados de dentro das partes somente de leitura, para que você possa editá-los para a sessão.

N.B .: minha experiência tem usado o Angstrom Linux em um Beaglebone, entre um teste de 20 dispositivos sensores. O registro do sistema era muito detalhado, usando o sistema de diário do systemd.

    

Answer 5

O Linux oferece muitos sistemas de arquivos. ext4 é o que eu tenho mais confiança. Em caso de dúvida, ext4 deve ser usado para qualquer partição que será montada como leitura-escrita.

O sistema de arquivos ext2 é muito mais frágil. É um sistema de arquivos perfeitamente bom para sistemas que podem montá-lo somente para leitura ou desmontá-lo corretamente. Mas a corrupção é extremamente provável com uma falha de energia no ext2 .

A outra opção poderia estar considerando jfs mesmo que o sistema de arquivos jfs não seja confiável em algumas versões do Linux. Corrupção é menos provável com jfs do que com ext4 . O Jfs também possui um tempo de montagem rápido e tempo de verificação do sistema de arquivos.