меньше фрагментации - быстрее торрент

Обратитесь в тех. поддержку своего провайдера. Вызовите компьютерного специалиста, он вам все расскажет и покажет.

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

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

что мешает скачать 10 таких кусков и последовательно их записать?

Недоделанность твоего торрент-клиента? Неумение его настроить?

Продолжение мысли: у торрента размером 1,5gb размер так называемых кусочков ~2mb, что мешает скачать 10 таких кусков и последовательно их записать? Как вам идейка, а?

торрент качает не то, что хочется, а то что качается. Потому качает намного быстрее. И даже на 100мбпс интернете скорости HDD хватает.

Используй

1. преаллокацию на весь файл.

2. после закачки переноси в другой раздел.

И то и другое есть в настройках клиента.

А что за HDD у тебя, который не может записывать ~11.5Mb/s рандомом?
Чтоб я такие не покупал, например.

Свои 100mbit забить тупо не получается!

Может их просто на самом деле нет?

Продолжение мысли: у торрента размером 1,5gb размер так называемых кусочков ~2mb, что мешает скачать 10 таких кусков и последовательно их записать? Как вам идейка, а?

Ничто не мешает кроме того, что (в зависимости от того, что точно ты имел в виду) так и делается или это попросту не нужно.

Что за жёсткие диски, что за файловая система, что за торрент-клиент? У меня вот уже год на 500гб жёсткий диск (самый обычный сигейтовский) с XFS качаются (и что немаловажно в этом случае, удаляются, и качаются новые) торренты как раз со скоростью 100 мбит/с. До этого тоже качались, но скорость (в смысле, даваемая провайдером) была ниже. При этом они могут не только качаться, полностью загружая канал, но я могу ещё туда же что-то переносить (чтобы раздавать) и с того же жёсткого диска смотреть кино. Даже намёка не то, чтобы упиралось в жёстки диск, нет. В качестве торрент-клиента использую Deluge. Либо у тебя какие-то особые hdd, либо какая-то очень особая файловая система, либо 100мбит/с провайдер даёт только на бумажке. Если дело действительно в фрагментации, то тут или надо ФС сменить (в случае с торрентами и достаточно большими файлами хорошо себя показывает XFS), либо просто стараться не доводить до полного забивания винта, оставляя всегда хотя бы 10% свободного места, тогда проблемы не будет. Либо нужно поставить торрент-клиент (а не то, что вместо него сейчас используется) и включить в нём преаллокацию.

Реально при ~150мбит/с io смотришь хотя бы 720p видео без проблем? У меня подлагивает в зависимости от того что раздаётся и скольким пирам и если кэши не используются, затык секунд на 10 при перемотке видео может случится. xfs настолько лучше ext4 для файло?

А что за HDD у тебя, который не может записывать ~11.5Mb/s рандомом? Чтоб я такие не покупал, например.

с этим справляется даже давно снятый с производства HDD-IDE 120Гб. Ты даже его только на барахолке можешь купить.

Реально при ~150мбит/с io смотришь хотя бы 720p видео без проблем? У меня подлагивает в зависимости от того что раздаётся и скольким пирам и если кэши не используются, затык секунд на 10 при перемотке видео может случится. xfs настолько лучше ext4 для файло?

при чём тут перемотка?

Реально без проблем смотрю. Сидирую 500–800 торрентов (сейчас 754) с Deluge, параллельно что-то качается со скоростью в 11мбайт/c, и я с этого диска смотрю фильм в 1080p (тут больне не от разрешения, а от битрейта, конечно, я имею в виду обычные рипы в пределах 10гб). С ext4 не пробовал (когда-то была ext3, но тогда и скоростей таких не было), но с XFS и Deluge в качестве клиента у меня никогда не было с этим проблем. Как-то даже и не думал, что они могут быть. Да, помимо использования XFS я ещё не забиваю диск полностью, оставляю 40–50 Гб свободными всегда.

Это называется отзывчивость io под нагрузкой в нормальной ситуации, а не когда iowait 1500%. Естественно, при просмотре локальных файлов кэш не используется.

Ясно, спасибо. Возможно проблема ещё и в том, что у меня трансмиссия, при активной раздаче ~100mbit периодически испытываю проблемы на видео с высоким битрейтом, если ещё и скачивается что-то, они становятся слишком очевидны.

Я знаю, как это называется. Твоя (и ТСа) проблема видимо в том, что нужно читать/писать файлы далеко друг от друга. Это не совсем «фрагментация», т.к. файлы могут быть одним куском, а тормоза всё равно будут. Очевидно ты не только смотришь кино, но и качаешь пару файлов сразу. Естественно HDD с этим принципиально не справляется. Там _одна_ головка, он одновременно один цилиндр умеет.

И да, скорость тут не причём, с amuled всё намного хуже, и на ADSL тоже(со скоростью 512/512 кбитпс). Там активных участников больше.

RAID, RAMFS!

При большей фрагментации файла, время random-access меньше.

+ ext4 не ntfs, практически не фрагментируется и не испытывает заметного падения падения скорости от фрагментации, так что да, проблема явно не в этом.

IBM DTLA

ext4 не ntfs, практически не фрагментируется и не испытывает заметного падения падения скорости от фрагментации

да, с этим согласен. Эта проблема свойственна только NTFS.

Вообще то есть, например у kTorrent сеть опция предварительного резервирования свободного пространства, то есть создаётся пустой файл на нужный объём, а потом в него происходит запись. Так же у многих торрент-клиентов есть функция последовательной загрузки частей файлов.

