Precisa trocar a camada debian FS readonly gravável de tmpfs para aufs para não perder arquivos após a inicialização

0

Estou tentando fazer isso em um sistema integrado baseado no Debian 9. O fs que vem para o root é montado como tal em / etc / fstab:

# /etc/fstab: static file system information.
#
/dev/mmcblk1p1  /  ext4  noatime,errors=remount-ro  0  1
debugfs  /sys/kernel/debug  debugfs  defaults  0  0

Meu sistema de arquivos atual é assim:

Filesystem      Size  Used Avail Use% Mounted on
udev            215M     0  215M   0% /dev
tmpfs            49M  6.0M   43M  13% /run
/dev/mmcblk1p1  3.5G  1.9G  1.4G  59% /
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           242M     0  242M   0% /sys/fs/cgroup
tmpfs            49M     0   49M   0% /run/user/1000

Agora, o que eu preciso fazer é usar o unionfs (ou aufs) + ext4 para criar um sistema de montagem mais resiliente porque o / ext4 pode falhar devido à queda de energia e pode ocorrer corrupção do arquivo. A idéia aqui é ter uma camada de arquivo readonly na parte inferior com um gravável na parte superior para / home / debian, assim como qualquer outro que possa requerer gravação do sistema para eles (como var / log dir). O que me foi dito é que o ext4 trabalhando com um sistema embarcado que pode perder energia inesperadamente regularmente, causaria problemas / corrupção no disco em série, especialmente porque vamos gravar em disco muito enquanto nosso aplicativo estiver rodando. (Link) . Isso é completamente verdade mesmo com a presença do Journaling no ext4?

Depois de horas e horas de pesquisa, descobri que é sugerido passar pelo / usr / share / initramfs-tools criando ganchos / scripts e outros. Depois de criar um novo script e inicializar meu sistema, consegui algo semelhante ao que eu queria:

Filesystem      Size  Used Avail Use% Mounted on
udev            215M     0  215M   0% /dev
tmpfs            49M  6.0M   43M  13% /run
/dev/mmcblk1p1  3.5G  1.9G  1.4G  59% /ro
root.rw         242M  8.5M  234M   4% /rw
root.union      242M  8.5M  234M   4% /
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           242M     0  242M   0% /sys/fs/cgroup
tmpfs            49M     0   49M   0% /run/user/1000

& & Usando o mount eu recebo os seguintes detalhes para os novos ro & & sistemas de arquivos rw:

/dev/mmcblk1p1  on  /ro                              type  ext4        (ro,relatime,data=ordered)
root.rw         on  /rw                              type  tmpfs       (rw,relatime)
root.union      on  /                                type  aufs        (rw,relatime,si=587d3414)

Agora, isso funcionou em termos de tornar meu sistema inicial / somente leitura que está em / ro dir & & Eu instalei no topo uma camada gravável em / rw. O problema aqui é que, se eu criar novos arquivos / dir, todos eles desaparecem após a inicialização do dispositivo. Olhando fundo nisso eu suspeito o fato de que eu estava usando tmpfs pode ter causado isso, uma vez que é usado normalmente para a RAM, mas tenho dificuldade em usar aufs no topo (root.union) resolveria este problema, mas não o fez.

Como posso resolver esse problema fazendo com que a camada / rw retenha novas informações / arquivos criados mesmo após a inicialização? Tenha em mente que o meu sistema é lido apenas agora, então toda vez que eu tento entrar no meu script e montar / rw como aufs, ele é revertido após a inicialização do dispositivo.

Nota: Minha configuração atual significa que os logs do meu aplicativo atual não estão conectados ao meu / var / log / ... e se perdem após o dispositivo de inicialização? alguns aplicativos geralmente logar para / var / log / syslog que está no diretório / rw, mas não consigo confirmar se eles estão mantendo novos logs após a inicialização ou apenas reverter para o que eles tinham no arranque neles?

    
por JJ Adams 02.10.2018 / 20:43

1 resposta

0

AFAIK, o diário do ext4 significa que a corrupção real é rara e pode ser corrigida com um fsck. Eu nunca encontrei uma corrupção ext4 em nada, mas um disco moribundo (literalmente se recusou a girar no dia seguinte).

O cache do Linux significa que a RAM atua como um tmpfs com um armazenamento de apoio. Se você achar isso muito lento (o que seria surpreendente, já que você está usando um disco flash), você pode aumentar o tempo gasto para liberar os dados adicionando commit=<time> ao seu fstab, que troca a perda de dados com velocidade. p>

Passar na tentativa de encontrar o que precisa ser escrito pelos programas é um problema não resolvido na ciência da computação, acima do problema da complexidade. Por que não apenas armazenar as coisas que você precisa para persistir em uma partição / disco separado, para que você possa migrar em caso de falha?

    
por 02.10.2018 / 21:28