Я реализую систему загрузки и архивации торрентов. Я хочу скачать торрент-файл (содержащий несколько небольших файлов), а затем архивировать его. Производительность моего Диска низкая. поэтому мне нужен эффективный способ архивации файлов.
У меня есть несколько вариантов:
1.Загрузите файлы на обычный диск/файловую систему, а затем заархивируйте их с помощью обычной tarкоманды Unix.
2.Создайте пустой архив TAR, затем смонтируйте его в режиме записи с помощью archivemount, а затем начните загрузку торрента по смонтированному пути.
3.Аналогично варианту2но используя ZIP-файл вместо tar.
4.Поскольку я хочу доставлять файлы через веб-браузер: Реализовать программное обеспечение/скрипт для архивации папки в TAR на лету. (Я написал скрипт на Python (uWsgi/Nginx) несколько лет назад, чтобы сделать это. Но поскольку tar требует контрольную сумму для каждого файла, производительность была довольно низкой)
5.Найдите торрент-клиент, который может записывать напрямую в файл TAR/Zip. (Маловероятно)
Какой вариант мне следует рассмотреть?
Спасибо.
решение1
Лучшим для производительности на самом деле все еще, вероятно, будет 4, если диск действительно является вашим узким местом. Это избавит вас от необходимости тратить драгоценные IOPS на копирование файлов из одного места в другое.
Кроме того, вариант 4 — это единственный вариант, который позволит клиенту мгновенно загрузить торрент, как только ваш сервер закончит загрузку, то есть клиент сможет получить свои данные раньше. Кроме того, таким образом у вас есть возможность легко разрешить пользователю загружать отдельные файлы (это очень просто, поскольку они просто лежат в вашей файловой системе).
Я бы исследовал, почему tar давал вам такую низкую производительность. Я действительно сомневаюсь, что проблема была в контрольных суммах, поскольку их даже нет в данных, насколько я помню. Есть ли причина, по которой вы не можете просто перенаправить вывод GNU tar напрямую в веб-браузер, а не писать свой собственный упаковщик tar?
Одной из проблем будет предоставление клиенту корректной длины контента при таком подходе. Если вас это не волнует, вы можете просто не отправлять это, и тогда ваш клиент просто не увидит процентный счетчик для загрузки. Это может не иметь значения в зависимости от вашего приложения.