final review

Author: Your Name

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

@@ -6,7 +6,7 @@ minutes_to_complete: 30
 who_is_this_for: A cloud developer who wants to optimise storage cost or performance of their application. Developers who want to uncover potential storage-bound bottlenecks or changes when migrating an application to a different platform. 
 
 learning_objectives: 
-    - Understand basic data flow for storage devices 
+    - Understand the flow of data for storage devices 
     - Use basic observability utilities such as iostat, iotop and pidstat
     - Understand how to run fio for microbenchmarking a block storage device
 

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

@@ -16,7 +16,7 @@ The basic attributes of a given workload are the following.
 - Read to Write Ratio
 - Random vs Sequential access
 
-The characteristics of many real-world workloads will vary over time, for example an application that periodically flushes writes to disk. Further, the system-wide and process-specific characteristics may be significantly differently. 
+There are many more characteristics to observe, just as latency but since this is an introductory topic we will mostly stick to the high-level metrics listed above. 
 
 ## Running an Example Workload
 
@@ -38,7 +38,7 @@ 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. We use the `-flush_packets` flag to write each chunk of video back to storage.  
+Run the following command to begin transcoding the video and audio using the `H.264` and `aac` transcoders respectively. We use the `-flush_packets` flag to write each chunk of video back to storage from memory.   
 
 ```bash
 ffmpeg -i BigBuckBunny.mp4 -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k -flush_packets 1 output_video.mp4
@@ -51,7 +51,7 @@ Whilst the transcoding is running, we can use the `pidstat` command to see the d
 ```bash
 pidstat -d -p $(pgrep ffmpeg) 1
 ```
-Since this example `151MB` video  fits within memory, we observe no `kB_rd/s` for the storage device. However, since we are flushing to storage we observe ~275 `kB_wr/s` for this specific process.  
+Since this example `151MB` video  fits within memory, we observe no `kB_rd/s` for the storage device after the initial read. However, since we are flushing to storage we observe period ~275 `kB_wr/s`.  
 
 ```output
 Linux 6.8.0-1024-aws (ip-10-248-213-118)        04/15/25        _aarch64_       (2 CPU)
@@ -111,7 +111,7 @@ nvme0n1          0.66     29.64     0.24  26.27    0.73    44.80    2.92    203.
 
 ### Basic Characteristics of our Example Workload
 
-This is a simple transcoding workload with flushed writes, where most data is processed and stored in memory. Disk I/O is minimal, with an IOPS of just 3.81, low throughput (248.71 kB/s), and an average IO depth of 0.01 — all indicating very low disk utilization. The 52% write merge rate and low latencies further suggest sequential, infrequent disk access, reinforcing that the workload is primarily memory-bound.
+This is a simple transcoding workload with flushed writes, where most data is processed and stored in memory. Disk I/O is minimal, with an IOPS of just 3.81, low throughput (248.71 kB/s), and an average IO depth of 0.01 — all summarised in very low disk utilization. The 52% write merge rate and low latencies further suggest sequential, infrequent disk access, reinforcing that the workload is primarily memory-bound.
 
 
 | Metric             | Calculation Explanation                                                                                     | Value         |

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

@@ -8,15 +8,14 @@ layout: learningpathall
 
 ## Introduction
 
-The ideal storage activity of your system is 0. In this situation all of your applications data and instructions are available in memory or caches and no reads or writes to a spinning hard-disk drive or solid-state SSD are required. However, due to physical capacity limitations, data volatility and need to store large amounts of data, many applications require frequent access to storage media. 
+The ideal storage activity of your system is 0. In this situation all of your application data and instructions are available in memory or caches with no reads or writes to a spinning hard-disk drive or solid-state SSD required. However, due to physical capacity limitations, data volatility and need to store large amounts of data, many applications require frequent access to storage media. 
 
 ## High-Level Flow of Data
 
