Escolha do sistema de arquivos para GNU / Linux em um cartão SD

Question

Eu tenho um sistema embarcado baseado em ARM em execução em um cartão SD. Atualmente é Debian GNU / Linux usando ext3 como sistema de arquivos. Quando estou prestes a reinstalar o sistema, comecei a pensar em mudar para um sistema de arquivos mais amigável ao flash. Eu ouvi sobre JFFS2, YAFFS2 e LogFS, e todos parecem adequados para o trabalho. Qual desses você recomendaria? Além disso, ouvi dizer que houve muitas melhorias no ext4 para melhor atender aos discos SSD; Eu sou para interpretar que, como rodar o ext4 deve estar bem? O que preciso pensar especialmente nesse caso?

Eu acho que o uso do sistema é importante. Mas, por uma questão de generalidade, imagine que ele vai fazer coisas de desktop padrão (mesmo que seja de fato um pequeno sistema baseado em ARM).

Obrigado por qualquer resposta.

Editar: Wikipedia me diz (em uma declaração "citação necessária") que < em> Placas de memória flash removíveis e unidades flash USB possuem controladores incorporados para executar o nivelamento de desgaste e a correção de erros, portanto, o uso de um sistema de arquivos flash específico não adiciona nenhum benefício . Assim, estou inclinado a ficar com um sistema de arquivos ext.

    

Answer 1

Excelente artigo sobre os sistemas de arquivos em flash .

Uma questão importante quando se fala em sistemas de arquivos flash é a seguinte: O que é o nivelamento de desgaste? Artigo da Wikipédia . Basicamente, em discos flash você pode escrever um número limitado de vezes até o bloco ficar ruim. Depois disso, o sistema de arquivos (se não houver gerenciamento de nivelamento de desgaste embutido no hardware, como no caso dos SSDs normalmente existem) deve marcar esse bloco como inválido e evitar usá-lo mais.

Sistemas de arquivos típicos (por exemplo, ReiserFS, NTFS, ext3 e assim por diante) são projetados para discos rígidos, que não possuem tais limitações.

JFFS2

Inclui compressão e proteção elegante de nivelamento de desgaste.

YAFFS2

• Única coisa que faz a diferença: tempos de montagem curtos, depois de umount bem-sucedido.
• Implementa a propriedade write once: quando os dados são gravados em um bloco, não é necessário reescrevê-los. Isso é importante, pois reduz o desgaste.

LogFS

• Não é muito maduro, mas já está incluído na árvore do kernel do Linux.
• Suporta sistemas de arquivos maiores que o JFFS2 / YAFFS2 sem problemas.

UBIFS

• Mais maduro que o LogFS
• Suporte ao cache de gravação
• Na escalabilidade: artigo . Em discos grandes, melhor desempenho do que com o JFFS2

ext4

Se nenhum driver ou placa (por exemplo, unidades SSD possuem nivelamento de desgaste interno, pelo menos normalmente) manipulam o nivelamento de desgaste, o ext4 não é a melhor idéia, pois não é destinado ao uso bruto do flash.

Qual é o melhor?

Claro, isso depende do uso e do suporte. Pelo que li na Internet, eu recomendaria o UBIFS. Bom suporte para grandes sistemas de arquivos, fase madura de desenvolvimento, desempenho adequado e sem grandes desvantagens.

    

Answer 2

Eu estava enfrentando o mesmo problema e fiz algumas pesquisas também. Eventualmente, decidi ir com o ext2.

Parece que alguns cartões SDHC implementam seu próprio nivelamento de desgaste na camada de hardware. Se você conseguir usar cartões SDHC que tenham o nível de ajuste de desgaste.

Sistemas de arquivos que fornecem nivelamento de uso podem interferir no nivelamento de desgaste no nível do Flash, então pode ser ruim para o flash usá-los (o artigo da IBM citado acima fala sobre como o JFFS faz isso, então está claro que não trabalhe com o nível de flash WL). Eu decidi que não precisava do diário do ext3, já que não estou armazenando dados críticos nele e geralmente faço backup regularmente (cron).

Eu também montei / tmp e / var como tmpfs para acelerar as coisas. Se você tem memória RAM suficiente, você deve fazer isso (mas certifique-se de rodar ou apagar seus logs regularmente)

DICA: Monte seus cartões SD com a opção "noatime"

    

Answer 3

A seleção (e o dimensionamento) do sistema de arquivos correto é mais importante do que qualquer outra coisa, não apenas para segurança, mas para muitas outras razões que as pessoas geralmente não reconhecem. Sem um sistema de arquivos, todo o processamento seria anulado.

resposta muito bem colocada por Olli, e o OP é muito antiquado, mas os sistemas de arquivos são o meu problema de estimação que eu não poderia ficar longe. superuser.com não é algo que eu visitei antes, não sou administrador, mas me inscrevi e vou visitar mais.