А что за HDD у тебя, который не может записывать ~11.5Mb/s рандомом?

У меня на WD Red иногда падает до 4..5Мб/с на ext4 :) Когда совсем рэндом.

Прям в рейде? Или зачем Red без рейда?
У меня на WD Black всё ок, брат жив.

Или зачем Red без рейда?

Почему нет?

У меня на WD Black всё ок, брат жив

И у меня Red жив. И?

Почему нет?

Потому-что есть более дешевый Green, который почти тот же Red, но без плюшек, актуальных в RAID.

И у меня Red жив. И?

А брат?

получается, но не всегда, а вот JDownloader подзавязку часто 100Мбит забивает

Реально без проблем смотрю. Сидирую 500–800 торрентов (сейчас 754) с Deluge, параллельно что-то качается со скоростью в 11мбайт/c, и я с этого диска смотрю фильм в 1080p (тут больне не от разрешения, а от битрейта, конечно, я имею в виду обычные рипы в пределах 10гб). С ext4 не пробовал

с ext3/ext4 тоже нет проблем. У ТСа проблема совсем в другом.

JDownloader подзавязку часто 100Мбит забивает

JDownloader requires Java Runtime Enviroment

А еще грузит проц в потолок и съедает всю доступную память?

то есть создаётся пустой файл на нужный объём

шибко умная ФС может и не сделать файл. И не делает его IRL, это видно по выводу ls/du. (файлы в 700Мб занимают 70Мб).

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

эта функция вредит всем личерам/сидам, а вот тебе реального профита НЕ приносит(разве-что можно предпросмотр юзать, но для этого хватит и первых 10Мб).

никогда такого не замечал, даже под Вендой

шибко умная ФС

может хватит так бравировать незнанием матчасти?) это зависит целиком от клиентского ПО.

может хватит так бравировать незнанием матчасти?) это зависит целиком от клиентского ПО.

ну попробуй создать файл, и записать туда Over9000K нулей. Да, всё будет зависеть от ПО тоже. Но и от ФС тоже.

~/opt $ rm 11111
~/opt $ dd if=/dev/zero of=11111 bs=100M count=10
10+0 records in
10+0 records out
1048576000 bytes (1.0 GB) copied, 62.742 s, 16.7 MB/s
~/opt $ du -h --apparent-size 11111 
1000M	11111
1000M	total
~/opt $ du -h 11111 
1001M	11111
1001M	total
~/opt $ dd if=/dev/zero of=ololo bs=1 count=0 seek=16383G
0+0 records in
0+0 records out
0 bytes (0 B) copied, 6.5622e-05 s, 0.0 kB/s
~/opt $ du -h --apparent-size ololo 
16T	ololo
16T	total
~/opt $ du -h ololo 
0	ololo
0	total

клиент может создавать файл по-разному, sparse либо с fallocate.

dd

а теперь попробуй cp.

By default, sparse SOURCE files are detected by a crude heuristic and the corresponding DEST file is made sparse as well. That is the behavior selected by --sparse=auto. Specify --sparse=always to create a sparse DEST file whenever the SOURCE file contains a long enough sequence of zero bytes. Use --sparse=never to inhibit creation of sparse files.

клиент может создавать файл по-разному, sparse либо с fallocate.

ну вот оно часто создаётся sparse, потому что это не ведёт к сильной фрагментации на ext3/ext4.

Потому-что есть более дешевый Green, который почти тот же Red

Ок, с Вами всё понятно.

cp - прикладное ПО, и разработчики всяких качалок тоже в курсе об этой фишке, и создаётся оно таким не само.

Возможно проблема ещё и в том, что у меня трансмиссия, при активной раздаче ~100mbit периодически испытываю проблемы на видео с высоким битрейтом

Лично у меня нет такой проблемы при похожих условиях.
Но у меня аплинк сотня, а по дому от роутера до моего компа и сервера гигабит, на остальные девайсы - до 11ac.
У тебя io scheduler какой? CFQ?

что мешает скачать 10 таких кусков и последовательно их записать? Как вам идейка, а?

Идейка отличная. Беда этой идейки в том, что это уже реализовано (libtorrent-rasterbar), библиотека дополнительно буферизует запись.

факт в том, что многие качалки создают разряжённые файлы. И это не тормозит.

CFQ, самая очевидная проблема может быть в том, что часть файлов доступны только через юзерспейсный ntfs3g (правда, когда виноват именно он, это обычно видно по загрузке ядер и высокому iowait), хотя наблюдал такое поведение и с большими файлами на ext4.

Попробуй либо настроить CFQ, либо протестировать BFQ или deadline.

что мешает скачать 10 таких кусков и последовательно их записать

У меня приблизительно так и делает. Скидывает на хард каждые 300-500 мегов.

настроить CFQ

хм, как? сейчас

group_idle 8
slice_idle 8

// ещё замечал, с использованием ionice затыков не случается даже при копировании чего-нибудь в фоне в пару потоков…

Попробуйте это https://wiki.archlinux.org/index.php/sysctl#Small_periodic_system_freezes

~ $ zgrep IO_DELAY /proc/config.gz 
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
CONFIG_IO_DELAY_NONE=y
CONFIG_DEFAULT_IO_DELAY_TYPE=3
~ $ 

что выбрать? 0X80 не лучше, насколько я помню, а остальные вообще какая-то экзотика.

Не, это не трогайте. Только sysctl-параметры поменяйте.

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

man zfs