Control Linux Disk I/O Priority Safely with ionice

ionice lets you tell the kernel a job can wait its turn for disk time, without touching the job itself. This guide inspects a process's I/O scheduling class, runs a command with a deliberate priority, and changes an existing process without restarting it. Allow about ten minutes. You need a shell and the ionice command from util-linux. The examples are read-only until the step that changes a test process, so you can follow them without touching a service.

The local manpage is from util-linux 2.39.3, while the ionice executable first found in this shell reports util-linux 2.41.3. The core interface and output used here agree, but keep that difference in mind when comparing another host. The command is part of the util-linux package; it is not a setting in a configuration file.

1. Check which ionice you are using

Start by checking the command path and version. This catches a common distraction: a locally installed executable can take precedence over the distribution package's command.

$ command -v ionice
/home/linuxbrew/.linuxbrew/bin/ionice
$ ionice --version
ionice from util-linux 2.41.3

On a distribution-managed installation, the path and version will differ. The documented interface accepts a command to launch, or a process ID, process group ID or user ID to inspect or change.

Checkpoint: Record the version if you are writing a script or investigating a result on more than one machine.

2. Inspect a process without changing it

With only -p, ionice reports the current class and priority. Use your own shell process for a harmless first check:

$ ionice -p $$
none: prio 0

none means that the process has not requested a specific I/O class. Linux treats an unspecified process as effective best-effort work, but the query can still display none. Do not read prio 0 here as proof that the process has explicitly been assigned best-effort priority.

You can query several process IDs in one command:

$ ionice -p 1234 5678

Replace those numbers with real, running PIDs. If a process exits between finding its PID and querying it, the command can report an error. Recheck the process list rather than adding --ignore blindly.

3. Run one command at idle priority

The idle class is the safest choice when work should yield disk time to other processes. It takes no priority number. Start the command through ionice:

$ ionice -c idle sh -c 'ionice -p $$'
idle

The inner query is run by the child shell, so it confirms the class inherited by the command. Ordinary users are permitted to use the idle class on supported Linux kernels. This does not make a command faster. It tells the I/O scheduler to serve it only when other disk requests have been quiet for the scheduler's grace period.

For a real job, replace the final command and its arguments, for example:

$ ionice -c idle tar -cf /path/to/archive.tar /path/to/data

Creating an archive reads the input tree and writes an output file, so choose paths carefully. The command above does not require sudo unless you do not have permission to read the source or write the destination. Check the archive and its destination after the command finishes.

4. Choose best-effort priority for ordinary background work

Best-effort is the normal explicit class. Its priority range is 0 to 7, and lower numbers mean higher priority. If you give ionice a command but no class, it selects best-effort and defaults to priority 4:

$ ionice sh -c 'ionice -p $$'
best-effort: prio 4

Set a level deliberately when the workload needs one. This example requests the highest best-effort priority:

$ ionice -c best-effort -n 0 sh -c 'ionice -p $$'
best-effort: prio 0

A lower number gives the process a stronger claim among best-effort work. It is not a guarantee of a fixed transfer rate. The result still depends on the kernel, storage device and active I/O scheduler.

Realtime is different. It has priority levels 0 to 7 and receives first access to the disk, which can starve other processes. The manpage says it is not available to ordinary users. Treat any realtime request as a deliberate operational change requiring review and elevated privilege, not as a routine performance tweak.

5. Change and verify an existing process

Use a real PID only after checking what it belongs to. The following safe test creates a temporary sleep process, changes it, and queries it again:

$ sleep 30 & pid=$!
$ ionice -p "$pid"
none: prio 0
$ ionice -c idle -p "$pid"
$ ionice -p "$pid"
idle
$ ionice -c best-effort -n 4 -p "$pid"
$ ionice -p "$pid"
best-effort: prio 4
$ kill "$pid"

The -p form changes already-running processes. Use -P for process groups and -u for all processes belonging to a user ID. Those wider scopes deserve an extra review because one command can affect more work than intended.

Changing your own process normally needs no elevation. Changing another user's process, or selecting realtime priority, may fail without the required privilege. Use sudo only after confirming the PID or UID and the operational impact:

$ sudo ionice -c idle -p 1234
$ ionice -p 1234

The second command may also need permission to inspect the target. If you used sudo to change a service, undo the temporary choice by setting its previous class and level, or restart it through its normal service manager if that is how the service establishes its process state. Do not kill a production process merely to undo an I/O setting.

6. Handle failures without hiding them

The -t or --ignore option tells ionice to run a requested command even when setting the requested priority fails, such as through insufficient privilege or an older kernel. That is useful only when the command is safe to run without the requested scheduling policy. It can also conceal the reason a workload behaved differently, so check the exit status and log the condition in scripts.

Do not pass -n with idle class: idle accepts no priority data. For realtime and best-effort, stay within 0 to 7. If a target PID no longer exists, find it again rather than reusing a stale number. If a setting appears ineffective, query the same PID immediately and confirm that the process has not forked or exited.

These commands change scheduling state, not file ownership, permissions or the contents of the workload. They also do not change the system-wide I/O scheduler. Keep the original command available so you can return to it if a batch job becomes too aggressive or too slow.

Done means