Disk I/O Bottleneck

This is the one limit that gets worse as the line gets faster, because the network side scales with the connection while the storage side does not. A 50 Mbps line writing 6 MB/s troubles no disk. A gigabit line asking a single mechanical drive to absorb 100 MB/s of decoded segments while reading an archive back for verification and writing extracted output at the same time is requesting three streams of work from a device with one head.

The signature

Throughput that is healthy until post-processing starts and collapses the moment it does, then recovers when the unpack finishes. The correlation is with what the client is doing, not with the hour or the server, which is what separates this from congestion on the path. Speed that is flat and low regardless of whether anything is being repaired or extracted is some other fault, most often connection count or a processor ceiling.

What competes for the same device

• Incoming segments being decoded and written into the incomplete folder.
• PAR2 verification, which reads the entire set back at whatever rate the device allows.
• Extraction, reading the archive and writing the output simultaneously.
• The move into the completed folder at the end of the job.
• Unrelated software on the same volume: a media server scanning its library, a nightly backup, an antivirus product examining every file as it appears.

Moves that are secretly copies

A move between two directories on one filesystem is a rename and costs effectively nothing. A move between different filesystems, between different drives, or across a container boundary where the two paths are separate mounts, is a full read and a full write of a finished release. Placing the completed folder on the same filesystem as the destination library is what makes instant moves and hardlinks possible, and it removes a large block of I/O from the end of every job.

Measuring rather than guessing

Every platform exposes a per-device utilization figure: iostat on Linux, the disk active time column in Task Manager, the resource monitor on a NAS. A device sitting near one hundred percent busy with a growing queue depth is saturated, and no change on the network side will help. Comparing that figure during plain downloading against the figure during an unpack shows the contention directly.

Relieving it

Putting the incomplete folder on an SSD and the completed folder on bulk storage separates the two heaviest workloads. Limiting the client to one post-processing job at a time prevents two repairs from fighting each other. Turning off direct unpack on slow media stops extraction from overlapping with the download it depends on. USB volumes sharing a controller are a common hidden cause, since two drives on one bus do not behave like two drives. A modest speed cap set just under the device's sustained write rate often completes more jobs per hour than an uncapped rate that thrashes.