Discussion 11: Designing Storage for a Workload

01 Overview

Course	COMP 3150 / CMIS 3150 — Operating Systems
Unit	Unit 11 — I/O and Storage Management
Weight	Part of the 5% participation grade (each discussion is worth approximately 0.4% of the final grade)
Opens	Monday of Week 11
Initial post due	Thursday of Week 11, 23:59
Peer replies due	Sunday of Week 11, 23:59
Format	One initial post (550–700 words, including a comparison table) and at least two substantive peer replies (150–250 words each)
CLOs assessed	CLO5, CLO6, CLO7

02 Learning outcomes addressed

By participating in this discussion you will

Describe I/O hardware, interrupts, and DMA (U11.1–U11.3).
Explain the role of the device driver and the block layer (U11.4).
Compare disk-scheduling algorithms and their suitability for different workloads (U11.5).
Compare RAID levels and evaluate their capacity, redundancy, and performance trade-offs (U11.6).
Explain SSD architecture and the read/write asymmetry of flash (U11.7).
Recommend a storage architecture for a given workload and justify it with metrics (U11.6, U11.7).

This discussion assesses CLO5 (explain storage and I/O management), CLO6 (apply Linux tools), and CLO7 (evaluate operating-system technologies).

03 Discussion prompt

The scenario

You are the storage architect for a small hosting provider. The provider is about to acquire hardware for three new customers. Each customer has a distinct workload, and each has a budget. You must recommend a storage design for each.

Customer A — Online transaction processing (OLTP) database. A moderate-size relational database (a few hundred gigabytes) serving an e-commerce application. The workload is dominated by small, random reads (lookups by primary key) and small, synchronous random writes (committed transactions). Latency is critical: the service-level objective is a 99th-percentile latency of under 10 ms per transaction. Data loss is unacceptable.
Customer B — Video streaming archive. A library of high-definition video files (tens of terabytes) served to viewers over HTTP. The workload is dominated by large, sequential reads. Writes are infrequent (new content is uploaded in batches). Throughput is critical; individual request latency matters less.
Customer C — Machine-learning training platform. A shared environment in which data scientists submit training jobs. Each job reads a training dataset (tens to hundreds of gigabytes) and writes checkpoints (a few hundred megabytes each) periodically. The workload is mixed: large sequential reads during the training phase, small random writes during checkpointing, and occasional large sequential writes when a new dataset is uploaded. Throughput and capacity matter more than latency.

The provider's hardware options are:

NVMe SSDs (fast, expensive, small capacity).
SATA SSDs (moderate performance, moderate price, moderate capacity).
10K RPM SAS hard drives (moderate performance, low price, high capacity).
7200 RPM SATA hard drives (low performance, very low price, very high capacity).

Each customer's storage must be configured as a RAID array (or a single disk if you can justify it) with a suitable RAID level, a suitable I/O scheduler, and a suitable caching strategy.

Your task

Recommend a design for each customer. For each, specify:
- The media (NVMe SSD, SATA SSD, or HDD).
- The RAID level (0, 1, 5, 6, 10, or none), with the number of disks and the usable capacity.
- The I/O scheduler (none, mq-deadline, bfq, kyber).
- The caching strategy (write-back, write-through, or direct I/O), and the cache size.
Justify each choice with reference to the workload's metrics. For Customer A, the metric is 99th-percentile latency. For Customer B, it is sequential read throughput. For Customer C, it is combined throughput and capacity. Explain why your design is appropriate for the metrics that matter and, just as important, why the alternatives are less appropriate.
Analyse the trade-offs. For each design, state:
- What you are optimising for.
- What you are willing to give up.
- What the approximate cost per terabyte is (you may estimate).
- What the failure mode is — what happens if one disk fails, and how long a rebuild takes.
Present the comparison. Include a table with one row per customer and columns for the media, RAID level, scheduler, caching, and the estimated throughput and capacity.
Reflect on one specific trade-off. Choose one trade-off that you made in one of the designs (for example, choosing RAID 10 over RAID 5 for the database, or choosing HDDs over SSDs for the archive) and explain why you chose as you did. What would change your decision? At what point would you switch to the other option?

