Linux: загрузка незавершенных файлов - с проверкой размера файла (scp/rsync)

Question

Обычно я вхожу в следующую ситуацию: у меня есть, скажем, видео-файл формата MPEG-2 .avi емкостью 650 МБ с камеры. Затем я использую ffmpeg2theora, чтобы преобразовать его в видеофайл Theora .ogv, скажем, около 150 МБ. Наконец, я хочу загрузить этот .ogv-файл на сервер ssh.

Скажем, процесс кодирования ffmpeg2theora занимает около 15 минут на моем ПК. С другой стороны, загрузка продолжается со скоростью около 60 КБ/с, что занимает около 45 минут (для 150 МБ .ogv). Итак: если я первый закодировать, и ждать, пока процесс кодирования, чтобы закончить - и затем загружает, это займет примерно

15 min + 45 min = 1 hr 

для завершения операции.

Итак, я подумал, что было бы лучше, если бы я мог как-то начать загрузку, параллельно с помощью операции кодирования; то, в принципе, поскольку процесс загрузки медленнее (с точки зрения переданных байтов/сек), чем кодирующий (с точки зрения сгенерированных байтов/сек.) - процесс загрузки всегда будет «отставать» от кодировки , и поэтому вся операция (enc + upl) будет завершена всего за 45 минут (то есть только время процесса загрузки +/- несколько минут в зависимости от фактической ситуации с загрузкой на проводе).

Моей первой идея состояла в том, чтобы трубы выхода ffmpeg2theora к tee (с тем, чтобы сохранить локальную копию .ogv), а затем, труба на выходе дополнительно к ssh - как в:

./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 -o /dev/stdout MVI.AVI | tee MVI.ogv | ssh user@ssh.server.com "cat > ~/myvids/MVI.ogv" 

Хотя эта команда действительно выполняет функцию - в рабочем журнале терминала можно легко увидеть от ffmpeg2theora, что в этом случае ffmpeg2theora рассчитывает, что предсказанное время завершения составляет 1 час; то есть, кажется, нет преимущество с точки зрения меньшего времени завершения как для enc + upl. (Хотя возможно, что это связано с перегрузкой сети, и я получаю меньше скорости сети в то время - мне кажется, что ffmpeg2theora должен ждать подтверждения для каждого небольшого фрагмента данных, которые он отправляет по трубе , и что ACK, наконец, должен произойти от ssh ... В противном случае ffmpeg2theora не смог бы предоставить оценку времени завершения. Опять же, возможно, оценка ошибочна, а операция действительно завершится через 45 минут - dunno, never было терпения ждать, и время процесса, я просто получить обозленный на 1hr как оценка, и нажмите Ctrl-C;) ...)

Мой второй попытка была запустить процесс кодирования в одном окне терминала, т.е.:

./ffmpeg2theora-0.27.linux32.bin -v 8 -a 3 MVI.AVI  # MVI.ogv is auto name for output 

..., и процесс загрузки, используя scp, в другом окне терминала (тем самым 'заставляя' 'распараллеливание'):

scp MVI.ogv user@ssh.server.com:~/myvids/ 

Проблема состоит в следующем: допустим, в то время когда начинается scp, ffmpeg2theora уже закодировал 5 МБ выходного файла .ogv. В это время scp видит этот 5 МБ как весь размер файла и начинает загрузку - и он выходит, когда он встречает отметку 5 МБ; в то время как в то же время ffmpeg2theora, возможно, произвел дополнительные 15 МБ, делая.ogv-файл 20 МБ в общем размере на момент scp вышел (завершение передачи первых 5 МБ).

Потом я узнал (joen.dk » Tip: scp Resume), что rsync поддерживает «резюме» частично завершенных закачек, как в:

rsync --partial --progress myFile remoteMachine:dirToPutIn/ 

..., поэтому я попытался с помощью rsync вместо scp - но это, кажется, ведут себя точно то же, что и scp с точки зрения размера файла, то есть: он будет передавать только размер файла, считанного в начале процесса, а затем он выйдет.

Я предполагаю, что там может быть несколько способов, как в:

• опции командной строки (я не видел), что заставляет scp/rsync постоянно проверять размер файла - если файл открыт для записи другим процессом (, тогда я мог бы просто запустить загрузку в другое окно терминала)
• Сценарий bash; скажем, запустить rsync --partial в цикле while, который работает до тех пор, пока файл .ogv открыт для записи другим процессом (Мне действительно не нравится это решение, так как я могу слышать сканирование жесткого диска для точки возобновления, каждый раз, когда я запустить rsync --partial - который, я думаю, не может быть хорошо, если я знаю, что тот же файл записывается в то же время)
• другой инструмент (кроме scp/rsync), что делает поддержку загрузки образа «в настоящее время () Предполагая, что он может обрабатывать только растущие файлы, он будет завершен, если обнаружит, что локальный файл внезапно стал меньше размера, чем уже переданные байты)

... но также может быть, что я что-то пропускаю - и 1 час так же хорош, как и получается (другими словами, возможно, логически невозможно достичь 45-минутного общего времени - даже при попытке распараллеливать) :)

Ну, я с нетерпением жду комментариев, которые бы, надеюсь, разъясняют это для меня;)

заранее спасибо,
Ура!

Answer 1

Может быть, вы можете попробовать sshfs (http://fuse.sourceforge.net/sshfs.html). Это файловая система должна иметь некоторую оптимизацию, хотя я не очень уверен.