In the world of Web3 infrastructure, disk I/O is almost always the ultimate bottleneck. Running a high-throughput blockchain node—whether it’s an Ethereum execution client like Erigon, a Solana validator, or a heavy-data indexer—demands relentless, parallel, low-latency disk writes.

When you run these workloads on virtualized cloud instances, you are inherently fighting a losing battle. Cloud providers throttle your Input/Output Operations Per Second (IOPS), abstract your storage layers, and charge a premium for “burst” performance.

Bare-metal hardware changes the game. Running on dedicated iron gives you direct access to the Linux kernel, allowing you to bypass hypervisor overhead and squeeze every ounce of performance out of your NVMe drives.

Here is how to tune your bare-metal Linux storage stack specifically for the punishing write cycles of blockchain databases.

1. Bypass Overhead: Switch to the Correct NVMe Disk Scheduler

Traditional disk schedulers (like bfq) try to be smart about sorting I/O requests to accommodate spinning platters or general-purpose workloads. For high-throughput, multi-threaded database writes on modern NVMe drives, this “intelligence” just introduces CPU overhead and latency.

For dedicated blockchain infrastructure, you generally want one of two paths:

• none: Completely bypasses the OS-level scheduler, handing I/O management entirely to the NVMe controller’s native hardware queues.
• kyber: A lightweight, modern scheduler designed specifically for fast storage. It prioritizes low latency by capping maximum read/write delays.

Check Current Scheduler

To see what scheduler your drive (e.g., nvme0n1) is currently using, run:

cat /sys/block/nvme0n1/queue/scheduler

cat /sys/block/nvme0n1/queue/scheduler

(The active scheduler will be wrapped in square brackets, like [none] or [mq-deadline]).

Apply the Tweak Natively

To switch to none (often best for pure raw throughput) or kyber instantly:

sudo echo "none" > /sys/block/nvme0n1/queue/scheduler

sudo echo "none" > /sys/block/nvme0n1/queue/scheduler

Make it Permanent via Udev

Directly echoing into /sys will reset on a reboot. To lock this configuration in permanently, create a custom udev rule:

sudo nano /etc/udev/rules.d/60-blockchain-storage.rules

sudo nano /etc/udev/rules.d/60-blockchain-storage.rules

Add the following line to ensure all non-rotational NVMe drives automatically use the optimal scheduler:

ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

2. Eliminate Useless Writes: Optimize /etc/fstab with noatime

By default, Linux likes to keep track of the exact metadata time a file was last accessed (atime). Every single time a database process reads a file, the file system triggers a corresponding write operation to update that timestamp.

For a blockchain node constantly scanning historical blocks and updating state trees, this creates an enormous, invisible write amplification storm that degrades performance and prematurely burns through your drive’s endurance.

The Fix: Mount with noatime and nodiratime

Open your file system configuration file:

sudo nano /etc/fstab

sudo nano /etc/fstab

Locate the partition housing your blockchain data directory and modify its mount options to include noatime and nodiratime. Your entry should look similar to this:

UUID=xxxx-xxxx-xxxx    /mnt/blockchain-data    ext4    defaults,noatime,nodiratime,errors=remount-ro    0    2

UUID=xxxx-xxxx-xxxx    /mnt/blockchain-data    ext4    defaults,noatime,nodiratime,errors=remount-ro    0    2

Remount Dynamically

You don’t need to reboot the server to apply this. Remount the active directory on the fly:

sudo mount -o remount,noatime /mnt/blockchain-data

sudo mount -o remount,noatime /mnt/blockchain-data

3. Prevent Memory Stalls: Tune Cache Swapping & Dirty Ratios

Blockchain databases manage massive in-memory caches to stage transactions and state changes before flushing them to disk. If the Linux kernel’s virtual memory subsystem isn’t configured to match this behavior, the system will suddenly freeze or drop frames when flushing large chunks of memory to disk.

We need to optimize three core kernel parameters in /etc/sysctl.conf: vm.swappiness, vm.dirty_background_ratio, and vm.dirty_ratio.

The Tuning Strategy

Apply the Configuration

Open your kernel parameters file:

sudo nano /etc/sysctl.conf

sudo nano /etc/sysctl.conf

Append the following optimized values to the bottom of the file:

# Web3 Infrastructure Storage Optimizations
vm.swappiness = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

# Web3 Infrastructure Storage Optimizations
vm.swappiness = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

To activate these settings immediately without restarting your infrastructure:

sudo sysctl -p

sudo sysctl -p

The Bare-Metal Advantage: Cloud providers mask these underlying kernel constraints beneath heavy hypervisor layers. By running bare-metal and stripping away unnecessary access timestamps, dropping scheduling overhead, and keeping database pages locked in physical RAM, you minimize write amplification and unlock the true hardware capabilities of your storage array.