¿Ventajas de cargar archivos en /tmp antes de pasar al almacenamiento permanente?

Question

Parece que la tendencia común en la programación cuando se crea una funcionalidad para manejar la carga de archivos es cargar el archivo primero en un directorio/carpeta temporal (por ejemplo, /tmp en Linux). Una vez que se completa el archivo, se saca del directorio temporal y se coloca en el directorio especificado para su almacenamiento. Algunos lenguajes de programación/scripting colocan de forma predeterminada las cargas en curso en /tmp, mientras que otros no, pero parece una práctica común establecer explícitamente /tmp como un directorio de marcador de posición hasta que se complete la carga, momento en el cual se mueve a un directorio separado.

¿Qué ventaja tiene utilizar un directorio temporal "de retención" para cargar contenido antes de mover los archivos a otra partición/directorio para almacenamiento a largo plazo?

Trabajo en un entorno donde el almacenamiento de red (interno) se monta mediante montajes NFS en máquinas virtuales para el almacenamiento persistente de grandes cantidades de datos (terabytes). A medida que avanza la tecnología, podemos ingerir datos más rápidamente y en cantidades mucho más significativas. Hace varios años, era una simple carga HTTP de un archivo a la vez (de tamaño relativamente pequeño, ¿megabytes?), luego pasamos a las cargas Flash. Ahora tenemos cargas mediante arrastrar y soltar, incluso con el potencial de cargar una estructura de archivos/carpetas en algunos navegadores, en el ámbito de los gigabytes. Está llegando al punto en el que un usuario podría fácilmente exceder la partición reservada para /tmp si realmente quiere cargar suficiente cantidad a la vez. ¿Cuál sería la ventaja de expandir /tmp versus simplemente enviarlo directamente al servidor de archivos, aparte de la latencia de la red a través del montaje NFS? ¿Es esta una práctica heredada (ahora mala) que se ha vuelto obsoleta ahora que la tecnología nos permite ingerir cantidades de datos que de otro modo serían inconcebibles hace una década?

Answer 1

1. ¿Es por motivos de rendimiento en caso de que el directorio de almacenamiento especificado sea almacenamiento de red?
   • Sí, puede serlo, aunque no habitualmente. El rendimiento de la carga real rara vez es la principal preocupación de rendimiento del código.
2. ¿Linux escanea rutinariamente [su] directorio /tmp para eliminar archivos antiguos, evitando que el desarrollador/administrador tenga que dar cuenta de eso en otro lugar?
   • Sí, normalmente. Esto también cubre el caso en el que el proceso del administrador de carga falla y deja un archivo parcial que de otro modo no se limpiaría.
3. ¿Es así simplemente porque es así?
   • Sí. :-)
4. Si se me da la oportunidad de simplemente escribir el archivo en el directorio en el que finalmente se almacenará (por ejemplo, usando el módulo fs de node.js), ¿debería hacerlo o es un no-no?
   • Hay buenas razones para utilizar un directorio temporal y también para ubicarlo en el mismo sistema de archivos que el directorio de destino. Muchas aplicaciones colocan este directorio en el mismo árbol de archivos que el directorio de destino final, por lo que la eventual operación de "mover" será casi instantánea (y potencialmente atómica). Por lo tanto, a menudo verás cosas como /var/spool/myapp/tmpy /var/spool/myapp/data. Pero luego la aplicación a menudo agrega una crontarea para limpiar archivos antiguos en formato .../tmp.

Answer 2

Esto realmente depende de qué más hay en el sistema y de cómo se utilizan las cosas.

En algunos sistemas, /tmpse usa comúnmente para archivos del sistema o espacio de intercambio. Si llenas combustible /tmpcon Solaris,pasan cosas malas(y anécdota relacionada). En tal caso, si alguien carga un archivo que llena este volumen, su sistema puede fallar. Otras cosas que pueden suceder son que ciertas aplicaciones no puedan escribir sus propios archivos temporales.

En el pasado, se podía confiar razonablemente en que la gente no fuera estúpida (al menos fuera de septiembre) y la malicia también era razonablemente baja. Hoy... esa es una historia diferente.

Elventajaa escribir /tmpes que se garantizaba que sería un sistema de archivos local en la máquina, presente y patrullado (scripts que circularían y eliminarían archivos antiguos automáticamente). SistemasnecesarioEra necesario un /tmparranque y un acceso rápido a este para un rendimiento razonable del sistema. Por lo tanto, ¿quieres escribir un archivo rápidamente en algún lugar y luego moverlo? Ponlo adentro /tmp.

Con eso de que suceden cosas malas cuando /tmpestá lleno, uno debería buscar otras alternativas que proporcionen la misma ventaja, como crear una partición montada para cargar archivos que no bloquee la máquina cuando esté lleno.

Sin embargo, otra consideración es esa parte "rápida". Las unidades se han vuelto más rápidas desde la antigüedad. Bastante más rápido: un buen SSD puede eliminar cualquier cosa de aquel entonces... pero, ¿lo haces?en realidad¿Necesita un SSD para escribir archivos cargados? No sólo las inmersiones se han vuelto más rápidas, sino que la red se ha vuelto más rápida. Escribir archivos de carga en un área de almacenamiento de red puede ayudar en un punto único donde puede tener varios sistemas cargando sus archivos en un lugar central donde otros procesos pueden asumir la responsabilidad de escanearlos y moverlos a la ubicación adecuada.

Entonces... para resumir:

• Tenía ventajas en los viejos tiempos.
  • Más rápido que la red, siempre ahí.
• Podría causar problemas
• Los viejos tiempos ya no están aquí
  • Unidades y redes más rápidas
  • La gente es estúpida y más atacantes.

Entonces, diría que no... no escribas /tmpmás como respuesta predeterminada. Consulte con el administrador de su sistema cuál es el lugar adecuado para escribirlos que se ajuste a su política de uso del disco y considere escribirlos en algún lugar completamente fuera del sistema local.

Answer 3

/tmpes simplemente un lugar conveniente para colocar archivos, y un lugar en el que puede estar bastante seguro de que se limpiará (si, por ejemplo, la aplicación web no pudo hacerlo). Entonces es un valor predeterminado razonable.

Si tiene la opción de especificar su propia ruta para cargar los archivos, hay una buena razón para convertirla en una ruta en el mismo soporte que el destino final, ya que entonces puede usar un cambio de nombre atómico para ponerlo en su formato final. lugar. (Si es de montaje cruzado, debe hacer una copia).

No lo subiría a su destino final, ya que (por ejemplo) si la carga se cancela en el medio, podría quedar un archivo parcial allí. O si su secuencia de comandos muere, podría quedarse con un archivo huérfano al que su base de datos no hace referencia.

Por cierto: recuerde que el nombre de archivo proporcionado por el cliente no son datos de confianza. Un usuario malintencionado podría fácilmente darle el nombre del archivo ../../../somethingy, si no tiene cuidado, podría terminar escribiendo algo que no desea.