-The diagram below is a high-level overview of how data can be written or read from a storage device.  This diagram illustrates a multi-disk I/O architecture where each disk (Disk 1 to Disk N) has an I/O queue and optional disk cache, communicating with a central CPU via a disk controller. Memory is not explicitly shown but typically resides between the CPU and storage, offering faster access times than disk but is volatile. File systems, though not depicted, operate at the OS/kernel level to handling file access metadata and offer a familiar way to interact with files and directories. In NVMe-based systems, the disk controller is located on the drive itself, reducing latency and improving parallelism.
+The diagram below is a high-level overview of how data can be written or read from a storage device.  This diagram illustrates a multi-disk I/O architecture where each disk (Disk 1 to Disk N) has an I/O queue and optional disk cache, communicating with a central CPU via a disk controller. Memory is not explicitly shown but resides between the CPU and storage, offering fast access times with the tradeoff of volatile. File systems, though not depicted, operate at the OS/kernel level to handling file access metadata and offer a friendly way to interact through files and directories.
 
 ![disk i/o](./diskio.jpeg)
 
-Many techniques are transparent to a developer. The queue at the operating system level and disk level may reorder I/O requests to improve efficiency (for example an atomic write that increments a value by 1 followed by a minus by 1). 
 
 ## Key Terms
 
@@ -32,7 +31,7 @@ IOPS is a measure of how much random read or write requests your storage system
 ![iops_hdd](./IOPS.png)
 
 #### Throughput / Bandwidth
-Throughput is the data transfer rate normally in MB/s. IOPS x block size is the bandwidth utilisation of your system. Max throughput is usually reached for sequential access patterns.
+Throughput is the data transfer rate normally in MB/s with bandwidth specifying the maximum amount that a connection can transfer. IOPS x block size can be used to calculate the storage throughput of your application.
 
 #### Queue Depth
 Queue depth refers to the number of simultaneous I/O operations that can be pending on a device. Consumer SSDs might typically have a queue depth in the range of 32 to 64, whereas enterprise-class NVMe drives can support hundreds or even thousands of concurrent requests per queue. This parameter affects how much the device can parallelize operations and therefore influences overall I/O performance.

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

@@ -8,7 +8,7 @@ layout: learningpathall
 
 ## Setup and Install Fio
 
-I will be using the same `t4g.medium` instance from the previous section with 2 different types of SSD-based block storage devices as per the console screenshot below. Both block devices have the same, 8GiB capacity but the `io1` is geared towards I/O as opposed to the general purpose SSD `gp2`. In this section we want to observe what the real-world performance for our workload is so that it can inform our selection.
+I will be using the same `t4g.medium` instance from the previous section with 2 different types of SSD-based block storage devices as per the console screenshot below. Both block devices have the same, 8GiB capacity but the `io1` is geared towards throughput as opposed to the general purpose SSD `gp2`. In this section we want to observe what the real-world performance for our workload is so that it can inform our selection.
 
 ![EBS](./EBS.png)
 
@@ -31,9 +31,9 @@ fio-3.36
 
 ## Locate Device 
 
-`Fio` allows us to microbenchmark either the block device or a mounted filesystem. The disk free, `df` command to confirm our EBS volumes are not mounted.
+`Fio` allows us to microbenchmark either the block device or a mounted filesystem. The disk free, `df` command to confirm our EBS volumes are not mounted. Writing to drives that hold critical information may cause issues. Hence we are writing to blank, unmounted block storage device.
 
-Using the `lsblk` command to view the EBS volumes attached to the server (`nvme1n1` and `nvme2n1`). The immediate number appended to `nvme`, e.g., `nvme0`, shows it is a physically separate device. `nvme1n1` corresponds to the faster `io2` block device and `nvme2n1` corresponds to the slower `gp3` block device. 
+Using the `lsblk` command to view the EBS volumes attached to the server (`nvme1n1` and `nvme2n1`). The immediate number appended to `nvme`, e.g., `nvme0`, shows it is a physically separate device. `nvme1n1` corresponds to the faster `io2` block device and `nvme2n1` corresponds to the slower `gp2` block device. 
 
 ```bash
 lsblk -e 7
@@ -58,9 +58,9 @@ If you have more than 1 block volumes attached to an instance, the `sudo nvme li
 Let us say we want to simulate a fictional logging application with the following characteristics observed using the tools from the previous section. 
 
 {{% notice Workload%}}
-The logging workload has a light sequential read and write workload. 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 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). 
+The logging workload has light sequential read and write characteristics. 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 sensitive to latency and since it holds critical information, needs to write directly to non-volatile storage (directIO). 
+Further, the application 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 characterisics of your synthetic workload. Parameters under the `[global]` option are shared among jobs. From the example below, we have created 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.