Como detectar uma falha iminente do dispositivo MTD

Question

Escrevemos software que é executado em dispositivos de terceiros. Em um dos dispositivos que suportamos, a fabricação nos diz para não gravar na unidade flash, ou corremos o risco de usar as operações limitadas de gravação que ele suporta. Infelizmente, um dos requisitos da nossa aplicação é persistir alguns dados nas botas e não temos outra alternativa.

Eu não sei exatamente o que é a unidade dentro do dispositivo, nem como ele está configurado, então uma pergunta é: como posso encontrar essas informações? Algumas informações que consegui encontrar: bash-3.2$ df | grep mtd /dev/mtdblock5 65536 7824 57712 12% /apps

bash-3.2$ dmesg | grep -i mtd Kernel command line: root=/dev/mtdblock4 rootfstype=jffs2 rw ip=none console= mem=128M init=/sbin/init mtdparts=mtd:512k(bootloader),512k(env),2M(kernel_a),2M(kernel_b),59M(filesystem),64M(user) loglevel=3 panic=5 reboot=h 6 cmdlinepart partitions found on MTD device <NULL> Creating 6 MTD partitions on "<NULL>":

Eu dei uma olhada em proc e sysfs e não achei nada útil. O ambiente do dispositivo não possui ferramentas úteis instaladas como hdparam, lshw, etc. que eu possa encontrar.

Outra questão é se há algum software heurístico para detectar se o 'limite de gravação' está se aproximando?

Por fim, há alguma prática recomendada que possa ser observada ao gravar no disco para limitar os efeitos negativos? Por exemplo, as pequenas explosões de escrita são melhores do que as operações de gravação sustentada? É a taxa de transferência de dados que é o problema ou é uma coisa do sistema de arquivos? Se eu abrir um arquivo sem fechá-lo e continuar a transmitir dados lá, será melhor do que se eu abrir, escrever e fechar cada novo dado?

Muito obrigado por qualquer ajuda que você possa fornecer Dan.

    

Answer 1

If I open a file without closing it and continue to stream data there, is it better than if I open, write and close for each new piece of data?

Não. Fechar ou não fechar um arquivo em que a saída é armazenada em buffer faz diferença se / quando os dados estão visíveis para serem lidos no arquivo, mas isso é diferente de quando ele é fisicamente gravado em disco.

Em outras palavras, quando você solta um filehandle (por exemplo, fechando-o), uma leitura de processo separada do mesmo arquivo agora poderá ler os dados que você liberou para o arquivo, mas isso não significa necessariamente que o arquivo literalmente foi escrito pelo kernel. Se estiver em uso, é possivelmente armazenado em cache, e pode ser apenas o cache que é afetado.

Os caches de disco do sistema são liberados (- > gravados em um dispositivo) quando sync é chamado em um sistema de arquivos inteiro. AFAIK não há como fazer isso em um único arquivo.

Another question is whether there are any heuristics software could use to detect whether the 'write limit' is approaching?

Eu duvido muito, especialmente porque você não sabe muito sobre o dispositivo. Números como esse serão aproximados e conservadores, e é por isso que os dispositivos de imagem geralmente não são criados para falhar em um ponto predefinido: eles falham quando falham e, como eles poderiam falhar a qualquer momento, você também pode fazer o que puder para verificar e proteger contra perdas por causa disso, ponto final, em vez de supor que está tudo bem até ~ N operações.

Execute fsck sempre que possível (antes de montar os sistemas de arquivos). Se este for um dispositivo de longa duração, determine uma forma de desmontar e fsck em intervalos quando o sistema estiver ocioso.