Config to limit disk usage for YT sync #6450

Open
opened 2026-02-22 12:55:34 -05:00 by deekerman · 3 comments
Owner

Originally created by @afilina on GitHub (Feb 5, 2026).

Describe the problem to be solved

Hi, I am synchronizing rather large channels (often over a thousand hours of content). It downloads from YT faster than my runners can transcode. Only then can PeerTube can move files to remote storage and reclaim disk space. I've been using all kinds of workarounds to manage disk space usage during those syncs.

Describe the solution you would like

The easiest would have been a production.yaml config that says, for example: "don't download any more if sum of downloaded files exceeds 100GB" or maybe keep X GB free space at all times.

Originally created by @afilina on GitHub (Feb 5, 2026). ### Describe the problem to be solved Hi, I am synchronizing rather large channels (often over a thousand hours of content). It downloads from YT faster than my runners can transcode. Only then can PeerTube can move files to remote storage and reclaim disk space. I've been using all kinds of workarounds to manage disk space usage during those syncs. ### Describe the solution you would like The easiest would have been a `production.yaml` config that says, for example: "don't download any more if sum of downloaded files exceeds 100GB" or maybe keep X GB free space at all times.
Author
Owner

@Chocobozzz commented on GitHub (Feb 16, 2026):

Hello,

I think github.com/Chocobozzz/PeerTube@0920f5fa82 will help. I suggest waiting for 8.1 to check, and if it doesn't we'll find another solution.

@Chocobozzz commented on GitHub (Feb 16, 2026): Hello, I think https://github.com/Chocobozzz/PeerTube/commit/0920f5fa822fb72815c3f64d75425e7f2ad9a275 will help. I suggest waiting for 8.1 to check, and if it doesn't we'll find another solution.
Author
Owner

@afilina commented on GitHub (Feb 21, 2026):

It's a big diff in a codebase I'm not familiar with, so I rely on the commit message. These new rules will be very helpful. Thank you!

However, when starting a sync with several thousand hours of content, we'd still download much faster than we can free it up, and there are no configs that guarantee disk space availability. When a download eats up the last of the disk space, the site crashes. It happened twice already.

A reserved amount that the downloader should respect would go a long way to prevent a crash when these syncs run unattended (which happens when Europe sets up a big channel sync while I sleep in Canada). I temporarily threw an extra half terabyte at this problem.

@afilina commented on GitHub (Feb 21, 2026): It's a big diff in a codebase I'm not familiar with, so I rely on the commit message. These new rules will be very helpful. Thank you! However, when starting a sync with several thousand hours of content, we'd still download much faster than we can free it up, and there are no configs that guarantee disk space availability. When a download eats up the last of the disk space, the site crashes. It happened twice already. A reserved amount that the downloader should respect would go a long way to prevent a crash when these syncs run unattended (which happens when Europe sets up a big channel sync while I sleep in Canada). I temporarily threw an extra half terabyte at this problem.
Author
Owner

@afilina commented on GitHub (Feb 21, 2026):

@Chocobozzz Unrelated to the ticket: where do I support the maintainers of this project?

Edit: never mind, found https://support.joinpeertube.org/en/ and set up recurring donation.

@afilina commented on GitHub (Feb 21, 2026): @Chocobozzz Unrelated to the ticket: where do I support the maintainers of this project? Edit: never mind, found https://support.joinpeertube.org/en/ and set up recurring donation.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/PeerTube#6450
No description provided.