Задумался.

Торрент-кеш по содержимому напоминает "мочалку". Состоит в основном из сплошных нулей. У меня - занимает около 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 например.