{"id":834,"date":"2026-08-08T22:47:38","date_gmt":"2026-08-08T22:47:38","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=834"},"modified":"2026-10-20T22:04:13","modified_gmt":"2026-10-20T22:04:13","slug":"vps-disk-io-tuning-filesystems","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-disk-io-tuning-filesystems\/","title":{"rendered":"Virtual Disk Performance Tuning: Filesystem, Scheduler and Mount Options Verified with fio"},"content":{"rendered":"
\n

Storage is the component most often misdiagnosed on a virtual server, because the visible device is a virtual block device whose latency, queue depth and throttling behaviour are all decided one layer below the guest. Two identical-looking plans can differ by 20x in random-write IOPS, and a filesystem tuned for local NVMe will behave badly on a network-attached volume. This guide separates the layers \u2014 device, scheduler, filesystem, mount options \u2014 shows how to measure each with fio<\/code>, and gives the mount options that actually change results. Everything here has been run on an instance listed under the provider’s VPS plan specifications<\/a>, which is the first thing to check: the plan’s advertised IOPS class sets the ceiling no tuning can exceed.<\/p>\n

Step 1: Identify What Kind of Device You Have<\/h2>\n

Before tuning, find out whether the block device is local NVMe, a paravirtualised virtio disk backed by a host SSD, or a network volume. The rotational flag and the queue parameters reveal almost all of it:<\/p>\n

<code>lsblk -o NAME,SIZE,ROTA,TYPE,MODEL,MOUNTPOINT,DISC-GRAN,DISC-MAX\ncat \/sys\/block\/vda\/queue\/rotational\ncat \/sys\/block\/vda\/queue\/nr_requests\ncat \/sys\/block\/vda\/queue\/scheduler\ncat \/sys\/block\/vda\/queue\/wbt_lat_usec 2>\/dev\/null<\/code><\/code><\/pre>\n
A rotational<\/code> value of 1 on a virtual disk is common and meaningless \u2014 the hypervisor reports HDD semantics for a network volume to avoid guests disabling merging. The reliable signal is measured latency: local NVMe shows p99 write latency in the low hundreds of microseconds, network-attached storage in the low milliseconds with far more variance.<\/p>\n
Step 2: Characterise the Device With fio<\/h2>\n
One benchmark is not enough. Measure four workloads that map to real applications: sequential read (backups restoring, large file serving), sequential write (log-heavy workloads), random 4K read (database index lookups) and random 4K write with queue depth (database commits, journaling).<\/p>\n
<code>fio --name=seqread  --rw=read      --bs=1M --size=2G --numjobs=1 --iodepth=8  \\\n    --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting\nfio --name=seqwrite --rw=write     --bs=1M --size=2G --numjobs=1 --iodepth=8  \\\n    --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting\nfio --name=randread --rw=randread  --bs=4k --size=1G --numjobs=4 --iodepth=32 \\\n    --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting\nfio --name=randwrite --rw=randwrite --bs=4k --size=1G --numjobs=4 --iodepth=16 \\\n    --fsync=1 --ioengine=libaio --direct=1 --runtime=30 --time_based --group_reporting<\/code><\/code><\/pre>\n
Always use --direct=1<\/code> to bypass the page cache, and --fsync=1<\/code> for the write test, otherwise you measure RAM. A typical mid-range virtual disk produces something in this shape:<\/p>\n\n\n\n\n\n\n
Workload<\/th>\nThroughput \/ IOPS<\/th>\np50 latency<\/th>\np99 latency<\/th>\n<\/tr>\n
Sequential read 1M QD8<\/td>\n1.1 GB\/s<\/td>\n\u2014<\/td>\n\u2014<\/td>\n<\/tr>\n
Sequential write 1M QD8<\/td>\n620 MB\/s<\/td>\n\u2014<\/td>\n\u2014<\/td>\n<\/tr>\n
Random read 4K QD128<\/td>\n48,000 IOPS<\/td>\n0.9 ms<\/td>\n4.1 ms<\/td>\n<\/tr>\n
Random write 4K fsync<\/td>\n6,800 IOPS<\/td>\n1.2 ms<\/td>\n11.4 ms<\/td>\n<\/tr>\n<\/table>\n
The p99\/p50 ratio is the number to watch. Read latency that is 4x the median means queueing somewhere in the path \u2014 hypervisor, network link or throttle. Latency that is 12x the median on fsync writes is normal for anything involving a network round trip and durability.<\/p>\n
Step 3: Scheduler and Queue Depth<\/h2>\n
For NVMe and virtio-blk devices none<\/code> is usually correct: the device has its own parallel queues and the kernel scheduler adds overhead without benefit. For older virtio or SATA-backed virtual disks, mq-deadline<\/code> bounds tail latency better than none<\/code> under mixed load.<\/p>\n
<code># compare without rebooting\necho none        > \/sys\/block\/vda\/queue\/scheduler\necho mq-deadline > \/sys\/block\/vda\/queue\/scheduler\n\n# persist\ncat >\/etc\/udev\/rules.d\/60-io-scheduler.rules <<'EOF'\nACTION==\"add|change\", KERNEL==\"vd[a-z]\", ATTR{queue\/scheduler}=\"none\"\nACTION==\"add|change\", KERNEL==\"nvme[0-9]n[0-9]\", ATTR{queue\/scheduler}=\"none\"\nEOF<\/code><\/code><\/pre>\n
Also raise nr_requests<\/code> for NVMe devices serving database workloads; the default of 64 on some kernels queues too shallowly for high-IOPS random reads:<\/p>\n
<code>echo 1024 > \/sys\/block\/vda\/queue\/nr_requests<\/code><\/code><\/pre>\n
Measure before and after with the random-read fio job. On a virtio disk with a shared backend the gain is often under 3% \u2014 the queue was never the limit \u2014 which is exactly the kind of result that stops you from chasing the same knob on every host.<\/p>\n
Step 4: Filesystem Choice<\/h2>\n
Three candidates matter on a server: ext4, XFS and btrfs. Measure them on the same device, not across machines.<\/p>\n\n\n\n\n\n
Filesystem<\/th>\nRandom 4K write (fsync)<\/th>\nConcurrent small files<\/th>\nNotes<\/th>\n<\/tr>\n
ext4<\/td>\n6,900 IOPS<\/td>\nFast<\/td>\nMature, best-tested, shrinking not supported<\/td>\n<\/tr>\n
XFS<\/td>\n7,300 IOPS<\/td>\nVery fast<\/td>\nScales on large directories, can grow online only<\/td>\n<\/tr>\n
btrfs<\/td>\n3,100 IOPS<\/td>\nModerate<\/td>\nCopy-on-write costs on small writes; snapshots excellent<\/td>\n<\/tr>\n<\/table>\n
btrfs’s write amplification from copy-on-write is real and shows up most on database-style random writes. It remains the right answer when you need cheap snapshots or checksums, and the wrong answer for an InnoDB data directory on a modest disk.<\/p>\n
With the filesystem chosen, format with intent \u2014 the inode ratio on XFS matters for workloads that create millions of small files:<\/p>\n
<code>mkfs.xfs -f -m reflink=1 -i maxpct=10 -d agcount=8 \/dev\/vda2\nmkfs.ext4 -F -O ^has_journal -E stride=0 -m 1 \/dev\/vda2   # only if you have a real journal elsewhere<\/code><\/code><\/pre>\n
Do not disable the ext4 journal on a VPS. The performance gain is in the noise compared with the recovery risk after a host power event.<\/p>\n
Step 5: Mount Options That Matter<\/h2>\n
These are the options that change measured behaviour, not folklore:<\/p>\n