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

Recentemente, tivemos uma situação bastante desagradável com nosso cliente - o "quiosque" baseado em Raspberry Pi usado para exibir dados de sensoriamento remoto (nada mais sofisticado do que um navegador em modo de quiosque que exibe uma página de atualização automática do servidor de coleta de dados) falhou ao inicializar devido a corrupção do sistema de arquivos. Ext4, fsck manual necessário, o sistema fará parte da apresentação importante de amanhã, serviço necessário 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 essas situações no futuro e gostaria de mudar o sistema operacional para um sistema de arquivos que evitasse isso. Existem vários sistemas de arquivos destinados a dispositivos MTD, em que fazê-los rodar em cartão SD (um dispositivo de bloco padrão) exige alguns saltos sérios. Existem também alguns outros sistemas de arquivos (diários etc) que possuem boa resistência contra a corrupção. Eu ainda preciso ver uma 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 inesperadas de energia e não exigiria saltar por obstáculos impossíveis como o yaffs2 para instalar no SD.

O balanceamento de desgaste é uma vantagem, mas não um requisito - os cartões SD geralmente têm seus próprios mecanismos, se não forem perfeitos, embora o sistema deva ser "gentil com o flash" (sistemas como o NTFS podem matar um cartão SD dentro de um mês).

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

Os benefícios:

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

Aqui está como fazê-lo:

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

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 inserir o btrfs no RAID1, crie o sistema de arquivos da seguinte maneira:

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

Então você rsync -aAXvfaz o seu sistema com backup anterior.

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

O Raspberry normalmente não usa o mkinitcpio, portanto você deve instalá-lo. Então, você precisa adicionar “btrfs” à matriz 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, DEVE recriar o initramfs ANTES de reiniciar.

Em seguida, 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

Depois de fazer tudo isso e inicializar com sucesso no sistema RAID1 do btrfs, a única coisa que resta é configurar a limpeza periódica (a cada 3-7 dias) com o timer do systemd (preferencial) ou o cron (dcron) da seguinte forma:

btrfs scrub start /

Ele será executado no seu sistema de arquivos comparando somas de verificação de todos os arquivos e corrigindo-os (substituindo pela cópia correta), se encontrar alguma corrupção.

A combinação de BTRFS RAID1, meio único e Raspberry Pi torna essas coisas bastante misteriosas. Demorou algum tempo e trabalho para juntar todas as peças, mas aqui está.

Bem, o armazenamento flash é mais desejável do que o armazenamento magnético, por várias razões, mas para esse aplicativo direi principalmente porque não há partes móveis. Dito isto, não acho que exista um sistema de arquivos "à prova de corrupção", mas existem alguns sistemas de arquivos robustos (ext4 sendo um) por aí, além de algumas táticas para ajudar a mitigar a corrupção.

Disco RAM

Se a imagem do RPi não precisar mudar e parecer que não, se nada tentar gravar (ou tentar) gravar no disco, tente usar um sistema de arquivos raiz criado para ser descompactado na RAM . A idéia aqui é que você tenha um sistema de arquivos raiz compactado na inicialização que é descompactado na RAM. Todas as alterações ocorrem no disco RAM, portanto, não há efetivamente zero gravação no cartão SD, apenas leitura na inicialização. isso deve reduzir as leituras / gravações em sua unidade, preservando a vida útil dela. Isso é semelhante ao que é feito quando você inicializa o linux a partir de um CD e é uma das primeiras coisas que acontecem quando o linux é inicializado .

Eu seguiria outro caminho e usaria apenas um sistema de arquivos somente leitura. Nunca obtenho meu raspberry pi estável o suficiente ao usar um sistema de arquivos raiz de leitura e gravação no cartão sd. Você pode simplesmente inicializar sua raiz através do kernel cmdline (ro) ou usar um initramfs com piggyback, incluindo seu sistema completo.

É possível criar ambos com o meu sistema de compilação caseiro OpenADK. ( http://www.openadk.org )

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

O problema é que os sistemas de arquivos modernos estão sempre movendo os blocos para evitar a fragmentação dos dados. O que é bom em discos giratórios, nos quais você deseja que todos os seus dados sejam agrupados ao carregá-los no cache. A desvantagem é que ele realiza mais gravações que não podem ser armazenadas em cache, pois a organização está sendo realizada quando não há muita E / S acontecendo.

Também está acontecendo quando você lida com muitos logs, o que você pode querer fazer ao depurar seu dispositivo incorporado. As gravações de log são o pior tipo de gravações, porque muitas gravações minúsculas ocorrem 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 à medida que eles chegam. E eles são tão ruins quanto os dados do log.

Eu entrei no mesmo problema que você está enfrentando, e aqui estão minhas conclusões. Tentei procurar por cartões SD que seriam vendidos como "mais robustos", ou seja, capazes de lidar com mais gravações do que os outros, mas não encontrei nenhuma referência no mercado que se concentre nisso, ao contrário das referências 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.

No entanto, notei que os sanduíches de classe "industrial" tinham uma vida útil mais longa que os nomes. O que não é surpreendente, quando você paga mais, recebe mais.

Mas, no final, com o registro intensivo ativado, não encontrei nenhum cartão SD com vida útil superior a dois anos, sendo um ano o local onde mais mortes ocorrem.

A solução que encontrei são as soluções @ BigHomie e @wbx ': use um sistema de arquivos extX somente leitura (como o diário não é mais necessário, você pode até recorrer ao bom e velho ext2). E se você deseja manter registros dentro da sessão ou gravar arquivos temporários, sempre pode usar um RAMDISK.

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

NB: minha experiência foi usar o Angstrom Linux em um Beaglebone, em uma experiência de 20 dispositivos sensores. O registro desse sistema era muito detalhado, usando o sistema de diário do systemd.

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

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

A outra opção pode estar considerando o jfs, mesmo que o sistema de arquivos jfs não seja confiável em algumas versões do Linux. A 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.