Задумался.

Торрент-кеш по содержимому напоминает "мочалку". Состоит в основном из сплошных нулей. У меня - занимает около 100 Гиг, но реально полезной информации там едва-ли на 10-24 Gb. Когда качал под WinXP, то ставил атрибут сжатия на всю папку, но это ощутимо било по производительности, да и диск работал как-то напряжно. А вот если-бы хранить блоки данных в файле как-то более оптимально, ну например при закачке образа выделять 4.7 "виртуальных" гигов. А физически аллоцировать блоки по необходимости - то было-бы очень даже неплохо.

Моя жадность не имеет предела. +Люблю оптимизировать...

Модератор: Тема перенесена из форума "Просто треп".

Я имел в виду этот каталог:

Допустим я добавил 20 torrent-ов в загрузку. Каждый - по 4.7Гб. Сидирование слабое. Где-то по 1-2 seede-rs на каждую загрузку. Включаю в очередь все 20 штук с одинаковым приоритетом. Соотв. большой объём диска (около 100 Гб) будет вначале выделен впустую. Этот объём в начале будет заполнен нулями. Но по мере скачивания я буду сбрасывать законченые закачки на DVD и т.д.

Ограничивать себя очередью закачек со строгой последовательносью как-то не хочется ибо грустно и нерационально с точки зрения трафа.

P.S. Я привёл скрин для Win чтобы было понятно, но на самом деле меня интересует настройка ФС для торрентов под Linux т.к. планирую раб. станцию с линуксами оставлять на закачку на долгое время.

Флажок "Распределять место сразу" у меня отключен по умолчанию. Но это не помогает. Ведь порядок скачивания chunk-ов случайный и если допустим доступен 1Мб chunk #XXXX который находится в конце 4.7Гб файла то по протоколу торрент-клиента он форсирует аллокацию полной длины файла и прописывает туда 1Мб данных. Промежуток между chunk-ом #0000 и #XXXX будет балластом.

Всё равно харда не хватает. Вот скоро начну качать рипы с Blu-ray - снова надо будет думать где чего разместить. А политика - доплати еще 50$ и купи в два раза больше мне не особо интересна. Я ведь расчитываю на деньги а не на гигабайты.

Да. Я думал об этом. Помнится когда-то искал нечто подобное на sysinternals но не нашёл. Чуть позже поставлю VisualC++ и соберу утилиту типа makesparse.

+Вопрос по Линуксу тоже остаётся актуальным.

Нагуглил файловые системы, с поддержкой transparent compression. Btrfs,NTFS,Reiser4,JFS (on AIX),NSS,NWFS,Fossil,ZFS. Из этих всех реально использовал только NTFS, и старую версию Reiser. Это - не альтернатива sparse но всё-таки попробую чего-нибудь применить.

(по информации с wiki).

mriadusЯ так понимаю, в идеале ты хочешь, чтобы в этой файловой системе всё было устроено примерно так: один блок торрента - один файл в этой файловой системе
весь фильм - папка в этой файловой системе) Ну например)

Да. И один блок торрента вовсе не обязательно не должен быть совпадающим с размером блока ФС. Экономия будет в любом случае. Насколько я помню torrent оперирует chunk-ами 64, 128, 256 Kb и выше.

Считывание целого 2-гигового файла из этой файловой системы, это собирание кусков друг за другом из опр. папки в опр. порядке.
На самом деле ФС так и поступает на уровне MFT таблиц. Ведь блоки одного на диске лежат в виде частично-упорядоченных цепочек.

Просто (я для себя) разработал концепцию файловой системы которая решает проблему sparsed-файлов, и при этом не требует супер-вычислительных ресурсов, и является концептуально-простой. Её можно реализовать поверх ext2 например.

Такой подход оправдывал, когда я качал сериалы. Ставишь целый сезон в закачку. Выставляешь приоритеты так, чтобы серии качались в опр. порядке 01, 02... и по мере завершения - смотришь а потом либо стираешь нахер либо на DVD.

mriadusА я наверное никакие докторы-хаусы качать не буду, пока не наступит время, когда можно будет за 40 миллисекунд получать любую точку любой серии для ознакомления) Качаю только получателей оскара раз в месяц)
А смысл? Если ждать, тогда зачем вообще сериалы нужны.

P.S. А где вообще получаете ссылки? На каком трекере?

+1

Я-ж об этом и толкую. Мне безразлично что пишет торрент-клиент в файл. Просто я хочу оптимально использовать дырки в файлах которые он оставляет после аллокации.

Установка флажка bt.compact_allocation не помогла. Клиент uTorrent по прежнему выделяет 100% объём файла, но дополнительно создаёт файл ~uTorrentPartFile_********.dat для каждого .torrent-а. В чём смысл этого файла я не понял, но могу предположить что там должнен лежать mapping логических chunks в физические.

uTorrent у меня обновлён до самой последней версии. Кто-нибудь, проведите эксперимент пожалуйста, чтобы проверить как выделяется место скажем... на 4.7 Гб образе.

Условия не те. Вы выбрали один торрент c целой пачкой файлов.

Попробуйте один образ. Например вот http://torrent.fedoraproject.org/torrents//Fedora-12-i386-DVD.torrent.

Хрен его знает. Я раньше качал Azureus-ом, но когда увидел, что там с соглашением об использовании - нечито я его прибил и поставил uTorrent.

Хотя, как мне кажется с лягушкой такой проблемы не было.

Может с размером chunk-а связано? Посмотри плиз чему равно это значение у сериала "How it's made?" и у того образа Fedorа, который я указал.

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