Vantagens de fazer upload de arquivos para / tmp antes de sair para armazenamento permanente?

Question

Parece que a tendência comum na programação ao criar funcionalidade para lidar com uploads de arquivos é fazer o upload do arquivo para um diretório / pasta temporário (por exemplo, / tmp no Linux). Depois que o arquivo é concluído, ele é movido para fora do diretório temporário e colocado no diretório especificado para armazenamento. Algumas linguagens de programação / script padrão para ter uploads em andamento são colocadas em / tmp, enquanto outras não, mas parece prática comum definir explicitamente / tmp como um diretório de espaço reservado até que o upload seja concluído, no ponto em que é movido para um diretório separado.

Qual a vantagem de usar um diretório "holding" temporário para carregar conteúdo antes de mover o (s) arquivo (s) para outra partição / diretório para armazenamento a longo prazo?

Eu trabalho em um ambiente onde o armazenamento de rede (interno) é montado via montagens NFS em máquinas virtuais para armazenamento persistente de grandes quantidades de dados (terabytes). À medida que a tecnologia avança, somos capazes de ingerir dados mais rapidamente e em quantidades muito mais significativas. Vários anos atrás, era um upload HTTP simples de um arquivo de cada vez (de tamanho relativamente pequeno, megabytes?), Depois fomos para os uploads em Flash. Agora temos arrastar e soltar carregamentos, mesmo com o potencial de fazer o upload de uma estrutura de arquivos / pastas em alguns navegadores, no reino dos gigabytes. Está chegando ao ponto em que um usuário pode facilmente ultrapassar a partição reservada para / tmp se realmente quiser carregar o suficiente de uma só vez. Qual seria a vantagem de expandir / tmp versus apenas tê-lo enviado diretamente para o servidor de arquivos, além da latência de rede através da montagem NFS? Isso é uma prática legada (agora ruim) que se tornou desatualizada agora que a tecnologia está nos permitindo ingerir quantidades de dados que seriam inconcebíveis uma década atrás?

    

Answer 1

1. É para desempenho no caso do diretório de armazenamento especificado ser o armazenamento de rede?
   • Sim, pode ser, embora não seja normalmente. O desempenho do upload real raramente é a principal preocupação de desempenho do código.
2. O Linux examina rotineiramente o diretório [its] / tmp para excluir arquivos antigos, salvando o desenvolvedor / administrador por ter que contabilizar isso em outro lugar?
   • Sim, normalmente. Isso também cobre o caso em que o processo do gerenciador de upload falha e deixa para trás um arquivo parcial que, de outra forma, não seria limpo.
3. É só assim porque é?
   • Sim. : -)
4. Se for dada a oportunidade de simplesmente gravar o arquivo no diretório, ele será finalmente armazenado (por exemplo, usando o módulo fs do node.js), devo, ou isso é um não-não?
   • Há boas razões para usar um diretório temporário e também para localizá-lo no mesmo sistema de arquivos que o diretório de destino. Muitos aplicativos colocam esse diretório na mesma árvore de arquivos que o eventual diretório de destino, de modo que a eventual operação de "movimentação" será quase instantânea (e potencialmente atômica). Assim, muitas vezes você verá coisas como /var/spool/myapp/tmp e /var/spool/myapp/data . Mas o aplicativo geralmente adiciona uma tarefa cron para limpar arquivos antigos em .../tmp .

Answer 2

Isso realmente depende do que mais está no sistema e de como as coisas estão sendo usadas.

Em alguns sistemas, /tmp é comumente usado para arquivos do sistema ou espaço de troca. Se você encher /tmp no Solaris, coisas ruins acontecem ( anedota relacionada ). Nesse caso, se alguém fizer o upload de um arquivo que preencha esse volume, ele poderá travar seu sistema. Outras coisas que podem acontecer são certos aplicativos não poderão gravar seus próprios arquivos temporários.

Nos dias passados, você podia razoavelmente confiar que as pessoas não eram estúpidas (pelo menos fora de setembro) e a malícia era razoavelmente baixa também. Hoje ... isso é uma história diferente.

A vantagem de escrever para /tmp é que era garantido que fosse um sistema de arquivos local na máquina, presente e patrulhado (scripts que iriam rodar e excluir arquivos antigos automaticamente). Sistemas necessários um /tmp para inicializar e acesso rápido a isso era necessário para um desempenho razoável no sistema. Assim, você quer gravar um arquivo rapidamente em algum lugar e depois movê-lo? Coloque em /tmp .

Com esse pouco de coisas ruins acontecendo quando /tmp está cheio, deve-se olhar para outras alternativas que fornecem a mesma vantagem - como fazer uma partição que é montada para fazer upload de arquivos, que não trava a máquina quando as coisas estão cheio.

Outra consideração é o bit 'rápido'. As unidades ficaram mais rápidas desde os tempos antigos. Bastante mais rápido - um bom SSD pode explodir qualquer coisa daquela época ... mas você realmente precisa de um SSD para gravar arquivos de upload? Não só os mergulhos ficaram mais rápidos, mas a rede ficou mais rápida. A gravação de arquivos de upload em uma área de armazenamento de rede pode ajudar no único ponto em que vários sistemas podem fazer upload de seus arquivos para um ponto central, onde outros processos podem assumir a responsabilidade de digitalizá-los e movê-los para o local adequado.

Então ... para resumir:

• Teve vantagens nos dias de antigamente
  • mais rápido que a rede, sempre lá
• Pode causar problemas
• Dias antigos não estão mais aqui
  • Drives e redes mais rápidos
  • As pessoas são estúpidas e mais atacantes

Então, eu diria que não ... não escreva mais para /tmp como resposta padrão. Verifique com o administrador do sistema sobre o local apropriado para escrevê-los, de acordo com a política de uso de disco, e considere gravá-los em um local completamente fora do sistema local.

    

Answer 3

/tmp é apenas um local conveniente para colocar arquivos, e em algum lugar em que você possa ter certeza de que será limpo (se, por exemplo, o aplicativo da Web não tiver feito isso). Então é um padrão razoável.

Se você tiver a opção de especificar seu próprio caminho para carregar os arquivos, há um bom motivo para torná-lo um caminho na mesma montagem que o destino final, assim você pode usar um renomeado atômico para colocá-lo em seu lugar final. (Se o seu cross-mount, você precisa fazer uma cópia).

Eu não iria enviá-lo para o seu destino final, como (por exemplo) se o upload foi abortado no meio, você poderia ficar com um arquivo parcial lá. Ou se seu script morrer, você pode ficar com um arquivo órfão que não é referenciado pelo seu banco de dados.

BTW: Lembre-se de que o nome do arquivo fornecido pelo cliente é de dados não confiáveis. Um usuário mal-intencionado pode facilmente fornecer o nome do arquivo ../../../something e, se você não for cuidadoso, pode acabar escrevendo para algo que não pretende.