LINUX.ORG.RU

Что торрент делает с дисками в первые минуты своей работы?

 , , , ,


0

2

Здарова, господа красноглазики!

Если берём раздачу на 30+ гигов (относительно большую), то получаем бруталити, фаталити или френдшип по отношению к диску.

Я заметил три варианта развития событий:

  1. SMR-HDD. Запускаем. Ловим подвисон на минуту-две (чем больше раздача, тем больше время лага), затем начинается загрузка. Скорость может плавать, но это не точно.
  2. SSD 1: Запускаем. Ловим подвисан на 1-2 секунды, затем стабильно маленькая скорость (200-300 kb 5-10 cекунд), затем плавное увеличение скорости и всё ровно, без падений.
  3. SSD 2: Запускаем. Скорость сразу нормализуется до средней по больнице (6-8 мегабайт при 100 мегабитах) и держится так до конца загрузки. То, что доктор прописал.

Собственно, сабж. Поясните, что и почему не вывозят варианты под номерами 1 и 2 с технической точки зрения.

Да, мне уже писали про многолетний баг ввода-вывода. Для smr помогает понижение «асинхронных потоков ввода вывода» в настройках самого клиента.

то получаем бруталити, фаталити или френдшип по отношению к диску.

Зависит от пиров, файлов в торренте, преаллокации и файловой системы.

ALiEN175
()

Еще во времена одно-двухъядерников жесткие диски легко такое вывозили. И 100 мегабит это более 10 мегабайт стабильно должно быть. Тебя скорее всего провайдер глушит. Знаю одного провайдера что отдельный тариф для полноценной работы интернета запилил, чтобы более двух потоков могли работать. Так что либо у тебя программа говно, хотя Transmission работает исправно, либо как вариант ты хреново разогнал память, если со звуком тоже заминки в начале видео случаются. Тогда копать в сторону напряжений - их может не хватать. Если процессору не хватает там тоже заминки могут быть, хотя система обычно не падает. Так что от криворукости тут нет защиты - как настроил так все и работает.

anonymous
()

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

With ★☆☆
()

Торрент клиент обычно при старте торрента делает ftruncate(2), чтобы получился разреженный файл нужного размера, а потом fallocate(2) для выделения дискового пространства на файл. Чтобы потом при записи блоков в файл не оказалось, что дискового пространства не хватает. А дальше всё зависит от файловой системы. Обычно эти операции не требуют записи нулей на всё аллоцированное пространство, нужна только запись метаданных файловой системы. Если файлов в торренте много, может файловая система приседает на записи метаданных?

iliyap ★★★★★
()
Ответ на: комментарий от Shadow

Когда у меня в Windows 11 без остановки на скорости около 100 Мб/с писался из-за какого-то кривого обновления суперзащищённый секьюрити-лог, тоже всё подтормаживало. Но почему-то мне даже в голову не приходило назвать это багом подсистемы I/O. Потому что о каких багах речь, если у тебя полоса дискового ввода/вывода легитимно съедена (это был NVME SSD, к слову)? 🤷

12309, насколько я помню, был о том, что от сатурации I/O в каком-то изолированном месте (типа USB-флэшки) наблюдается снижение производительности в других местах. И с тех пор линаксоеды не перестают ныть про этот баг, даже не включая мозг.

anonymous
()

Поясните, что и почему не вывозят варианты под номерами 1

Hdd с черепицей охреневает от аллокации 30Gb разом.

2

Так ты не указал модели и прошивки ssd.

Dimez ★★★★★
()

aria2c, например, по дефолту выделяет весь объем нужный заранее. Но это поведение зависит от ФС еще.

Вроде, эта опция есть во всех популярных клиентах и она по-умолчанию выключена. У меня qbittorrent.

Зависит от пиров, файлов в торренте, преаллокации и файловой системы.

Любая большая раздача. Хоть фильмы, хоть игры, хоть архивы. Поведение плюс-минус одинаковое. Может, NTFS вставляет палки в колеса.

Посмотри gstatiotop, вероятно там будет разгадка.

23.07.2025 12:44:00
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,1%    0,0%    0,4%   12,1%    0,0%   87,4%

     r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz Device
  109,00    109,0M     0,00   0,0%   18,39     1,0M sdc

     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     f/s f_await  aqu-sz  %util Device
    0,00    0,00    2,00  99,8% sdc


23.07.2025 12:44:01
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,0%    0,0%    0,3%   12,2%    0,0%   87,5%

     r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz Device
  109,00    109,0M     0,00   0,0%   18,29     1,0M sdc

     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     f/s f_await  aqu-sz  %util Device
    0,00    0,00    1,99  99,3% sdc


23.07.2025 12:44:02
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,0%    0,0%    0,5%   12,0%    0,0%   87,5%

     r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz Device
  109,00    109,0M     0,00   0,0%   18,31     1,0M sdc

     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     f/s f_await  aqu-sz  %util Device
    0,00    0,00    2,00  99,4% sdc


23.07.2025 12:44:03
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,0%    0,0%    0,3%   12,1%    0,0%   87,6%

     r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz Device
  109,00    109,0M     0,00   0,0%   18,37     1,0M sdc

     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     f/s f_await  aqu-sz  %util Device
    0,00    0,00    2,00  99,9% sdc


23.07.2025 12:44:04
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,1%    0,0%    0,6%   11,5%    0,0%   87,8%

     r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz Device
  109,00    109,0M     0,00   0,0%   18,39     1,0M sdc

     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     f/s f_await  aqu-sz  %util Device
    0,00    0,00    2,00 100,0% sdc


