Фев 03

В сборку FreeNAS 0.69, как оказалось, уже интегрирован консольный торрент-клиент Transmission, а именно его последняя стабильной версия 1.42. При этом приделывать к нему WebGUI уже не требуется, т.к. начиная с версии 1.3 он (Clutch) уже встроен в дистрибутив Transmission. Сам WebGUI достаточно симпатичен, и, к сожалению, примитивен по функциональности - только запуск, остановка, просмотр краткой информации и регулировка общих ограничений по траффику. Сложные действия, типа перепроверки закачанного; выбора файлов, которые надо скачивать; ограничения скорости по отдельным торрентам и т.п. невозможно сделать.  Кстати, контекстное меню в Opera не работает, в отличие от FireFox, но пользы от него не много.

FreeNAS - Transmission - WebGUI

По кнопке Inspector открывается правая панель, где можно посмотреть сводную информацию по torrent-файлу

FreeNAS - Transmission - WebGUI - Inspector - Info

и состояние загрузки/раздачи

FreeNAS - Transmission - WebGUI - Inspector - Activity

В интернете нашлась программа удаленного управления, работающая через тот же открытый порт, что и WebGUI, но предоставляющая гораздо более большой функционал. Называется она transmission remote dotnet и написана, как следует из названия, на .Net Framework. При этом для ее запуска требуется .Net FrameWork 3.5, хотя в моем случае она не запускалась пришлось поставить еще и SP1. В итоге, функциональность связки Transmisson+WebGUI+Remote мне кажется достаточной. Сама программа внешне очень похожа на uTorrent, разные скриншоты ее можно посмотреть на тут, один из них приведен ниже:

Некоторые подводные камни:

  1. демон transmission может иногда аварийно завершать свою работу. Это может быть вызвано нехваткой свободного места или тем, что owner у файлов и/или папок, куда она пытается обратиться (downloads, config), стоит не transmisson. Для установки правильных аттрибутов достаточно изменить владельца, например, так
    1. chown -R transmission:transmission /mnt/data/torrents/config
    1. chown -R transmission:transmission /mnt/data/torrents/downloads

  2. если скачивать сразу несколько файлов, то возникает фрагментация ФС, из-за чего скорость чтения скачанного может падать до 1Мб/сек.  Видимо, это вызвано тем, что transmission по умолчанию не резервирует на файловой системе место для всего файла, а резервирует только область, которая скачивается в тот момент. Для того, чтобы клиент сразу резервировал место на диске, нужно в файл settings.json, который находится в папке с настройками transmission, вставить строку
    1. "preallocation": 2,

Google Bookmarks Digg Reddit del.icio.us Ma.gnolia Technorati Slashdot Yahoo My Web News2.ru БобрДобр.ru RUmarkz Ваау! Memori.ru rucity.com МоёМесто.ru Mister Wong

Автор: Vasiliy \\ Метки: , , ,


