Início / unix / Perguntas / 537965
Accepted
Travis Griggs
Asked: 2019-08-29 14:03:32 +0800 CST

Sincronizar ou não sincronizar em um ambiente incorporado?

  • 772

Eu tenho um dispositivo de placa única que executa o Debian 10 em um pedaço de flash. O UBIFS é usado e é dividido em dois volumes: um ro roots e um rw /var. Descobri que, em condições de ciclo de energia/redefinição, posso acabar com arquivos de 0 byte. Eu mantenho minhas "configurações" em /var/opt/myApp. Alterar a opção de montagem de /var para incluir syncparece fazer com que esses incidentes desapareçam.

Eu sei que o conselho usual é que o assíncrono é preferível à sincronização, mas geralmente é ressalvado com "geralmente, mas nem sempre" com pouca explicação sobre quais podem ser as exceções.

A solução alternativa seria modificar todo e qualquer site de chamadas onde eu escrevo dados no disco, para não apenas liberar o fechamento do arquivo, mas também sincronizar (faço muito disso com python). Por uma questão de codificação/completude, a montagem syncparecia menos trabalhosa e evitou que eu perdesse a adição dos guardas de sincronização em alguns lugares, pois é universal.

Além disso, permito que o dispositivo salve dados em pen drives USB. Acho que devo montar essa sincronização também, para reduzir a perda quando eles são retirados logo após os dados serem gravados neles.

Esta é uma configuração excepcionalmente adequada para justificar o uso sync? Ou devo usar a solução alternativa?

linux filesystems

1 respostas

  1. Best Answer

    Aqui está a minha opinião: Desculpe pela verbosidade com antecedência.

    Quando estamos falando especificamente ubifs, devemos sempre syncopções semelhantes.

    ubifsapoiawrite-back caching

    Isso significa que as alterações escritas nos arquivos não vão para o flash diretamente. Eles são armazenados no cache da página primeiro e depois gravados no flash. (Leia mais sobre write buffersflashes NAND no UBIFS)

    Isso melhora o desempenho do sistema de arquivos reduzindo o número de gravações.

    Observe que este é o asynchronouscomportamento de fs.

    Como você disse na pergunta, quando você monta o UBIFS com a opção -sync, ele fará com que o sistema de arquivos synchronous(as alterações sejam gravadas para piscar todas as vezes), mas ao custo da queda de desempenho.

    Se você estiver trabalhando com asynchronoussistemas de arquivos como ubifs, o ônus de garantir que as gravações sejam gravadas em flash é dos desenvolvedores de aplicativos. Aqui está o que a página man do write(2) diz:

    $ man 2 write
NOTES
   A  successful return from write() does not make any guarantee that data
   has been committed to disk.  In fact, on some buggy implementations, it
   does  not  even guarantee that space has successfully been reserved for
   the data.  The only way to be sure is to call fsync(2)  after  you  are
   done writing all your data.

    Usando

    sync- sincroniza fs inteiros. Pode não ser o ideal

    fsync- Principalmente faz o trabalho

    fdatasync- Somente as alterações de dados são liberadas e não os metadados (permissões). Mais ideal do que fsynctalvez (não tenho certeza)

    Leia também Boa leitura sobre fsync

    Então, no final, suas opções:

    1. montar com 'sincronização' - com impacto no desempenho
    2. melhorar o aplicativo usando as syncopções acima.
    3. lidar com arquivos de 0 byte em aplicativos
    4. criando arquivos temporários e renomeando-os mais tarde

    Último pensamento, pode querer mudar para fs síncrono como jffs2(não totalmente síncrono se estiver usando flash NAND). Eu sei que esta não é a resposta para sua pergunta, mas eh, escrevi tanto, como escrever isso ....

    • 1

relate perguntas