Cartão micro SD: O I/O é gerenciado?

Relacionado ao artigo anterior, uma questão foi levantada em um dos grupos que gerencio. A questão foi em relação ao gerenciamento de escrita no cartão micro SD, que, conforme as informações que temos, ele escreve dados de forma randômica para evitar muita escrita no mesmo ponto. Bem, isso é verdade, mas o que acontece quando se está modificando um arquivo constantemente? O que mais pode afetar a vida útil de um cartão de memória? Vamos por partes.

Conhecendo o micro SD

Primeiro, falemos da nomeclatura. "SD" é o acrônimo de "Secure Digital". O micro SD é a menor memória desse tipo que temos hoje, utilizada em muitos dispositivos como smartphones, câmeras e dispositivos embarcados; ora para armazenamento de sistema, ora para armazenamento de dados.

Esse tipo de memória pode (teoricamente) ser escrita milhares de vezes e trata-se de um dispositivo de armazenamento, portanto os dados tem persistência. Sua arquitetura é bastante diferente de um HD; aliás, não tem a menor relação, tratando-se de memória NAND.

Existe a possibilidade de bloqueio físico ou lógico contra escrita, mas nesse caso só é válido para proteção da mídia contra subescrição de dados.

Corrupção dos dados

Assim como na política, não nos agradamos com corrupção, mesmo sendo digital. E ocasionalmente isso ocorre em dispositivos de armazenamento do tipo NAND por diversas razões. A mais comum é por cache de dados. Isso normalmente ocorre quando, para otimização do sistema, uma área de memória RAM é utilizada para depositar os dados sendo modificados e, através de um pipe, esses dados são posteriormente despejados para a midia de armazenamento. O que pode fragilizar o cartão de memória nesse momento seria, por exemplo, uma mínima interrupção na alimentação; ou uma baixa repentina pelo gerenciamento de energia do sistema; ou devido à intensidade dos dados, um aquecimento maior da mídia. Mas esses não são os únicos problemas que podem corromper o sistema de arquivos ou gerar falha de segmentação em bibliotecas e outros binários do sistema. Se o cartão for removido antes dos despejos de dados, ou ocorrer um desligamento incorreto do sistema, as chances de não ser possível uma recuperação são grandes.

Considerando tudo o que foi citado anteriormente, podemos perceber que por mais otimizado que seja o cartão de memória em sí, ele é totalmente dependente do sistema operacional.

Características do SD

E apesar de serem todos os SDs uma memória NAND, eles podem diferir em diversas características.

Capacidade de armazenamento

Essa é a principal e a que todos dão atenção. A capacidade de armazenamento, que vem marcado sobre o cartão de memória. Somente cartões com até 32GB contam com o padrão SDHC (Secure Digital High Capacity).

Classe

A classe define a velocidade de I/O do cartão. Entre elas estão:

Classe 2 - velocidade mínima de 2MB/s Classe 4 - velocidade mínima de 4MB/s Classe 6 - velocidade mínima de 6MB/s Classe 10 - velocidade mínima de 10MB/s

Quando utilizamos para sistemas embarcados, não há dúvidas de que é fundamental escolher classe 10, uma vez que isso influenriará diretamente no desempenho do sistema.

UFS - o novo micro SD

Rumores dizem que a Samsung já tem o sucessor do micro SD, conhecido como Universal Flash Storage. Esse tipo de cartão de memória virá em32, 64, 128 e 256 GB de capacidade, com uma velocidade 5 vezes maior que o Micro SD. Com certeza isso fará muita diferença no desempenho de sistemas embarcados.

Existem benchmarks de cartões SD e os resultados diferem para leitura sequencial, escrita sequencial, leitura de blocos e escrita de blocos. Se você realmente quer ir a fundo antes de comprar seu micro SD, dê uma investigada. Adianto que, ao que tudo indica, o Samsung Evo é o campeão, utilizando o padrão SDXC.

O que causa I/O intenso?

Diversas coisas podem ser consideradas. Ler um arquivo muito grande (como um filme, por exemplo) não quer dizer que o esforço e desgaste do cartão é maior. Porém utilizar uma pequena área como swap, aí sim você poderá "esmirilhar" seu micro SD rapidamente. Apenas como exemplo, seria algo como:

sudo su
free -m
dd if=/dev/zero of=swapfile.swap count=1048576 bs=100
mkswap swapfile.swap
swapon swapfile.swap
free -m

Aqui você poderá checar sua memória RAM, posteriormente criando um arquivo de memória virtual, que fará I/O em disco. O momento em que a swap entrará em uso pode ser controlado via sysctl, e em alguns casos a swap pode ser fundamental, não se tratando exatamente de um vilão dos cartões SD. Por padrão, no Raspbian esse controle está ajustado para interagir a partir de 60% de utilização:

Como realmente não é bom fazer swap no cartão SD, pode ser ideal ajustar esse valor. Ajustando para 100, significa que indiferente da utilização de memória RAM, todo o conteúdo será paginado imediatamente na memória virtual. Definindo esse valor para 0, significa que somente no mais absoluto esgotamento da RAM a memória virtual será utilizada. Se você conhece bem seu sistema e sabe quanto ele consome de RAM, em que velocidade ele consome a RAM e quanto costuma ficar livre no sistema, baixar esse valor pode significar muito na durabilidade do seu SD. Eu não utilizo arquivo de paginação, por isso que no meu Raspberry o valor está como no padrão, mas se você quer garantir o funcionamento do sistema (porque ele travará automaticamente ao esgotar a memória), você pode criar seu arquivo de swap e definir sua utilização para somente quando estiver em, por exemplo, 5%. Para aplicar a modificação imediatamente:

sysctl vm.swappiness=5

E para persistir a configuração, edite o arquivo /etc/sysctl.conf e modifique o valor "vm.swappiness = 60**"** para "vm.swappiness = 5".

Escritas pequenas em um mesmo arquivo são significativas?

Essa é a grande pegadinha. Considerando que o cartão escreva de forma randômica, modificações em um mesmo arquivo podem ser alocadas em um mesmo setor, ou redistribuidos. Mas não é aí que está o problema.

Os sistemas de arquivos tem um conjuntos de informações sobre o arquivo alocado; seu tipo, tamanho, regiões em que se encontra no disco, nome, útimo acesso, timestamp de modificação, modificação de um node, propriedade, etc. um mínimo toque no arquivo fará que esses dados de baixo nível sejam reescritos e sim, isso é muito representativo. Tanto que essa característica é tratada em tunning de servidores. Relatei aqui uma dessas aventuras. Para evitar esse tipo de problema, garantindo maior durabilidade da midia e maior desempenho, no artigo anterior você ver os ajustes que desabilitam essas informações do sistema de arquivos, inseridas no fstab. São elas, noatime e  nodiratime. Claro que mais coisas podem ser feitas, mas sugiro que leia o artigo supracitado sobre tunning.

Aqui está uma série de comandos para você conferir as informações contidas nos inodes (criei um sistema de arquivos para o teste:

Alguns desses comandos são um pouco incomuns para a maioria dos usuários, mas utilizo muito na perícia forense digital.

Conclusão

Assim, voltando à questão que me levou a escrever esse artigo:

"Utilizar o sistema em read-only como descrito no post anterior aumentará a vida útil do cartão"?

A resposta é "sim". Além disso, evitará falhas de segmentação, perdas de bibliotecas e corrupção do sistema de arquivos em caso de falta de energia.

Inscreva-se no nosso canal Manual do Maker no YouTube.

Também estamos no Instagram.