23.07.2025 12:44:05
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,0%    0,0%    0,4%   11,7%    0,0%   87,9%

     r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz Device
  109,00    109,0M     0,00   0,0%   18,28     1,0M sdc

     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz Device
    0,00      0,0k     0,00   0,0%    0,00     0,0k sdc

     f/s f_await  aqu-sz  %util Device
    0,00    0,00    1,99  99,8% sdc 

SMR на 4 TB. 14 гигов раздача. Тупил в таком режиме минуты 2. Забрал за команию и клиент.

Еще во времена одно-двухъядерников жесткие диски легко такое вывозили. И 100 мегабит это более 10 мегабайт стабильно должно быть. Тебя скорее всего провайдер глушит.

На винде 2 терабайтный smr работал (давно проверял). Иногда уходил под сотку, но не тупил.

Скорости в среднем написал. Может быть порядка 10.8 в торрентах.

ssd1 скорее всего какой-нибудь шрот на qlc nand, без dram кэша, который охреневает от попытки записать в него 30Гб нулей разом. Это нормальное поведение для таких ssd.

Все на TLC без dram. Видимо, контроллер решает.

Возьми и посмотри. blktrace, blkparse А вообще торрент это протокол. реализации в клиенте сильно разные

Попробую разобраться. Тупят и ktorrent и qbittorrent. Точней диски, конечно же.

12309? Это баг в головах пишущих про него.

Может. По крайней мере что-то на тему у меня встречается только в тоорент-клиентах. В остальном, всё в норме.

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

Хм. Резервация и галочка «Предвыделять место на диске для всех файлов» делают разные вещи?

Торрент клиент обычно при старте торрента делает ftruncate(2), чтобы получился разреженный файл нужного размера, а потом fallocate(2) для выделения дискового пространства на файл. Чтобы потом при записи блоков в файл не оказалось, что дискового пространства не хватает. А дальше всё зависит от файловой системы. Обычно эти операции не требуют записи нулей на всё аллоцированное пространство, нужна только запись метаданных файловой системы. Если файлов в торренте много, может файловая система приседает на записи метаданных?

Вроде как производительность фс полностью увязана с производительностью диска? То есть даже если проседает запись метаданных, то, вероятно, из-за того, что железо диска не вывозит? Пробовал две: NTFS и EXT4.

Hdd с черепицей охреневает от аллокации 30Gb разом.

Проверю на днях CMR-ные.

Если я поставлю галку предвыделения места в клиенте, это поможет снизить градус перегруза? Если выйдет настроить под smr, то можно брать и qlc под файлопомойку.

Так ты не указал модели и прошивки ssd.

Вот с этим сложней. Винды нет: vlo только там.

  • Apacer AS350 128GB [mv1120 Micron 176L(B47R) TLC] EXT4. Ок. Работает без нареканий.
  • DEXP SSD C100 128Gb [SMI2259XT \ SM2259XA Hynix 3dv6-128L TLC] EXT4. Ок. Работает без нареканий.
  • KINGSTON SA400 512GB [PS3111 Sandisk 112L BiCS5 TLC] NTFS. Тупит, как smr, только лаг меньше.

P. S. Пингвин не умеет читать контроллер и память?

Reptile
() автор топика
Ответ на: комментарий от Reptile

Может, NTFS вставляет палки в колеса.

У тебя там ещё и NTFS? :)) Собрал трипл-комбо.

NTFS - самая худшая FS для скачки торрентов под линуксом. Файл при добавлении раздачи аллоцируется полностью.

Dimez ★★★★★
()
Ответ на: комментарий от Khnazile

Если торрент-клиент резервирует место без sparsity то да, они не будут игнорится на уровне ФС.

А вот на уровне SSD почти все контроллеры при попытке записи нулей в сектор помечают его как свободный и никуда ничего на самом деле не записывают кроме флага в FTL.

Sandforce были первыми ЕМНИП, почти все Phison так умеют, более подробно – не знаю.

Это тот самый случай когда шифрование будет сильно бить по перфу.

anonymous
()
Ответ на: комментарий от anonymous

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

Khnazile ★★★★★
()
Ответ на: комментарий от Reptile

Винды нет: vlo только там

Модель и прошивку показывают nvme/smartctl. vlo это про определение производителя флэша, и он часто полагается на предположения.

anonymous
()
Ответ на: комментарий от Dimez

У тебя там ещё и NTFS? :)) Собрал трипл-комбо.

На smr’ном hdd ntfs. На днях попробую перекинуть данные и потестить на ext4. И на одном ssd тоже ntfs.

NTFS - самая худшая FS для скачки торрентов под линуксом. Файл при добавлении раздачи аллоцируется полностью.

Аллоцирование - это запись нулей?) Какая фс может подойти? Или же EXT4 - стандарт де-факто?

Reptile
() автор топика
Ответ на: комментарий от Reptile

Аллоцирование - это запись нулей?)

Аллокация. Да. Sparse файлы на ntfs под линуксом создавать нельзя, поэтому делается 30-гиговый файл с нулями. В отличие от «нативных» FS.

Какая фс может подойти? Или же EXT4 - стандарт де-факто?

Любая «нативная», ext4 подойдёт.

Dimez ★★★★★
()
Ответ на: комментарий от Dimez

NTFS - самая худшая FS для скачки торрентов под линуксом

Зато выше лимит на длину имени

Ну, или раньше был выше. Не следил

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)