22 комментария к “Сборка Mini-ITX файл-сервера. Часть 4. Torrent-клиент Transmission”

  1. 1. dluciv пишет:

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

    А при закачках с серверов лучше резервировать по несколько мегабайт — компромиссный вариант между холостым расходом и фрагментацией.

    Только вот какой момент: это всё сурово зависит от того, какая у тебя ФС на /mnt/data… Если с ленивым выделением, то может не помочь. А если что-нибудь типа FAT32, то конечно. Но если ты chown выполняешь отдельно на /mnt/data/torrents/config и /mnt/data/torrents/downloads, то на FAT32 это не похоже :).

    Ответить

    vasiliy Reply:

    Мой предыдущий «сервер» до сих пор работает на Windows XP Home + Azureus, он на NTFS целенаправленно выделяет все место под все файлы сразу и никаких проблем. А тут я был удивлен, что так не сделано. При этом я до сих пор не уверен, что место фактически выделяется, т.к. под NTFS выделение места по времени занимало ровно столько, сколько запись нулевыми байтами всего объема. А тут файл нужного объема уж очень быстро появляется, хотя про UFS+Soft Updates я еще не читал внимательно. Странно другое, что в режиме «по умолчанию», когда выделяется блок от первого до последнего куска файла, на деле скорость очень низкая, винт шумит головками, а системные утилиты показывают в среднем по два фрагмента на файл (сами файлы не менее 1Гб).

    Ответить

    dluciv Reply:

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

    Если будет сильно мешать, универсальный способ — FAT32 — никто не отменял. Лучший вариант, чтобы просто файлы хранить, и дефрагментировать можно до идеального состояния. Не знаю, правда, можно ли в *никсах на ходу FAT дефрагментировать, предполагаю, что не очень.

    Ответить

    vasiliy Reply:

    FAT32 не подходит, т.к. со скачиванием, например, образа BD-диска под 40Гб одним файлом будут естественные проблемы, вызванные ограничением на размер файла в ФС.
    На счет записи в кластер не похоже, т.к нельзя, имхо, выделить путем записи всего пространства 42Гб за несколько десятков секунд на обычном диске. Значит, либо UFS такая прикольная, либо я чего-то не понимаю.

    Ответить

    dluciv Reply:

    Ну может у UFS правда можно как-то попросить место выделить с небольшим количеством фрагментов, но не писать при этом. И у других юниксовых FS. Хотя я не слышал.

    Ответить

    vasiliy Reply:

    В общем, нету такого у UFS. Выходит прикол — файл на 40Гб есть, а место на диске не уменьшилось. И в процессе заполнения файла место уменьшается. При этом фрагментация внутри этого файла будет дикая, т.к. торрент качается рандомными кусками, а пишутся они на диск в порядке скачивания… Потом напишу подробнее, интересная «фича» получается.

    dluciv Reply:

    Напиши багу на клиент. Пускай хоть нули туда, но пишет, и чтобы последовательно.

    На самом деле все орут и топают ногами, что, типа, под *никсами сильной фрагментации не бывает и т.д., а ведь фигня… И тулзов нормальных на эту тему не найдешь.

    Грустно, когда лучший совет — «заархивируйте, отформатируйте и разархивируйте назад»…

    Оффтоп:
    Вообще фундаментальная проблема — если что-то работает чуть лучше, то на это уже все начинают слепо надеяться. Классический пример — «почему Перл работает быстро, а Java тормозит?». Ответ такой же элементарный: потому что на самом деле Перл тормозит ещё сильнее, и у него из-за этого большая часть библиотек написана на C.

    vasiliy Reply:

    «*никсами сильной фрагментации не бывает и т.д., а ведь фигня…»
    При этом системные утилиты показывают среднее число фрагментов на файл около двух, а на практике я ясно слышу, как винт надрывается и по скорости видно.

    «заархивируйте, отформатируйте и разархивируйте назад»…
    Угу, это мне еще предстоит, если ФС форматировать надумаю.

    dluciv Reply:

    1. http://en.wikipedia.org/wiki/ExFAT
    правда ждать долгонько придется, вон под линуксом только сейчас начали:
    http://www.linux.org.ru/view-message.jsp?msgid=3468437

    2.

    Слушай, а раз та там Multimedia держишь всё равно, может её можно как-нибудь переформатировать, чтобы кластеры по паре метров были, тогда легче будет… Правда даже для коротких файлов inode большие будут, но файлов-то у тебя там будет немного…

    Или у UFS никак нельзя?

    vasiliy Reply:

    Я пока решил временно забить на этот раздел, т.к. там только торренты лежат, скорости для раздачи/просмотра по сети хватает. А вот когда буду раздел для данных делать на другом винте — придется покопаться.
    Еще смущает низкая скорость работы самбы и траблы с подключением КПК (хочу, чтобы он с него по USB к интернету был подключен, заряжался и RSS для оффлайн чтения обновлял)

  2. 2. Влад пишет:

    По поводу FreeNAS и transmission. Я, на данный момент, скорее чайник. Поэтому прошу консультации.
    Столкнулся со следующей проблемой. Было собрано несколько тестовых вариантов железок под freenas. Чипсет 815, камень — обычно P3-800, памяти — 256, cистемный диск — старенький IDE, диск(и) под данные — 512 Gb WDC через PCI-SATA Sil3112. Во всех случаях, при включении торрент-сервиса, сталкивался со следующим. Если стоит один-два торрента с малым количеством файлов, то более менее всё работает. Если заряжено что-то типа пара сезонов сериалов (два-три торрента с десятком файлов в каждом), то через сутки я обнаруживаю мертвый сервер. При этом точно умирает первым веб-интерфейс, самба может и продолжать работать. Права, как указаны в статье, менял, раздел подкачки подключал. Сейчас тестовая железка работает на избыточной конфигурации (P4-3000, RAM 512, чипсет 945). Никаких проблем не вижу. Но использовать такой процессор в домашнем файл-сервере… как-то жалко.
    Хочу еще раз попробовать старую конфигурацию, но уже с памятью в 512. Есть совет?

    Ответить

    Vasiliy Reply:

    А веб-интерфейс умирает у FreeNAS или у Transmission? Если у Transmission, то в логах freenas’a будет указан код ошибки, по которому можно понять, что ему не понравилось. Также могут быть различные аппаратные проблемы, например с жестким диском. По сути, если FreeNAS отзывается, то можно по SSH зайти в консоль и посмотреть логи ОС, там точно что-нибудь должно быть.

    Ответить

  3. 3. Влад пишет:

    Сложный вопрос. Обычно я застаю картину, обоих мертвых веб-интерфейсов. Пару раз интерфейс фреенаса пытался еще жить. То есть выплевывал начало страницы и пытался что-то дальше отдать. Такое ощущение, что по байту в минуту.
    Про SSH спасибо, не подумал. Попробую.

    Ответить

  4. 4. RuslanBZ пишет:

    После перезагрузки сервера FreeNas пропадают торренты. С чем это может быть связано?

    Ответить

    Vasiliy Reply:

    Вероятно, Transmission настроен так, что файлы конфигурации хранятся на отдельном диске, который монтируется при загрузке и в момент запуска демона еще не подключен. В таком случае рекомендуется перенастроить так, чтобы все файлы конфигурации и .torrent-файлы лежали в папке на системном диске.
    Вот тут похожую проблему решили:
    http://sourceforge.net/apps/phpbb/freenas/viewtopic.php?f=60&t=3242

    Ответить

    Omisteria Reply:

    Обратите внимание на свап раздел, он у вас присутсвует?

    Ответить

    Vasiliy Reply:

    Думаю, к данной проблеме у пользователя swap отношения не имеет.
    Хотя если мало ОЗУ, данные находятся в свопе (вопрос только как они туда попали), а перезагрузка была неожиданной, то всякое могло произойти, разумеется.

    Ответить

  5. 5. Karinuss пишет:

    поставьте решетку перед chown, так будет корректнее.

    Ответить

    Vasiliy Reply:

    Имхо, это и так очевидно. 🙂

    Ответить

  6. 6. Karinuss пишет:

    это мне очевидно %) а вот неопытному линуксоиду….

    Ответить

  7. 7. Alveo пишет:

    Very informative post. Thanks for taking the time to share your view with us.

    Ответить

Оставьте комментарий или два

SEO Powered by Platinum SEO from Techblissonline