Demo
Demo

Knowledge base

PMTA knowledge base›Block <spool>›Directive§ 3.3.2.1

delete-file-holders

<spool>set by the Hub

Whether to delete temporary file holders after delivery
in the configuration this is a linedelete-file-holders falseinside the block <spool>
Saving I/O at the cost of files in the directory

The default is false. The line decides the fate of file holders — temporary files the engine deliberately leaves in the spool directory to save on I/O.

The point of the technique is that creating a file costs more than reusing one already created. A holder left behind spares that work next time.

With true, holders are deleted after the message is delivered — the directory stays clean, but every new message creates its file anew.

This is a classic trade-off: space and file count versus write speed.

The main trap is the number of files, not their size. Holders are small, and the space they take is small. What they take is directory entries, and file systems work noticeably slower on directories with hundreds of thousands of files — including the engine itself, which rereads this directory.

So the I/O saved on one message turns into I/O lost on all the others. Where the boundary lies depends on the file system and the volume — it can only be found out by counting the files in the directory.

What the Hub does. It writes yes — holders are deleted. The line came from the Protosender reference configuration, with which the Hub shares its format, and it is present in both templates.

For the fleet this is the right choice: nodes live long and unattended, their volume is uneven, and files piling up in the spool is the kind of failure that gets noticed late. The saving on creating a file is incommensurable with the risk at our volumes.

Recommended values

What to set. The trade-off is weighed by volume and by supervision:

Value When
false (default) a steady high flow and an eye on the spool: the I/O saving pays off
true an uneven flow or an unattended node — the directory stays clean

The second is safer and therefore usually right for a fleet: the price is creating a file for each message, and that is cheap at any reasonable volume.

The default false and the purpose of holders — saving I/O — are from the manual, § 3.3.2.1. The analysis of the file count in the directory and the breakdown of cases are ours.
Example configuration
# this is how the Hub writes the configuration — the directory stays clean
<spool /var/spool/pmta>
    deliver-only no
    delete-file-holders yes</spool>
The pair of lines describes the behavior of the node’s only directory: it is a working one and does not accumulate temporary files.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Leaving the default on an unattended node

our experience

What it costsHolders pile up, the number of files in the directory grows, and the file system starts working slower — along with the engine itself, which rereads this directory. This is noticed late, by a general slowdown.
How to spot itThe spool directory holds many times more files than there are messages in the queue.
How to do it rightEnable holder deletion: the price is creating a file per message, and it is small.

Treating holders as a fault and cleaning them by hand

§ 3.3.2.1

What it costsThis is a normal engine technique, not debris after a failure. Deleting by hand while the node is running may take a file the engine was about to reuse.
How to spot itA scheduled cleanup is regularly run in the spool directory.
How to do it rightSet the behavior with the line and do not touch the directory by hand.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
delete-file-holders <boolean>
Values
yes | no | true | false
Default
false § 3.3.2.1
Applying
reload, no restart needed
Queue
also affects what is already in the queue
Where to write it
<spool>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <spool> and applies to one directory. There is no inheritance between directories: each location has its own trade-off, and on a fast disk it may differ from that on a slow one.
⇄

Related directives

1 relation

Applies to

Where the queue lives on diskOne of the block’s four lines: the fate of temporary files after a message is delivered. § 3.3.2.1

How to check on the node
The line is visible in the configuration, the consequence — by counting the files in the directory:
grep -n -A4 '^<spool' /etc/pmta/config
find /var/spool/pmta -type f | wc -l
The number of files should be comparable to the number of messages in the queue. A noticeably larger number means accumulated holders — and a reason to enable their deletion.
◇

What else to read

3 articles

◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.

In the Hub
Managed at
Analytics → Node accounting
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Prepare a node for sending
Neighboring settings of the block <spool>:min-free-spacedeliver-onlypriorityAll 4 directives of the block →