Sistema de arquivos que nunca quebra (aceitável perda de dados)

Existem vários tópicos existentes em torno deste problema, mas o que eu procuro é um pouco diferente. Eu tenho um cartão SD em um Linux incorporado e ele sofre com perda de energia. Talvez eu possa modificar o hardware em algum momento, fechar corretamente etc. etc. Mas agora, gostaria de encontrar um sistema de arquivos que sobreviva à perda de energia sem problemas. A perda de dados é aceitável. Prefiro não perder mais do que o arquivo que estou escrevendo atualmente, mas prefiro perder tudo do que enfrentar um 'incapaz de montar', 'esperar por 10 minutos fsck' ou 'incapaz de criar novos arquivo devido a este inode algo algo erro '. O programa DEVE continuar!

Estou fazendo um grande esforço para garantir isso. Estou usando componentes de nível industrial, tenho watchdogs de hardware, watchdogs de software, interno, externo, init reiniciando os programas, daemons constantemente verificando memória, descritores de arquivos e outros enfeites, tenho watchdogs assistindo meus watchdogs, que por sua vez são assistidos por outros watchdogs ... Mas não consigo garantir que o cartão SD seja capaz de montar e funcionar?

Minha melhor aposta agora é usar o JFS no cartão SD, incluir fsck e fsck.jfs na minha instalação. (Adicionando 600kb + comendo meu ram e meu flash. O que é ruim.) E execute o fsck em todas as inicializações (talvez adicionando muito tempo de inicialização. O que é um pouco ruim.). Parece um pouco triste.

Alguém sabe de uma maneira melhor ou de um sistema de arquivos melhor?

ATUALIZAÇÃO: e2fsprogs-libs (dependência do jfsutils) parece ser terrivelmente difícil de compilar em minha distribuição. Analisarei o ZFS (embora não seja nativo da minha distribuição. E parece fazer muito do que não preciso).

UPDATE2: Mais algumas informações sobre o meu sistema e meus testes: O armazenamento do cartão SD é um armazenamento opcional secundário. Os cartões SD são microSD de classe industrial de 2Gb-8Gb. O cartão SD é montado através do meu rc com um comando mount -t. Opções "noatime", mas não "sync". Minha distribuição é um uClinux com sabor de dispositivo analógico personalizado, com um kernel 3.10 e uma busybox 1.21. Meu armazenamento primário é um spi flash com jffs2. Eu nunca tive problemas com isso. Eu nem sei se existe um fsck.jffs2 disponível. Nand flash, por outro lado ... mas isso é uma história diferente. O objetivo do cartão SD é armazenar dados de medição. O programa 'monitor' anexará os resultados a um arquivo e possui canais de sincronização estratégicos. Quando o arquivo estiver acima de um determinado tamanho, um novo será criado. Quando um determinado número de arquivos for atingido, o mais antigo será excluído. Se o arquivo de medição atual for perdido devido à perda de energia, não será um desastre. Os arquivos geralmente estão entre 50 e 100kb e 1 resultado é geralmente 1kb. Esta é apenas a fase inicial de desenvolvimento. Nada está consertado. Esta é a primeira vez que lido com sistemas de arquivos não flash em sistemas embarcados. (Eu tenho ext4 nos meus servidores x86.)

Comecei com vfat. O sistema de arquivos padrão. (Imaginei que as fábricas poderiam ter um motivo para escolhê-lo. E se as coisas funcionarem, eu realmente não me importo muito.) Nunca vi problemas de perda de energia em meus dispositivos vfat incorporados. Eu tive problemas com o FAT no WinCE. No entanto, quando meu programa 'monitor' atingiu 100-200 arquivos, ele se recusou a criar mais. Parece que o FAT tem um problema especial de limite de arquivos na raiz e um problema ligeiramente maior nos subdiretórios. Eu preciso ser capaz de criar 500-1000 arquivos em 1 dir. Então vfat não serve.

Então eu mudei para ext2. Eu não inseri um fsck na inicialização. (Não sabia que precisava fazê-lo.) Em um dia, meu programa 'monitor' não conseguiu criar mais arquivos devido a um erro 'inode something something'. Desastre!

Minha solução atual é ext2 com um "e2fsck -y" na inicialização. Até agora, parece promissor. Mas o e2fsck e todo o conceito de 'fsck na inicialização' estão me incomodando. O e2fsck por si mesmo está gastando mais de 350kb do meu flash e ram principais. (Quando não está em execução.) O que significa que é o meu maior programa. É maior que o busybox. Está quase rivalizando com meu kernel.

Eu estive pensando em ext3. Ele registrou metadados, o que não faria mal. Estou em dúvida quanto ao quanto isso vai ajudar. Com meus arquivos pequenos e sincronizações controladas, eu deveria estar coberto, eu acho? Possui uma sequência de gravação ordenada. Significando que os dados também são um pouco diários. No entanto, isso pode levar a atrasos não determinísticos. O que é ruim na minha situação. (Provavelmente não é um problema.) Ele também possui um recurso de sincronização agendada. Por exemplo. comprometer a cada 5 s. O que está interferindo nas minhas próprias sincronizações, eu acho. Muitas gravações são ruins para cartões SD. Mesmo os industriais. Não consigo encontrar nenhuma documentação sobre como desativar isso. E o ext3 ainda exige que o fsck seja executado em toda inicialização! Mas o ext3 ainda é uma possibilidade.

