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

Question

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

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

Eu trabalho em um ambiente onde o armazenamento de rede (interno) é montado por meio de 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 simples upload HTTP de um arquivo por vez (de tamanho relativamente pequeno, megabytes?), depois passamos para uploads em Flash. Agora temos uploads de arrastar e soltar, mesmo com o potencial de carregar uma estrutura de arquivo/pasta em alguns navegadores, na casa dos gigabytes. Está chegando ao ponto em que um usuário pode facilmente exceder a partição reservada para /tmp se realmente quiser fazer upload suficiente de uma vez. Qual seria a vantagem de expandir /tmp em vez de apenas enviá-lo diretamente para o servidor de arquivos, além da latência da rede por meio da montagem NFS? Será esta uma prática legada (agora má) que se tornou obsoleta agora que a tecnologia nos permite ingerir quantidades de dados que de outra forma seriam inconcebíveis há uma década?

Answer 1

1. É para desempenho caso o diretório de armazenamento especificado seja armazenamento de rede?
   • Sim, pode ser, embora geralmente não. O desempenho do upload real raramente é a principal preocupação de desempenho do código.
2. O Linux verifica rotineiramente [seu] diretório /tmp para excluir arquivos antigos, evitando que o desenvolvedor/administrador tenha 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. É assim porque é?
   • Sim. :-)
4. Se tiver a oportunidade de simplesmente gravar o arquivo no diretório em que ele será armazenado (por exemplo, usando o módulo fs do node.js), devo, ou isso é proibido?
   • Existem 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, portanto a eventual operação de "mover" será quase instantânea (e potencialmente atômica). Assim, você verá frequentemente coisas como /var/spool/myapp/tmpe /var/spool/myapp/data. Mas então o aplicativo geralmente adiciona uma crontarefa para limpar arquivos antigos no formato .../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 de sistema ou espaço de troca. Se você abastecer /tmpno Solaris,coisas ruins acontecem(e anedota relacionada). Nesse caso, se alguém fizer upload de um arquivo que preencha esse volume, seu sistema poderá travar. Outras coisas que podem acontecer é que certos aplicativos não serão capazes de gravar seus próprios arquivos temporários.

Antigamente, era razoável confiar que as pessoas não seriam estúpidas (pelo menos fora de setembro) e a malícia também era razoavelmente baixa. Hoje... essa é uma história diferente.

OvantagemO que escrever /tmpé que era garantido que era um sistema de arquivos local na máquina, presente e patrulhado (scripts que circulavam e excluíam arquivos antigos automaticamente). Sistemasnecessáriouma /tmpinicialização e acesso rápido a isso eram necessários para um desempenho razoável do sistema. Então, você deseja gravar um arquivo rapidamente em algum lugar e depois movê-lo? Coloque dentro /tmp.

Com aquela parte sobre coisas ruins acontecendo quando /tmpestá cheio, deve-se procurar outras alternativas que ofereçam a mesma vantagem - como criar uma partição montada para fazer upload de arquivos que não trave a máquina quando a máquina estiver cheia.

Outra consideração, porém, é aquela parte 'rápida'. As unidades ficaram mais rápidas desde os tempos antigos. Um pouco mais rápido - um bom SSD pode destruir qualquer coisa daquela época... mas vocêrealmenteprecisa de um SSD para gravar arquivos de upload? Não apenas os mergulhos ficaram mais rápidos, mas a rede também ficou mais rápida. Gravar arquivos de upload em uma área de armazenamento de rede pode ajudar no ponto único onde você pode ter vários sistemas enviando seus arquivos para um local 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 tempos antigos
  • mais rápido que a rede, sempre presente
• Poderia causar problemas
• Os velhos tempos não estão mais aqui
  • Unidades e redes mais rápidas
  • As pessoas são estúpidas e mais agressoras

Então, eu diria que não... não escreva /tmpmais como resposta padrão. Verifique com o administrador do sistema sobre o local adequado para gravá-los, de acordo com sua política de uso de disco, e considere gravá-los em algum lugar completamente fora do sistema local.

Answer 3

/tmpé apenas um local conveniente para colocar arquivos e um local onde você pode ter certeza de que será limpo (se, por exemplo, o aplicativo da web não conseguir fazer isso). Portanto, é um padrão razoável.

Se você tiver a opção de especificar seu próprio caminho para fazer upload dos arquivos, há um bom motivo para torná-lo um caminho na mesma montagem do destino final, pois então você pode usar uma renomeação atômica para colocá-lo em seu destino final. lugar. (Se for montagem cruzada, você precisa fazer uma cópia).

Eu não faria o upload para o destino final, pois (por exemplo) se o upload fosse abortado no meio, você poderia ficar com um arquivo parcial lá. Ou se o seu script morrer, você poderá 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 é um dado não confiável. Um usuário mal-intencionado pode facilmente fornecer o nome do arquivo ../../../somethinge, se você não tomar cuidado, poderá acabar escrevendo algo que não pretendia.