Melhor maneira de 'endurecer' servidor de arquivos ext4 incorporado contra perda inesperada de energia?

Question

Primeiro, um pouco de experiência: minha empresa fabrica um dispositivo de streaming de áudio que é uma caixa Linux montada em rack e sem cabeça com uma unidade e-SATA de estado sólido conectada. A unidade é formatada com ext4. Os usuários podem se conectar ao sistema usando o Samba / CIFS para carregar novos arquivos de áudio ou acessar os existentes. Há também um software personalizado para streaming de áudio pela rede.

Tudo bem. O único problema é que os usuários são pessoas de áudio, não pessoas de computador, e veem o sistema como uma 'caixa preta', não como um computador. O que significa que no final do dia, eles não estão indo para a caixa e digite "/ sbin / shutdown -h"; eles só vão cortar a energia do rack e sair, e esperar que as coisas ainda funcionem corretamente no dia seguinte.

Como o ext4 tem o diário, soma de verificação de diário, etc, isso funciona principalmente. A única vez que não funciona é quando alguém carrega um novo arquivo via Samba e depois corta a energia para o sistema antes que os dados carregados sejam totalmente liberados para o disco. Nesse caso, eles chegam no dia seguinte e descobrem que o novo arquivo foi truncado ou está totalmente perdido, e estão insatisfeitos.

Minha pergunta é: qual é a melhor maneira de evitar esse problema? Existe uma maneira de fazer com que o smbd chame "sync" ao final de cada upload? (O desempenho nos envios não é tão importante, pois eles ocorrem apenas ocasionalmente). Ou existe uma maneira de dizer ao ext4 para liberar automaticamente dentro de alguns segundos de qualquer alteração em um arquivo? (Novamente, o desempenho pode ser sacrificado por segurança aqui) Devo definir um modo específico de gravação, ativar barreiras, etc?

    

Answer 1

Montar o sistema de arquivos com sync especificado no fstab provavelmente ajudaria. Suspeito que alguém tenha uma recomendação mais adequada para sua aplicação específica.

Eu comecei a pesquisa inicial sobre sistemas de arquivos usados com armazenamento flash, como eu quero construir um PC de home theater como um aparelho. Você pode encontrar uma solução de armazenamento diferente, mais adequada ao seu dispositivo. Infelizmente, ainda não encontrei algo que eu prefiro, por isso não tenho uma recomendação detalhada.

Editar 1

De acordo com a man page do smb.conf (5), ele suporta sincronização imediata dentro do SAMBA:

   strict sync (S)
          Many Windows applications (including the Windows 98
          explorer  shell)  seem  to  confuse flushing buffer
          contents to disk with doing a sync to  disk.  Under
          UNIX,  a  sync  call  forces the process to be sus-
          pended until the kernel has ensured that  all  out-
          standing  data  in  kernel  disk  buffers  has been
          safely stored onto stable  storage.  This  is  very
          slow  and  should only be done rarely. Setting this
          parameter to no (the default)  means  that  smbd(8)
          ignores  the  Windows  applications  requests for a
          sync call. There is only a  possibility  of  losing
          data  if  the operating system itself that Samba is
          running on crashes, so there is  little  danger  in
          this  default setting. In addition, this fixes many
          performance problems that people have reported with
          the new Windows98 explorer shell file copies.

          Default: strict sync = no

   sync always (S)
          This  is  a boolean parameter that controls whether
          writes will always be  written  to  stable  storage
          before  the  write call returns. If this is no then
          the server will be guided by the  client's  request
          in  each write call (clients can set a bit indicat-
          ing that a particular write should be synchronous).
          If this is yes then every write will be followed by
          a fsync()  call to ensure the data  is  written  to
          disk.  Note  that the strict sync parameter must be
          set to yes in order for this parameter to have  any
          affect.

          Default: sync always = no

    

Answer 2

Certo, eu tenho trabalhado com o mesmo tipo de problema. Se você desabilitar qualquer tipo de cache de gravação no sistema, todos os dados serão gravados no disco o mais rápido possível.

Você perderá desempenho, mas obterá melhor integridade dos dados.

A diferença entre os dados no disco e o que o sistema operacional pensa estar no disco (mas na verdade armazena em cache na memória) será significativamente menor.

Se você não puder usar um no-break para a solução, ou alguma solução de hardware que normalmente desligue a máquina se a energia for perdida do AC, então você terá que usar hacks como este.

Pode ser uma idéia usar um sistema de arquivos muito mais simples para armazenar a mídia e inicializar o sistema operacional a partir de um ramdisk. Evitando assim a chance de corromper a partição boot / root da máquina.

Então, para recapitular,

Monte o sistema de arquivos com a sincronização, você perderá desempenho, no entanto, todas as gravações não serão armazenadas em cache.

Desative os caches de gravação de disco de hardware, novamente você perderá desempenho.

Este artigo deve ser do seu interesse

link

    

Answer 3

Desde que você mencionou que sua empresa constrói isso, eu recomendo olhar para um ângulo de hardware. Eu vi servidores com backups de bateria nos controladores de unidade para permitir que dados armazenados em cache sobrevivam a uma perda de energia. E se seus engenheiros construíssem uma pequena bateria para manter o sistema funcionando por tempo suficiente para desligar a máquina? Ele não precisaria ser um no-break grande e separado, poderia ser interno e configurado para desligar o sistema assim que a energia do A / C fosse perdida. Pode adicionar alguns dólares ao custo, mas também pode ser um ponto de marketing.