transmission-daemon и перенос файлов

Ну так переноси сам по крону. У трансмишшион есть api, по которому можнотопрелелить что файл скачан

Он после скачки из incomplete-dir в download-dir сам все переносит.
Написал, но не прочитал.

Может подкрутить vm.dirty_ и для transmission-daemon i/o idle приоритет сделать, чтобы вис именно transmission-daemon, а не transgui. Если это флешка, то смысла перемещать с помощью transmission нет, потому что раздачи при отмонтировании сломаются, флешке лучше по блокам синхронизировать файлы.

transgui тут не причем, речь о transmission-daemon.
Нет там флешек.

Если это vps с 100TB/s сетью, то можно использовать ssd как кэш средствами ядра dm-cache, bcache, swap и прочее, и сразу на hdd писать без всяких перемещений, но я так не умею.

На это жалуются многие (https://github.com/transmission/transmission/issues/6961), и чтобы закрывать такие баги с вердиктом «дубликат», разрабы transmission три года назад завели feature request (https://github.com/transmission/transmission/issues/2462).

Да. Это именно то, о чем я и говорю. В общем, вывод: трансмиссион для сервера говно. Заметны большие просадки не только при переноске, но и при большой дисковой активности.

«Он после скачки из incomplete-dir в download-dir сам все переносит.»

тебе уже все написали. Берешь API сам пересишь без трасмишена например через rsync. Профит

Есть еще deluge, ctorrent, qbittorrent

transmission-daemon встает раком на время

Ну так его любят за другие фичи, а не за скорость и отзывчивость.

спасибо подсветил проблему, download-dir и incomplete-dir на один и тотже раздел hdd назначил, перенос стал мгновенным т.к. не копирует, а переносит.

спасибо подсветил проблему, download-dir и incomplete-dir на один и тотже раздел hdd назначил, перенос стал мгновенным т.к. не копирует, а переносит.

Вы как дети. А если у меня вообще nfs.

Тут надо честно сказать, что виноваты оба, и transmission-daemon и transgui. Демон в ивентлупе синхронный io делает, из-за чего на rpc отвечает не мгновенно. Гуй в ивентлупе синхронный rpc делает, из-за чего window ивенты обрабатывает не мгновенно. В результате пользователь получает фризы пользовательского интерфейса.

а зачем вообще incomplete-dir? юзаю без оного

Да там дело даже не в transgui с rpc. transmission-daemon сам по себе тупит во время дисковых операций.

а зачем вообще incomplete-dir? юзаю без оного

Ну, наверное, потому что он у тебя просто на десктопе, и ты вообще не заморачивался, что и как он делает.

На сервере (Ubuntu 24.04.2 LTS) стоит transmission-daemon.

кто на десктопе?

sdb - hdd, sdd - ssd, чтоб скорости для записи для скачек хватало.

т.е. запись на hdd медленнее закачки? -_-

sdb - hdd, sdd - ssd, чтоб скорости для записи для скачек хватало.

т.е. запись на hdd медленнее закачки? -_-

Именно так.

На сервере (Ubuntu 24.04.2 LTS) стоит transmission-daemon.

кто на десктопе?

Никто. Иногда с разных клиентов transgui.

Сложно представить, проверял? И что, если писать сразу на hdd, сильно «плохо»?
Если так - то остается sync-ать.

sdb - hdd, sdd - ssd, чтоб скорости для записи для скачек хватало.

т.е. запись на hdd медленнее закачки? -_-

Именно так.

Сложно представить

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

Ну почему, может у него там MFM харды. :)

Ну не mfm, а вобще интересно было бы в живую увидеть mfm хотя бы на 1gb. :) У меня были макс 40mb, или 20. Точно не помню уже.

Ну или убитые вусмерть, вот они на каждой операции записи и тупят неподетски :)

Речь шла о переносе больших торентов с харда на хард. Вот здесь проблема есть. На время переноса демон просто не отвечает.

Ну не mfm, а вобще интересно было бы в живую увидеть mfm хотя бы на 1gb. :)

На 1гиг их может и не существовало, во всяком случае мне кажется что скорее нет, чем да, имхо слишком большой объем.