EX200 Configure local storage Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Increase the read-ahead buffer using blockdev --setra

  Why it's wrong here

  Raising the read-ahead buffer with blockdev --setra only helps when workloads perform sequential reads, where the kernel can prefetch adjacent blocks. High disk i/o wait in a database environment is usually caused by random reads and writes, where prefetching is useless because the next requested block cannot be predicted. Worse, aggressive read-ahead can issue extra useless reads, increasing queue depth and iowait further, so this does not address the underlying hardware latency.

• ✗

  Change the I/O scheduler from CFQ to noop

  Why it's wrong here

  Switching from CFQ to noop reduces scheduling CPU overhead and simplifies request merging, but it does not increase the physical throughput of a rotating disk. On a single HDD, the dominant component of high await is mechanical seek time and rotational latency, not the policy of the I/O scheduler. Moreover, modern kernels already default to mq-deadline or BFQ for SSDs and NVMe devices, and with slow disks the scheduler is rarely the bottleneck, so this change would have negligible impact.

• ✗

  Run 'fsck -f' on the filesystem to check for fragmentation

  Why it's wrong here

  The fsck utility verifies filesystem metadata integrity and repairs corruption; it does not defragment files or reclaim fragmented blocks. ext4 uses extent-based allocation and delayed allocation, which greatly reduces fragmentation, and even significant fragmentation would not be diagnosed by fsck. High i/o wait is a performance problem related to device latency and queue depth, not to filesystem structural inconsistency, so running fsck -f is both unnecessary and ineffective for this symptom.

• ✓

  Replace the drive with an SSD or add additional drives in RAID 10

  Why this is correct

  Replacing a mechanical drive with an SSD or deploying RAID 10 directly attacks the root cause of high disk i/o wait: excessive per-request latency and insufficient IOPS. SSDs eliminate rotational seek times and provide thousands of IOPS, while RAID 10 combines striping for parallel reads and writes with mirroring for redundancy, allowing multiple spindles to serve requests concurrently. This decreases both service time and queue depth, thereby reducing the await metric and iowait experienced by the database server.

Go deeper

Related to this question