Final tweaks.

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/disk-io-benchmark/_index.md

@@ -3,10 +3,10 @@ title: Microbenchmark storage performance with fio on Arm
 
 minutes_to_complete: 30
 
-who_is_this_for: This is an introductory topic for developers who want to optimize storage performance, reduce costs, identify bottlenecks, and evaluate storage options when migrating applications across platforms.
+who_is_this_for: This is an introductory topic for developers looking to optimize storage performance, reduce costs, identify bottlenecks, and evaluate storage options when migrating applications across platforms.
 
 learning_objectives: 
-    - Describe how data flows through storage devices.
+    - Describe data flow through storage devices.
     - Monitor storage performance using tools like iostat, iotop, and pidstat.
     - Run fio to microbenchmark a block storage device.
 

content/learning-paths/servers-and-cloud-computing/disk-io-benchmark/characterising-workload.md

@@ -1,12 +1,12 @@
 ---
-title: Characterizing a workload
+title: Analyzing I/O behavior with real workloads
 weight: 3
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Basic attributes
+## Workload attributes 
 
 The basic attributes of a given workload are the following: 
 
@@ -16,13 +16,15 @@ The basic attributes of a given workload are the following:
 - Read-to-write ratio.
 - Random vs. sequential access.
 
-While characteristics like latency are important, this section focuses on the high-level metrics listed above. 
+While latency is also an important factor, this section focuses on these high-level metrics to establish a foundational understanding.
 
 ## Run an example workload
 
 Connect to an Arm-based server or cloud instance. 
 
-As an example workload, use the media manipulation tool, FFMPEG on an AWS `t4g.medium` instance. This is an Arm-based (AWS Graviton2) virtual machine with two vCPUs and 4 GiB of memory, designed for general-purpose workloads with a balance of compute, memory, and network resources.
+As an example workload, use the media manipulation tool, FFMPEG on an AWS `t4g.medium` instance. 
+
+This is an Arm-based (AWS Graviton2) virtual machine with two vCPUs and 4 GiB of memory, designed for general-purpose workloads with a balance of compute, memory, and network resources.
 
 First, install the required tools: 
 
@@ -39,7 +41,9 @@ mkdir src && cd src
 wget http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4
 ```
 
-Run the following command to begin transcoding the video and audio using the `H.264` and `aac` transcoders respectively. The `-flush_packets` flag forces FFMPEG to write each chunk of video data from memory to storage immediately, rather than buffering it in memory. This reduces the risk of data loss in case of a crash and allows disk write activity to be more observable during monitoring, making it easier to study write behavior in real-time.
+Run the following command to begin transcoding the video and audio using the `H.264` and `aac` transcoders respectively. The `-flush_packets` flag forces FFMPEG to write each chunk of video data from memory to storage immediately, rather than buffering it in memory. 
+
+This reduces the risk of data loss in case of a crash and allows disk write activity to be more observable during monitoring, making it easier to study write behavior in real-time.
 
 ```bash
 ffmpeg -i BigBuckBunny.mp4 -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k -flush_packets 1 output_video.mp4

content/learning-paths/servers-and-cloud-computing/disk-io-benchmark/introduction.md

@@ -10,17 +10,27 @@ layout: learningpathall
 
 Performance-sensitive application data - such as frequently-accessed configuration files, logs, or transactional state - should ideally reside in system memory (RAM) or CPU cache, where data access latency is measured in nanoseconds to microseconds. These are the fastest tiers in the memory hierarchy, enabling rapid read and write operations that reduce latency and improve throughput. 
 
-However, random-access memory (RAM) is volatile (data is lost on power down), limited in capacity, and more expensive per gigabyte than other storage types. Due to these constraints, most applications also rely on solid-state drives (SSDs) or hard disk drives (HDDs).
+However, random-access memory (RAM) has the following constraints:
+
+* It is volatile - data is lost on power down.
+* It is limited in capacity.
+* It is more expensive per gigabyte than other storage types. 
+
+For these reasons, most applications also rely on solid-state drives (SSDs) or hard disk drives (HDDs).
 
 ## High-level view of data flow
 
 The diagram below shows a high-level view of how data moves to and from storage in a multi-disk I/O architecture. Each disk (Disk 1 to Disk N) has its own I/O queue and optional disk cache, communicating with a central CPU through a disk controller. 
 
