Преимущества загрузки файлов в /tmp перед перемещением в постоянное хранилище?

Question

Похоже, что общая тенденция в программировании при построении функциональности для обработки загрузки файлов заключается в том, чтобы сначала загрузить файл во временный каталог/папку (например, /tmp в Linux). После завершения файла он перемещается из временного каталога и помещается в указанный каталог для хранения. Некоторые языки программирования/сценариев по умолчанию помещают текущие загрузки в /tmp, а другие нет, однако, похоже, общепринятой практикой является явная установка /tmp в качестве каталога-заполнителя до завершения загрузки, после чего он перемещается в отдельный каталог.

В чем преимущество использования временного «каталога хранения» для загрузки контента перед перемещением файла(ов) в другой раздел/каталог для долгосрочного хранения?

Я работаю в среде, где (внутреннее) сетевое хранилище монтируется через NFS-монтирования к виртуальным машинам для постоянного хранения больших объемов данных (терабайты). По мере развития технологий мы можем поглощать данные быстрее и в гораздо более значительных количествах. Несколько лет назад это была простая HTTP-загрузка одного файла за раз (относительно небольшого размера, мегабайты?), затем мы перешли на Flash-загрузки. Теперь у нас есть загрузки методом перетаскивания, даже с возможностью загрузки структуры файлов/папок в некоторых браузерах, в области гигабайт. Дошло до того, что один пользователь может легко превысить раздел, отведенный для /tmp, если он действительно хочет загрузить достаточно за один раз. В чем преимущество расширения /tmp по сравнению с простой прямой отправкой на файловый сервер, помимо сетевой задержки через монтирование NFS? Является ли это устаревшей (теперь плохой) практикой, которая устарела теперь, когда технологии позволяют нам поглощать объемы данных, которые были бы немыслимы десятилетие назад?

Answer 1

1. Это необходимо для повышения производительности в случае, если указанный каталог хранения данных является сетевым хранилищем?
   • Да, это может быть, хотя и не обычно. Производительность фактической загрузки редко является основной проблемой производительности кода.
2. Проверяет ли Linux регулярно свой каталог /tmp, чтобы удалить старые файлы, избавляя разработчика/администратора от необходимости делать это где-то еще?
   • Да, как правило. Это также касается случая, когда процесс менеджера загрузки дает сбой и оставляет после себя частичный файл, который в противном случае не удалось бы очистить.
3. Это просто потому, что так оно и есть?
   • Да. :-)
4. Если бы мне предоставили возможность просто записать файл в каталог, в котором он в конечном итоге будет сохранен (например, с помощью модуля fs node.js), следует ли мне это делать или это табу?
   • Существуют веские причины для использования временного промежуточного каталога, а также для размещения его в той же файловой системе, что и целевой каталог. Многие приложения помещают этот каталог в то же дерево файлов, что и конечный целевой каталог, поэтому конечная операция «перемещения» будет почти мгновенной (и потенциально атомарной). Таким образом, вы часто будете видеть такие вещи, как /var/spool/myapp/tmpи /var/spool/myapp/data. Но затем приложение часто добавляет cronзадачу по очистке старых файлов в .../tmp.

Answer 2

Это действительно зависит от того, что еще есть в системе и как все это используется.

В некоторых системах /tmpобычно используется для системных файлов или пространства подкачки. Если вы заполняете /tmpна Solaris,плохие вещи случаются(и связанный с этим анекдот). В таком случае, если кто-то загрузит файл, который заполнит этот том, это может привести к краху вашей системы. Другие вещи, которые могут произойти, это то, что некоторые приложения не смогут записывать свои собственные временные файлы.

В старые времена можно было разумно доверять людям, что они не глупые (по крайней мере, за пределами сентября), и злобность тоже была достаточно низкой. Сегодня... это уже другая история.

Theпреимуществодля записи в /tmpтом, что это гарантированно была локальная файловая система на машине, присутствующая и патрулируемая (скрипты, которые обходили и автоматически удаляли старые файлы). Системынужныйa /tmpдля загрузки и быстрого доступа к этому было необходимо для разумной производительности в системе. Таким образом, вы хотите быстро записать файл где-то и затем переместить его? Поместите его в /tmp.

Учитывая все эти неприятные вещи, происходящие при /tmpзаполнении, следует рассмотреть другие альтернативы, которые обеспечивают то же преимущество — например, создание раздела, который монтируется для загрузки файлов и который не приведет к сбою системы при заполнении.

Другое соображение, однако, это «быстрый» бит. Диски стали быстрее со времен прошлого. Довольно быстро — хороший SSD может сдуть что угодно из того времени... но выДействительнонужен SSD для записи файлов загрузки? Не только погружения стали быстрее, но и сеть стала быстрее. Запись файлов загрузки в сетевое хранилище может помочь в единой точке, где вы можете иметь несколько систем, загружающих свои файлы в центральное место, где другие процессы могут затем взять на себя ответственность за сканирование и перемещение их в нужное место.

Итак... подведем итог:

• Имели преимущества в былые времена
  • быстрее сети, всегда рядом
• Могут возникнуть проблемы
• Дни прошлого уже не здесь
  • Диски и сети работают быстрее
  • Люди глупы и еще больше нападающих

Так что я бы сказал нет... больше не писать /tmpв качестве ответа по умолчанию. Проконсультируйтесь с вашим системным администратором о надлежащем месте для записи, которое соответствует его политике использования диска, и рассмотрите возможность записи в место, полностью удаленное от локальной системы.

Answer 3

/tmpэто просто удобное место для хранения файлов, и где-то, где вы можете быть уверены, что они будут очищены (если, например, веб-приложение не смогло этого сделать). Так что это разумное значение по умолчанию.

Если у вас есть возможность указать собственный путь для загрузки файлов, есть веская причина сделать его путем к тому же монтированию, что и конечное место назначения, поскольку тогда вы сможете использовать атомарное переименование, чтобы поместить его в конечное место. (Если это перекрестное монтирование, вам нужно сделать копию).

Я бы не стал загружать его в конечный пункт назначения, так как (например) если загрузка будет прервана в середине, вы можете остаться с частичным файлом там. Или если ваш скрипт умрет, вы можете остаться с потерянным файлом, на который не ссылается ваша база данных.

BTW: Помните, что имя файла, предоставленное клиентом, является ненадежными данными. Злонамеренный пользователь может легко дать вам имя файла ../../../something, и если вы не будете осторожны, вы можете в конечном итоге записать то, что не собираетесь делать.