Bugz
FreeNAS
linux
soft
Железо
Новости
Статьи
Фото
Юмор
В сборку FreeNAS 0.69, как оказалось, уже интегрирован консольный торрент-клиент Transmission, а именно его последняя стабильной версия 1.42. При этом приделывать к нему WebGUI уже не требуется, т.к. начиная с версии 1.3 он (Clutch) уже встроен в дистрибутив Transmission. Сам WebGUI достаточно симпатичен, и, к сожалению, примитивен по функциональности - только запуск, остановка, просмотр краткой информации и регулировка общих ограничений по траффику. Сложные действия, типа перепроверки закачанного; выбора файлов, которые надо скачивать; ограничения скорости по отдельным торрентам и т.п. невозможно сделать. Кстати, контекстное меню в Opera не работает, в отличие от FireFox, но пользы от него не много.
По кнопке Inspector открывается правая панель, где можно посмотреть сводную информацию по torrent-файлу
и состояние загрузки/раздачи
В интернете нашлась программа удаленного управления, работающая через тот же открытый порт, что и WebGUI, но предоставляющая гораздо более большой функционал. Называется она transmission remote dotnet и написана, как следует из названия, на .Net Framework. При этом для ее запуска требуется .Net FrameWork 3.5, хотя в моем случае она не запускалась пришлось поставить еще и SP1. В итоге, функциональность связки Transmisson+WebGUI+Remote мне кажется достаточной. Сама программа внешне очень похожа на uTorrent, разные скриншоты ее можно посмотреть на тут, один из них приведен ниже:
Некоторые подводные камни:
- демон transmission может иногда аварийно завершать свою работу. Это может быть вызвано нехваткой свободного места или тем, что owner у файлов и/или папок, куда она пытается обратиться (downloads, config), стоит не transmisson. Для установки правильных аттрибутов достаточно изменить владельца, например, так
- chown -R transmission:transmission /mnt/data/torrents/config
- chown -R transmission:transmission /mnt/data/torrents/downloads
- если скачивать сразу несколько файлов, то возникает фрагментация ФС, из-за чего скорость чтения скачанного может падать до 1Мб/сек. Видимо, это вызвано тем, что transmission по умолчанию не резервирует на файловой системе место для всего файла, а резервирует только область, которая скачивается в тот момент. Для того, чтобы клиент сразу резервировал место на диске, нужно в файл settings.json, который находится в папке с настройками transmission, вставить строку
- "preallocation": 2,
Публикации RSS
3 февраля, 2009 в 13:17
Да, в битторренте лучше сразу на все файлы, которые решил скачать, т.к. много маленьких кусков качается, даже если пиров немного.
А при закачках с серверов лучше резервировать по несколько мегабайт — компромиссный вариант между холостым расходом и фрагментацией.
Только вот какой момент: это всё сурово зависит от того, какая у тебя ФС на /mnt/data… Если с ленивым выделением, то может не помочь. А если что-нибудь типа FAT32, то конечно. Но если ты chown выполняешь отдельно на /mnt/data/torrents/config и /mnt/data/torrents/downloads, то на FAT32 это не похоже :).
Ответить
3 февраля, 2009 at 20:49
Мой предыдущий «сервер» до сих пор работает на Windows XP Home + Azureus, он на NTFS целенаправленно выделяет все место под все файлы сразу и никаких проблем. А тут я был удивлен, что так не сделано. При этом я до сих пор не уверен, что место фактически выделяется, т.к. под NTFS выделение места по времени занимало ровно столько, сколько запись нулевыми байтами всего объема. А тут файл нужного объема уж очень быстро появляется, хотя про UFS+Soft Updates я еще не читал внимательно. Странно другое, что в режиме «по умолчанию», когда выделяется блок от первого до последнего куска файла, на деле скорость очень низкая, винт шумит головками, а системные утилиты показывают в среднем по два фрагмента на файл (сами файлы не менее 1Гб).
Ответить
4 февраля, 2009 at 8:52
Ну остается надеяться, что сама программа, тем более, если она чисто юниксовая, знает и пишет что-нибудь в каждый кластер, либо ещё что-нибудь делает.
Если будет сильно мешать, универсальный способ — FAT32 — никто не отменял. Лучший вариант, чтобы просто файлы хранить, и дефрагментировать можно до идеального состояния. Не знаю, правда, можно ли в *никсах на ходу FAT дефрагментировать, предполагаю, что не очень.
Ответить
4 февраля, 2009 at 10:48
FAT32 не подходит, т.к. со скачиванием, например, образа BD-диска под 40Гб одним файлом будут естественные проблемы, вызванные ограничением на размер файла в ФС.
На счет записи в кластер не похоже, т.к нельзя, имхо, выделить путем записи всего пространства 42Гб за несколько десятков секунд на обычном диске. Значит, либо UFS такая прикольная, либо я чего-то не понимаю.
Ответить
4 февраля, 2009 at 10:53
Ну может у UFS правда можно как-то попросить место выделить с небольшим количеством фрагментов, но не писать при этом. И у других юниксовых FS. Хотя я не слышал.
Ответить
4 февраля, 2009 at 17:21
В общем, нету такого у UFS. Выходит прикол — файл на 40Гб есть, а место на диске не уменьшилось. И в процессе заполнения файла место уменьшается. При этом фрагментация внутри этого файла будет дикая, т.к. торрент качается рандомными кусками, а пишутся они на диск в порядке скачивания… Потом напишу подробнее, интересная «фича» получается.
5 февраля, 2009 at 8:18
Напиши багу на клиент. Пускай хоть нули туда, но пишет, и чтобы последовательно.
На самом деле все орут и топают ногами, что, типа, под *никсами сильной фрагментации не бывает и т.д., а ведь фигня… И тулзов нормальных на эту тему не найдешь.
Грустно, когда лучший совет — «заархивируйте, отформатируйте и разархивируйте назад»…
Оффтоп:
Вообще фундаментальная проблема — если что-то работает чуть лучше, то на это уже все начинают слепо надеяться. Классический пример — «почему Перл работает быстро, а Java тормозит?». Ответ такой же элементарный: потому что на самом деле Перл тормозит ещё сильнее, и у него из-за этого большая часть библиотек написана на C.
5 февраля, 2009 at 17:02
«*никсами сильной фрагментации не бывает и т.д., а ведь фигня…»
При этом системные утилиты показывают среднее число фрагментов на файл около двух, а на практике я ясно слышу, как винт надрывается и по скорости видно.
«заархивируйте, отформатируйте и разархивируйте назад»…
Угу, это мне еще предстоит, если ФС форматировать надумаю.
5 февраля, 2009 at 8:25
1.
правда ждать долгонько придется, вон под линуксом только сейчас начали:
2.
Слушай, а раз та там Multimedia держишь всё равно, может её можно как-нибудь переформатировать, чтобы кластеры по паре метров были, тогда легче будет… Правда даже для коротких файлов inode большие будут, но файлов-то у тебя там будет немного…
Или у UFS никак нельзя?
5 февраля, 2009 at 17:06
Я пока решил временно забить на этот раздел, т.к. там только торренты лежат, скорости для раздачи/просмотра по сети хватает. А вот когда буду раздел для данных делать на другом винте — придется покопаться.
Еще смущает низкая скорость работы самбы и траблы с подключением КПК (хочу, чтобы он с него по USB к интернету был подключен, заряжался и RSS для оффлайн чтения обновлял)
8 августа, 2009 в 17:00
По поводу FreeNAS и transmission. Я, на данный момент, скорее чайник. Поэтому прошу консультации.
Столкнулся со следующей проблемой. Было собрано несколько тестовых вариантов железок под freenas. Чипсет 815, камень — обычно P3-800, памяти — 256, cистемный диск — старенький IDE, диск(и) под данные — 512 Gb WDC через PCI-SATA Sil3112. Во всех случаях, при включении торрент-сервиса, сталкивался со следующим. Если стоит один-два торрента с малым количеством файлов, то более менее всё работает. Если заряжено что-то типа пара сезонов сериалов (два-три торрента с десятком файлов в каждом), то через сутки я обнаруживаю мертвый сервер. При этом точно умирает первым веб-интерфейс, самба может и продолжать работать. Права, как указаны в статье, менял, раздел подкачки подключал. Сейчас тестовая железка работает на избыточной конфигурации (P4-3000, RAM 512, чипсет 945). Никаких проблем не вижу. Но использовать такой процессор в домашнем файл-сервере… как-то жалко.
Хочу еще раз попробовать старую конфигурацию, но уже с памятью в 512. Есть совет?
Ответить
Vasiliy Reply:
8 августа, 2009 at 21:50
А веб-интерфейс умирает у FreeNAS или у Transmission? Если у Transmission, то в логах freenas’a будет указан код ошибки, по которому можно понять, что ему не понравилось. Также могут быть различные аппаратные проблемы, например с жестким диском. По сути, если FreeNAS отзывается, то можно по SSH зайти в консоль и посмотреть логи ОС, там точно что-нибудь должно быть.
Ответить
9 августа, 2009 в 14:10
Сложный вопрос. Обычно я застаю картину, обоих мертвых веб-интерфейсов. Пару раз интерфейс фреенаса пытался еще жить. То есть выплевывал начало страницы и пытался что-то дальше отдать. Такое ощущение, что по байту в минуту.
Про SSH спасибо, не подумал. Попробую.
Ответить
13 августа, 2009 в 16:42
После перезагрузки сервера FreeNas пропадают торренты. С чем это может быть связано?
Ответить
Vasiliy Reply:
13 августа, 2009 at 21:00
Вероятно, Transmission настроен так, что файлы конфигурации хранятся на отдельном диске, который монтируется при загрузке и в момент запуска демона еще не подключен. В таком случае рекомендуется перенастроить так, чтобы все файлы конфигурации и .torrent-файлы лежали в папке на системном диске.
Вот тут похожую проблему решили:
Ответить
Omisteria Reply:
17 августа, 2010 at 18:03
Обратите внимание на свап раздел, он у вас присутсвует?
Ответить
Vasiliy Reply:
17 августа, 2010 at 18:15
Думаю, к данной проблеме у пользователя swap отношения не имеет.
Хотя если мало ОЗУ, данные находятся в свопе (вопрос только как они туда попали), а перезагрузка была неожиданной, то всякое могло произойти, разумеется.
Ответить
20 марта, 2010 в 23:31
поставьте решетку перед chown, так будет корректнее.
Ответить
Vasiliy Reply:
22 марта, 2010 at 23:13
Имхо, это и так очевидно. 🙂
Ответить
24 марта, 2010 в 23:39
это мне очевидно %) а вот неопытному линуксоиду….
Ответить
11 марта, 2011 в 19:45
Very informative post. Thanks for taking the time to share your view with us.
Ответить