-While memory is not shown, it plays a central role in providing fast temporary access between the CPU and persistent storage. Likewise, file systems (not depicted) run in the OS kernel and manage metadata, access permissions, and user-friendly file abstractions. 
+While memory is not shown, it plays a central role in providing fast temporary access between the CPU and persistent storage. Likewise, file systems (also not depicted) run in the OS kernel and manage metadata, access permissions, and user-friendly file abstractions. 
 
-This architecture enables parallelism in I/O operations, improves throughput, and supports scalability across multiple storage devices.
+This architecture has the following benefits:
 
-![disk i/o](./diskio.jpeg)
+* It enables parallelism in I/O operations.
+* It improves throughput.
+* It supports scalability across multiple storage devices.
+
+![disk i/o alt-text#center](./diskio.jpeg "A high-level view of data flow in a multi-disk I/O architecture.")
 
 ## Key Terms
 
@@ -33,9 +43,9 @@ This architecture enables parallelism in I/O operations, improves throughput, an
 
 #### Input/Output Operations per Second (IOPS)
 
-IOPS measures how many random read/write requests your storage system can perform per second. It depends on the block size or device type. For example, AWS does not show IOPS values for traditional HDD volumes.
+IOPS measures how many random read/write requests your storage system can perform per second. It depends on the block size or device type. For example, AWS does not show IOPS values for traditional HDD volumes, as shown in the image below:
 
-![iops_hdd](./IOPS.png)
+![iops_hdd alt-text#center](./IOPS.png "Example where IOPS values are not provided.")
 
 #### Throughput and bandwidth
 
@@ -49,14 +59,15 @@ You can calculate storage `throughput as IOPS × block size`.
 
 *Queue depth* is the number of I/O operations a device can process concurrently. Consumer SSDs typically support a queue depth of 32–64, while enterprise-class NVMe drives can support hundreds to thousands of concurrent requests per queue. Higher queue depths allow more operations to be handled simultaneously, which can significantly boost throughput on high-performance drives — especially NVMe SSDs with advanced queuing capabilities.
 
-#### I/O Engine
+#### I/O engine
 
 The I/O engine is the software layer in Linux that manages I/O requests between applications and storage. For example, the Linux kernel's block I/O scheduler queues and dispatches requests to device drivers, using multiple queues to optimize disk access. Benchmarking tools like `fio` let you choose different I/O engines:
 
-* `sync`- synchronous I/O.
-* `libaio` - Linux native asynchronous I/O.
-* `io_uring` - a newer async I/O interface in newer Linux kernels.
+* `sync` – Performs blocking I/O operations using standard system calls. Simple and portable, but less efficient under high concurrency.
+* `libaio` – Uses Linux's native asynchronous I/O interface (`io_submit`/`io_getevents`) for non-blocking operations with lower overhead than `sync`.
+* `io_uring` – A modern, high-performance async I/O API introduced in Linux 5.1. It minimizes syscalls and context switches, and supports advanced features like buffer selection and batched submissions.
+
 
-#### I/O Wait
+#### I/O wait
 
 I/O wait is the time a CPU core spends waiting for I/O operations to complete. Tools like `pidstat`, `top`, and `iostat` can help identify storage-related CPU bottlenecks.

content/learning-paths/servers-and-cloud-computing/disk-io-benchmark/using-fio.md

@@ -10,28 +10,35 @@ layout: learningpathall
 
 You can use the same `t4g.medium` instance from the previous section with two different types of SSD-based block storage devices as shown in the console screenshot below. 
 
+### Attach and Identify Block Devices
 To add the required EBS volumes to your EC2 instance:
 
 1. In the AWS Console, navigate to **EC2** > **Volumes** > **Create Volume**.
+
 2. Create a volume with the following settings:
    - Volume Type: io2 (Provisioned IOPS SSD).
    - Size: 8 GiB.
    - IOPS: 400.
    - Availability Zone: The same as your EC2 instance
+
 3. Create another volume with the following settings:
    - Volume Type: gp2 (General Purpose SSD).
    - Size: 8 GiB.
    - Availability Zone: The same as your EC2 instance.
-4. Once created, select each volume and choose **Actions** > **Attach Volume**
-5. Select your t4g.medium instance from the dropdown and attach each volume
+
+4. Once created, select each volume and choose **Actions** > **Attach Volume**.
+
+5. Select your t4g.medium instance from the dropdown and attach each volume.
 
 Both block devices have the same 8 GiB capacity, but the `io2` is optimized for throughput, while `gp2` is general-purpose. 
 
-![EBS](./EBS.png)
+![EBS alt-text#center](./EBS.png "Multi-volume storage information.")
 
 In this section, you’ll measure real-world performance to help guide your storage selection.
 
-Flexible I/O (fio) is a command-line tool to generate a synthetic workload with specific I/O characteristics. This serves as a simpler alternative to full record and replay testing. Fio is available through most Linux distribution packages, please refer to the [documentation](https://github.com/axboe/fio) for package availability.
+Flexible I/O (fio) is a command-line tool to generate a synthetic workload with specific I/O characteristics. This serves as a simpler alternative to full record and replay testing. 
+
+Fio is available through most Linux distribution packages, see the [documentation](https://github.com/axboe/fio) for package availability.
 
 ```bash
 sudo apt update
@@ -50,7 +57,7 @@ The version is printed:
 fio-3.37
 ```
 
-## Locate device 
+## Identify Device Names for Benchmarking
 
 Fio allows you to microbenchmark either the block device or a mounted filesystem. Use the disk free, `df` command to confirm your EBS volumes are not mounted. Writing to drives containing critical data can result in data loss. In this tutorial, you're writing to blank, unmounted block devices.
 
@@ -76,15 +83,18 @@ If you have more than one block volume attached to an instance, the `sudo nvme l
 
 ## Generating a synthetic workload
 
-Suppose you want to simulate a fictional logging application with the following characteristics observed using the tools from the previous section. 
+Let’s define a synthetic workload that mimics the behavior of a logging application, using metrics observed earlier.
 
 {{% notice Workload%}}
 This workload involves light, sequential reads and writes. The system write throughput per thread is 5 MB/s with 83% writes. There are infrequent bursts of reads for approximately 5 seconds, operating at up to 16MB/s per thread. The workload can scale the infrequent reads and writes to use up to 16 threads each. The block size for the writes and reads are 64KiB and 256KiB respectively (as opposed to the standard 4KiB Page size). 
 
 Further, the application is latency sensitive and given it holds critical information, needs to write directly to non-volatile storage through direct IO. 
 {{% /notice %}}
 
-The fio tool uses simple configuration `jobfiles` to describe the characteristics of your synthetic workload. Parameters under the `[global]` option are shared among jobs. From the example below, you can create 2 jobs to represent the steady write and infrequent reads. Please refer to the official [documentation](https://fio.readthedocs.io/en/latest/fio_doc.html#job-file-format) for more details. 
+The fio tool uses simple configuration files - called `jobfiles` - to describe the characteristics of your synthetic workload. Parameters under the `[global]` option are shared among jobs. From the example below, you can create 2 jobs to represent the steady write and infrequent reads. Please refer to the official [documentation](https://fio.readthedocs.io/en/latest/fio_doc.html#job-file-format) for more details. 
+
+### Create fio Job Files
+
 
 Create two job files, one for each device, by copying the configuration below and adjusting the filename parameter (`/dev/nvme1n1` or `/dev/nvme2n1`):
 
@@ -111,17 +121,20 @@ bs=64k ; Block size of 64KiB (default block size of 4 KiB)
 name=burst_read
 rw=read
 bs=256k ; Block size of 256KiB for reads (default is 4KiB)
-startdelay=25 ; simulate infrequent reads (5 seconds out 30)
+startdelay=25 ; simulate a 5-second read burst at the end of a 30-second window
 runtime=5
 ; -- end job file including.fio --
 ```
+## Run the Benchmarks
 
 
 {{% notice Note %}}
 Running fio directly on block devices requires root privileges (hence the use of `sudo`). Be careful: writing to the wrong device can result in data loss. Always ensure you are targeting a blank, unmounted device.
 {{% /notice %}}
 
-Run the following commands to run each test back to back.  
+
+
+Run the following commands to execute each test sequentially:
 
 ```bash
 sudo NUM_JOBS=16 IO_DEPTH=64 fio nvme1.fio