Ext4. Corrigirá muitos problemas de desempenho do ext3. Eu realmente não preciso de performance. E minha distribuição não parece ter mkfs.ext4 e fsck.ext4 integrados. Talvez isso não seja um problema. Pode ser que sim. Por exemplo. o e2progs-libs (dependência do jfsutils) parece ter muitos problemas de compilação.

JFS, XFS, BRFSS. Tudo suportado pelo meu kernel. Atualmente não incluído na minha caixa de ferramentas de espaço do usuário. Tudo parece ser um sistema grande e complexo. E todos eles parecem exigir um equivalente 'fsck' na inicialização?

Também considerei lançar meu próprio sistema de arquivos: sempre escreva 2 cópias da tabela de arquivos. Ao percorrer, escolha aquele com o CRC correto e o número de sequência mais recente. Faça uma sequência de gravação em dois estágios. Aloque temporariamente, corrija na confirmação. Não é necessário fsck. Receio que possa ser um pouco ingênuo.

ATUALIZAÇÃO3: Aliás, a natureza dos sistemas embarcados (pelo menos este) é que eles são autônomos, autônomos, fora de alcance e precisam funcionar por anos. Programas como o fsck que podem exigir interação humana me assustam.

Há um pouco de inconsistência ou, pelo menos, ambiguidade, em sua história aqui:

Eu ainda prefiro perder tudo do que enfrentar um 'incapaz de montar', 'aguarde esse fsck de 10 minutos'

Implica - embora você realmente não o diga - que este é um problema que você está realmente enfrentando. Mas então:

O e2fsprogs-libs (dependência do jfsutils) parece ser terrivelmente difícil de compilar em minha distribuição.

Significando que você não tem nenhum fsck , pois e2fsprogs-libsé uma dependência e2fsprogsque fornece e2fsck. Então, talvez você ainda esteja em um estágio de planejamento aqui e nem sequer testou o sistema com, por exemplo ext4, mas chegou à conclusão de que deveria começar com o JFS? Existe alguma razão específica para isso?

Eu notei na troca raspberry pi (o armazenamento primário do pi também é um cartão SD) que um número significativo de usuários parece estar muito frustrado com problemas desse tipo, mesmo que a maioria (inclusive eu) nunca tenha experimentado isso. todos. No começo, presumi que eram pessoas ignorantes do fato de que o sistema deveria ser desligado de maneira limpa, mas esse não é um ponto difícil de entender quando explicado, e há pessoas que o denunciam, mesmo que o sistema tenha sido desligado corretamente .

Você já disse que precisa disso para poder tolerar cortes de energia (o que é justo), mas mencionei isso porque isso implica que há alguns pis, ou alguns cartões SD ou uma combinação de ambos que são propensos a corromper o sistema de arquivos devido a algum evento (surto?) que ocorre regularmente quando o plugue é puxado ou quando é recolocado. Eu também NÃO vi - e houve tempo de sobra para muita gente tentar - QUALQUER relato de alguém dizendo que mudou para btrfs ou jfs ou qualquer outra coisa e agora o problema está resolvido.

A outra coisa misteriosa sobre isso é que, mesmo que as pessoas estejam puxando o cabo, isso não deve resultar regularmente em um sistema de arquivos inutilizável. Certamente já fiz isso várias vezes com pi, e pontuações, se não centenas, com uma caixa linux comum (a energia foi cortada, o sistema ficou sem resposta, estou exausta e com raiva etc.) e apesar de ter visto uma pequena perda de dados, nunca vi um sistema de arquivos corrompido a ponto de ficar inutilizável após um fsck rápido.

Mais uma vez, presumindo que todos esses relatórios sejam verdadeiros (não vejo por que um número de pessoas mentiria sobre isso), há algo muito mais acontecendo do que simplesmente não desmontar corretamente, mas parece afetar apenas uma pequena porcentagem de usuários, implicando novamente algum tipo de defeito de hardware comum.

Na pi I escrever -ypara /forcefsckem um script de inicialização, para que na próxima inicialização é executado automaticamente e todos os problemas são fixos, independentemente de este parece ser necessária ou não. Em um núcleo único de 700 Mhz, são necessários ~ 10 segundos para um sistema de arquivos de 12 GB contendo ~ 4 GB de dados. Portanto, "10 minutos" parece incrivelmente longo, especialmente porque você já disse "Este é o pequeno sistema de arquivos para gravação!".

Você também pode considerar ligar syncem intervalos regulares.

Por fim, você deve atualizar a pergunta com detalhes mais factuais e específicos dos problemas que realmente encontrou e com menos hipérbole. Caso contrário, ele se parecerá muito com um problema prematuro do XY , que provavelmente será rapidamente ignorado por pessoas com muita experiência e conselhos em potencial para você.

O programa DEVE continuar!

Bem, este é um requisito comum e os sistemas Linux são a melhor escolha quando se trata de escolher um sistema estável.

Seus esforços também parecem não ir na direção certa. No entanto, o que você pode fazer para obter um sistema estável?

No primeiro nível, você pode melhorar seu sistema de arquivos:

• Use yournal_data_orderedem um ext3/ext4sistema de arquivos ao criar ou modificar com tune2fs.
• Com JFSuso --replay_journal_onlyao verificar.
• Ative o reparo automático, definindo FSCKFIX=yesnos initscripts.

Se isso não for suficiente, você pode inicializar o sistema sem montar o disco de buggy. Em vez disso, crie um novo ramdiskenquanto você verifica e repara manualmente o seu disco de buggy. Isso também pode ser automatizado por scripts.

No próximo nível, você precisará deixar seu sistema incorporado e ler alguns tópicos sobre Alta Disponibilidade