Your post should be 550–700 words, with the comparison table included. Cite at least one source (a textbook section, a vendor's performance documentation, or a paper on RAID or SSD performance) that supports one of your recommendations.

04 Notes on the design decisions

4.1 Media selection

The three media differ in three dimensions: latency, throughput, and cost per terabyte. NVMe SSDs have microsecond latency and GB/s throughput but cost many times more per terabyte than HDDs. HDDs have millisecond latency (dominated by seek and rotation) but cost little per terabyte. SATA SSDs sit in the middle. The right choice depends on which dimension the workload is sensitive to: a workload with small random I/O is sensitive to latency and benefits from SSDs; a workload with large sequential I/O is sensitive to throughput and can be served by HDDs; a workload with a mixture may need both (a tiered design).

4.2 RAID level selection

RAID 1 (mirroring) and RAID 10 (a stripe of mirrors) provide strong redundancy and good write performance but use half the disks for redundancy. RAID 5 and 6 use less capacity for redundancy but suffer the small-write penalty: a random write requires a read-modify-write of the data and parity blocks, which for RAID 5 is four I/Os and for RAID 6 is six. RAID 5 and 6 are therefore poor choices for write-intensive random workloads, even though they look attractive on capacity. RAID 0 provides no redundancy and is appropriate only for scratch space or caches that can be rebuilt.

4.3 I/O scheduler selection

The Linux kernel offers several I/O schedulers: none (no scheduling; the request queue is passed to the device in arrival order), mq-deadline (a deadline-based scheduler with separate read and write queues), bfq (a budget fair-queueing scheduler with good interactive latency), and kyber (a lightweight scheduler designed for fast devices). For NVMe SSDs, the none scheduler is often best because the device's internal parallelism makes host-side reordering unnecessary. For HDDs, a deadline-based scheduler reduces head movement and bounds latency. For a workstation with mixed interactive and background workloads, bfq can provide better responsiveness.

4.4 Caching strategy

The kernel's page cache absorbs reads and buffers writes. For a database that requires durability, write-through (or explicit fsync) is necessary; write-back is faster but loses data on power loss unless the device has a battery-backed cache. For a video archive, write-back is fine because the content is written in large batches and a small loss on power failure is acceptable. Direct I/O (O_DIRECT) bypasses the cache entirely, which is useful for databases that manage their own caching.

4.5 Cost

Storage cost is dominated by the media. Roughly, as of the time of writing, NVMe SSDs cost several times more per terabyte than SATA SSDs, which cost several times more than HDDs. A design that uses SSDs for hot data and HDDs for cold data (tiering) can achieve most of the performance of an all-SSD design at a fraction of the cost.

05 Grading rubric

The discussion is marked out of 100 points. The criteria and their weights are given below.

Discussion 11 grading rubric — weights
Criterion	Weight
Post quality (design, justification, trade-offs)	40%
Peer response quality	30%
Engagement and timeliness	20%
Netiquette and clarity	10%

5.1 Post quality (40 points)

Level	Descriptor
Exemplary (90–100%)	A clear design for each customer, with all four decisions specified (media, RAID, scheduler, caching). The justification references the metrics that matter for each workload. The trade-offs are analysed in detail, including the failure mode and the cost. The comparison table is complete. The reflection on one trade-off is insightful and states what would change the decision. Sources are cited.
Proficient (80–89%)	A clear design for each customer with all four decisions specified. The justification references the metrics. The trade-offs are mentioned but not analysed in detail. The reflection is present but brief.
Developing (70–79%)	A design is proposed for each customer, but one or two decisions are missing (for example, the scheduler is not specified). The justification is general and does not reference the metrics. The trade-offs and the reflection are superficial.
Beginning (60–69%)	A design is proposed for only one or two customers, or the decisions are not justified. The post is a list of preferences without reasoning.
Not demonstrated (<60%)	The post is missing, off-topic, or a restatement of the prompt without a design.

5.2 Peer response quality (30 points)

The descriptors are the same as for Discussion 1. An exemplary reply might challenge a RAID choice with a concrete argument, suggest a tiered design for a customer, or identify a metric the classmate did not consider.

5.3 Engagement and timeliness (20 points)

The descriptors are the same as for Discussion 1.

5.4 Netiquette and clarity (10 points)

The descriptors are the same as for Discussion 1.

06 Resources

Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 12 (I/O Systems) and Chapter 11 (Mass-Storage Structure).
Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapters 36–38 (I/O Devices, Hard Disk Drives, RAID).
Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 5 (Input/Output).
Patterson, D. A., Gibson, G., & Katz, R. H. A Case for Redundant Arrays of Inexpensive Disks (RAID). ACM SIGMOD, 1988.
Agrawal, N., et al. Design Tradeoffs for SSD Performance. USENIX ATC, 2008.
Gregg, B. Systems Performance, 2nd ed., Chapter 8 (Disks) and Chapter 9 (Network).
Linux kernel documentation: Documentation/block/ (the block layer and the schedulers).
Linux man-pages: man 8 iostat, man 1 fio, man 8 lsblk, man 8 mdadm.