Особенности работы rtorrent с использованием раздела ext3 для временных файлов
Конфигурация rtorrent с использованием отдельного раздела HDD в ext3
для временного хранения закачиваемых файлов (с последующим перемещением
уже скачанных в раздел с NTFS) имеет ряд преимуществ:
- rtorrent работает ощутимо быстрее с ext3. Это "родная" файловая система для Unix-ов, в отличие от NTFS;
- основная нагрузка при конкурентном доступе на запись нескольких
одновременно закачиваемых файлов ложится только на "временный" раздел
ext3. По этой причине, в случае непредвиденного выключения плеера (при пропадании электропитания, например), риск нарушения целостности
файловой системы велик только для ext3. В случае, разрушения ext3, мы
потеряем только порции недокачанных файлов. Одна команда форматирования
раздела ext3 возвращает rtorrent в полностью работоспособное состояние. В любом случае, разрушение ext3 никак не влияет на основную функциональность плеера по воспроизведению фильмов и работе остальных приложений;
- раздел NTFS, который содержит ценные данные (фильмы), большую часть
времени находится в режиме чтения, поэтому риск потери данных
минимальный;
- в NTFS файл полностью записываются одной операцией. Данные ложатся на
диск последовательно. Фрагментация файловой системы, практически,
отсутствует. Это, в итоге, позитивно сказывается на скорости воспроизведения фильмов с большим битрейтом.
С достоинствами все понятно. Есть ли недостатки ? Есть один, но заметный.
Когда файл полностью закачан во временный раздел, он переписывается из ext3 в NTFS стандартной командой mv (move). С учетом того, что драйвер файловой системы NTFS в Unix работает очень медленно на запись, а также с учетом больших размеров видео файлов (типичный HD фильм имеет размер 20-40 ГБ), этот процесс может занять много времени. Кроме того, процесс переноса фильма создает очень сильную нагрузку на процессор.
На скриншотах приложения atop, приведенных ниже, можно увидеть развитие ситуации: 1. До начала переноса файла из ext3 в NTFS:
Работа rtorrent с несколькими закачками занимает всего 7% ресурсов процессора (10-12% памяти - на скриншоте не показано) при скорости закачки по NET=eth0 654 Кбит в секунду и скорости роздачи файлов = 466 Кбит в секунду. Процессор (CPU) простаивает (idle) на 86%, винчестер (DSK=sda) загружен всего на 2%.
2. И картина во время переноса фильма "Star Track ... .mkv" командой "mv" из ext3 каталога incomplete:
видим наш процесс с PID=2421 (смотрим командой "ps"):
Здесь мы видим, что процесс "mv" съедает 83% ресурсов процессора. Процессор загружен полностью. Трафик по сети NET=eth0 упал в ноль на закачку и роздачу. Web-интерфейс rtorrent стал временно недоступен. Web-серверы lighttpd и unicgi (был также запущен) работали, но получали очень мало квантов процессорного времени, чтобы сформировать ответ по сети в отведенное по timeout время. Интерфейс самого плеера работал очень-очень медленно.
Нагрузка на винчестер также резко возросла (загрузка на 73%). Чтение и запись во время перемещения фильма примерно равны по объему. На загрузку оперативной памяти процесс переноса файла влияния не оказал.
Проблем с подключением и отзывчивостью telnet для 2-3 сессий не было. Работать можно вполне комфортно.
Попытка выключить плеер с пульта перевела его в режим выключения только формально. Цвет светодиода на лицевой панеле сменился с синего на красный, но плеер продолжал активно работать винчестером, не выключался вентилятор охлаждения и т.д.
Эксперимент с физическим отключением электрического питания плеера в этом состоянии проблем не создал: Загрузка прошла в штатном режиме, данные в файловых системах NTFS и ext3 потеряны не были. rtorrent начал сразу же отдавать по сети ранее скачанные файлы. Текущие закачки, конечно, упали и начали перекэшироваться. Но, поскольку, ранее недокачанные файлы, на ext3 никуда не делись, закачки автоматически восстановились довольно оперативно.
Не рекомендуется повторять данный эксперимент, поскольку существует теоретическая возможность потери данных на винчестере. Отключайте плеер только с пульта или из telnet-сессии. После того, как плеер сам отключит винчестер и вентилятор охлаждения, можно вынимать вилку питания из розетки.
Как избежать дискомфорта при пользовании плеером во время ресурсоемкой операции перемещения больших объемов данных на винчестере ?
Предлагаются два варианта решения:
1. установить задаче "mv" в профиле .rtorrent.rc низкий приоритет. Для этого необходимо заменить: system.method.set_key =
event.download.finished,move_complete,"d.set_directory=/tmp/hdd/volumes/HDD1/Complete/;execute=mv,$d.get_base_path=,/tmp/hdd/volumes/HDD1/Complete/" на system.method.set_key =
event.download.finished,move_complete,"d.set_directory=/tmp/hdd/volumes/HDD1/Complete/;execute=nice
-n 10 mv,$d.get_base_path=,/tmp/hdd/volumes/HDD1/Complete/" (сейчас это решение находится в процессе тестирования);
2. использовать встроенный планировщик (scheduler) в профиле .rtorrent.rc для отключения работы rtorrent в выходные и вечером, когда существует вероятность использования плеера по прямому назначению.
прошивка 2901 by titoo. В качестве основного использую ext3 диск (использовал замечание apl). Все папки, с которыми работает rtorrent, находятся на нём же. При скачивании со скоростью, превышающей 1Мб/сек, впрочем, как и при копировании файлов посредством самбы, загрузка процессора колеблется от 42% до 99%, те же цифры atop показывает и по жёсткому диску. Естесственно, работать с плеером в это время невозможно. Есть способы исправить ситуацию? Могли ли какие-то ошибки при разбивке диска и установке optware привести к такому результату?
Думаю что нет. активная работа торрента (любого) требует памяти и ресурса процессора. А они не то чтобы совсем малы, но и далеко не велики. Скорее наличие торрента в этом плеере это просто интересная фича, нежели полнофункциональный тулл. проще ограничить торрент в 500-600К, и не сильно нагружать сеть (CRC процессор считает). Второй вариант -- это ставить NAS и отдельно торренкачалку на этот самый NAS (они есть и netgear, linksys, dlink или прикрутить недокомп с большим диском).
Второй вариант -- сесть и начать оптимизировать самбу под эту конкретную архитектуру.
Девайс подключен к сети по WiFi. Иногда при большой нагрузке на rtorrent WiFi отпадает. Лечу с пульта перезагрузкой или заново ищу WiFi-сеть. Можно ли сделать так, чтобы cron например периодически сам проверял пинг до определённого хоста и при падении сетки перезапускал WiFi?
Идея не моя, но где прочитал, уже не помню... Пропишите во всех трех профилях одинаковые настройки - должно помочь. Если плеер потеряет канал, он начнет пробовать следующий, и т.д. по кругу.
При эксплуатации rtorrent-а появилось пара вопросов: 1. он не показывает комментарий к торренту, при том что uTorrent его показывает нормально. Как выцепить из него коментарий. он ен показывает что торрент на трекере поменялся. Как отслеживать изменения на трекере для rtorrent, потому как некузяво держать еще один на большом брате. 2. Как ему корректно обновить торрент файл? если его положить в каталог сновыми торрентами, то он его покажет как еще один новый торрент, а нафига такое счастье? И есть ли
Если заменить EXT=ext3 на EXT=HDD2 в соответствующем скрипте и настройках rtorrent ничего копировать не надо будет. Все будет видно из браузера. надо не забыть обновить самбу.
tahk: Похоже что можно. Немного пиляния руками -- главное перемонтировать /dev/scsi/host0/bus0/target0/lun0/part4 в /tmp/hdd/volumes/HDD1. пробую сделать это руками/скриптами.
Похоже не работает этот метод - как и у Seregan закачка становится на паузу и файлы не перемещаются. Я вот подумал - а нельзя ли обойтись вовсе без NTFS-раздела? Либо, если морда плейера от него однозначно зависит, сделать его минимального размера и сделать на нем точки монтирования большого ext3 раздела? Тогда вообще не понадобится перебрасывать файлы.
Спасибо! Отличная статья! От себя могу добавить только некоторые теоретические соображения: Есть подозрение, что столь высокую загрузку проца создает не сама команда перемещения, а драйвер NTFS ядра. Т.е. если создать еще один дополнительный раздел EXT3 на внутреннем диске или использовать в качестве устройства назначения внешний EXT3 диск и повторить замеры по данной статье, это можно было бы выяснить с большой достоверностью.
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
