Disk Full

Also known as: out of disk space, no space left

Downloads pause or fail when the destination volume runs out of space, and the client often reports only a generic write error. A Usenet workflow needs room for the incomplete folder, the extracted output, and the temporary files PAR2 repair creates, which together can approach three times the release size. Keeping incomplete and completed folders on the same small volume makes this far more likely.

The arithmetic behind this catches people out because a release occupies its own size more than once, and the peak arrives during post-processing rather than at the moment the last segment lands. A job that fitted comfortably when it was queued can exhaust the volume during repair, after every byte has already been paid for once. Fault here is local without qualification: no provider setting and no indexer affects it.

Counting the space a job needs

Three claims on the volume overlap in time.

  • The archive set as posted, written into the incomplete folder as segments decode.
  • The .par2 recovery volumes, which for a typical posting add somewhere in the region of five to fifteen percent on top of the set.
  • The extracted output, which is close to the archive size again and exists alongside the archive until the client deletes the source files.

Repair adds temporary files of its own while it reconstructs damaged blocks. Two and a half to three times the release size is a safe planning figure, and the requirement is higher where the completed folder sits on a different filesystem from the incomplete folder, because the final move is then a copy and both copies exist at once.

Free space that is not actually free

A volume can report available gigabytes and still refuse writes. Snapshots on ZFS or Btrfs pin deleted data until they expire. Recycle bins retain cleared downloads. Reserved blocks on ext4 are unavailable to an unprivileged process. On a container host, image layers and log files grow somewhere nobody is watching. Thin-provisioned storage can be exhausted at the pool level while the guest filesystem still believes it has room, and a per-user quota produces an identical failure on a volume with plenty to spare.

Why the message rarely mentions space

The client sees a failed write and reports what the operating system handed it, which is often a generic I/O error. The same shortage surfaces as an unpack that fails partway, as a repair that aborts in a way easily mistaken for insufficient recovery blocks, or as a queue that simply pauses itself. Checking free space is worth doing before any of those are investigated as separate problems, since one shortage produces all of them.

Restarting a job that filled the volume

Freeing space and resuming is usually enough, and completed segments in the incomplete folder survive. Partial output from an interrupted extraction should be removed first, since some clients will not overwrite it and others will treat it as finished. The durable fix is separating the roles: the incomplete folder on a volume sized for working space, the completed folder on the same filesystem as the final library so that the move is a rename rather than a copy, and a minimum free-space threshold configured in the client so that it pauses rather than fails.

Frequently asked questions

Roughly two and a half to three times the release size. The archive set, the PAR2 recovery volumes, the temporary files created during repair, and the extracted output all exist at the same time before the client cleans up. If the completed folder is on a different filesystem from the incomplete folder, the final move is a copy and needs the space twice.
Because the space is committed elsewhere. Filesystem snapshots, recycle bins, reserved blocks, per-user quotas, and thin-provisioned pools all produce a volume that reports free capacity while refusing writes. On container hosts the culprit is often image layers or logs on the same underlying volume rather than anything belonging to the download client.
Yes, and it is frequently misdiagnosed. Repair writes temporary reconstruction data before producing the fixed files, so a volume with too little headroom aborts the repair. The resulting message can resemble a shortage of recovery blocks. Checking free space before adding more PAR2 blocks avoids downloading data that will not solve the problem.

Browse all terms in Errors & Troubleshooting, or see the full Usenet glossary.

Put it into practice with the world's best usenet service