As coisas mudaram muito desde 2011, mas mesmo naquela época eu formatava cartões USB FAT e usava drives USB para carregar arquivos de 4Gb +. A razão é claro que compatibilidade não é segurança (tanto para S em SD, mas eu uso senhas em meus 7z's), e eu nunca carreguei nada maior do que um CD ISO, eles eram principalmente para scripts SQL e diff horários de cada hora instantâneos de banco de dados criptografados espremidos até a morte por 7-Zip.

Hoje em dia eu uso qualquer SD mais rápido do que qualquer um que conheço. Eu tenho um stick USB em algumas máquinas de produção no meu empregador para backup automatizado por hora, formatado FAT. Eu fico de olho neles todos os dias embora e - você adivinhou - os apoie religiosamente à mão (eles estão protegidos off-line construindo coisas ITAR). O SSD nivelou parte do campo de jogo, mas eu ainda não confio neles tanto quanto o HD normal, e o SD é pior que o óptico. Eles vão mal em um instante e a perda é total.

Qualquer sistema de arquivos que convide o sistema operacional host a escrever aleatoriamente para ele (NTFS, Lixeira) é uma má notícia para um SD. Além disso, desmontá-lo ajuda muito, nenhum sistema operacional vai tentar acessar o armazenamento desmontado, portanto, qualquer sistema de arquivos fará o tempo que o SD incluir um script para se desmembrar (um dos arquivos padrão em cada SD).

Ler um SD ainda é lento hoje, então eu recomendaria algo como despejo de disco (dd) para pegar a imagem inteira ao espelhar em vez de arquivo por arquivo. O dd também permite que você saiba quando algo está errado, então o gerenciador de arquivos não vai funcionar.

É claro que, se o seu objetivo principal é estender a vida útil de alguns centavos, você está lidando com o seu negócio da maneira errada. Eu faço o que eu não faço para prolongar a vida de um SD, mas para evitar que ele fique ruim quando não estou assistindo, e há a diferença.

Eu evito o ext4 ou qualquer FS de journaling no SD porque eu não me importo quando eles escrevem mal para eles, mas com certeza dói quando um ou dois dias depois eu não consigo lê-los!

    

Answer 4

Eu não sei se isso se encaixa no perfil do seu sistema, mas que tal usar um sistema de arquivos readonly mais uma partição de leitura / gravação (ou um pendrive que pode ser substituído facilmente)? Dessa forma, você terá um disco rápido para o seu sistema operacional e poderá substituir seu armazenamento rw facilmente quando se desgastar.

E então há unionfs. Como eu entendi isso "empilha" diferentes sistemas de arquivos (ou seja, um ro fs no topo de um rw fs). Se houver um sindicato de acesso de leitura, ele procurará pela pilha até atingir o FS que contém o arquivo que procuramos. Ao escrever, o unionfs procura o primeiro FS gravável na pilha e o usa.

Também encontrei estes artigos que podem ser interessantes: link link

E dois artigos com dicas para usar SSDs: link link

    

Answer 5

Como resposta à recomendação de uso de gordura (32?): Fiz alguns testes de desempenho e descobri que o fat32 tem um tempo muito previsível para gravar um arquivo (2 GB precisam de duas vezes de 1 GB + deslocamento, 3 GB precisam de tempos de árvore de 1 GB + deslocamento). O desempenho do ext4 é ligeiramente melhor que o ext3. Tanto o ext3 quanto o ext4 são às vezes rápidos, mas às vezes precisam de algum tempo extra para gravar os arquivos de diário no disco (sem comportamento de tempo de gravação linear). Todos os testes foram feitos com fsync () para ter certeza de que o arquivo está realmente gravado no disco. Eu realizei alguns testes com sync (). Eles resultam em desempenho de gravação muito ruim. Então eu voltei para o fsync (). Eu fiz alguns verificar se fsync () é suficiente. Portanto, eu liguei o dispositivo sem o desligamento do sistema ou removi o cartão SD sem desmontar. Em nenhum caso, os arquivos escritos ou a estrutura do diretório foram danificados. Então decidimos usar ext4 e apenas fsync ().

Atenciosamente, Thomas

    

Answer 6

se você quiser cartão sd livre de perda, sugiro usar BTRFS porque:

BTRFS é um novo sistema de arquivos comparado ao EXT originalmente criado pela Oracle em 2007.

Ele traz novos recursos aos sistemas de arquivos tradicionais:

• Clonagem / instantâneos
• Diffs (enviar / receber)
• Quotat
• União
• Auto-cura (com períodos de confirmação padronizados para 30s)

para explicações e comparações adicionais, consulte este pdf

para novas comparações, consulte este site