EEE4775-SCNS: Massive Storage and I/O for Big Data Computing

Course Description

EEE 4775 Massive Storage and I/O for Big Data Computing addresses the part of large-scale computing that determines whether the rest of it works. Processors have grown fast; storage and the paths to it have not kept pace, and in data-intensive computing the bottleneck is almost never arithmetic. It is moving bytes.

The Statewide Course Numbering System titles the number Massive Storage and I/O for Big Data Computing and describes it as providing “a broad introduction to the fundamentals of massive file storage systems and I/O architectures in big data computing and its enabling systems infrastructure.” The statewide prerequisite is EEL 4709C Computer Design, or instructor approval.

Florida International University carries the course at 3 credits under the statewide title. FIU has a substantial systems research presence, and this course reflects it — the material is closer to current practice in large-scale infrastructure than a general computer architecture course would be.

What kind of course this is. It sits between computer architecture and operating systems, and it is a systems course: the reasoning is about latency, bandwidth, queueing, failure and cost at scale, rather than about algorithms in the abstract. Students who enjoy reasoning about where time actually goes in a real system tend to find it among the more satisfying courses in the degree.

Learning Outcomes

Required Outcomes

• Describe the storage hierarchy from registers to archival media, and quantify the latency, bandwidth, capacity and cost characteristics of each level.
• Analyse magnetic disk mechanics — seek time, rotational latency, transfer rate — and explain why access locality dominates disk performance.
• Explain flash memory and solid-state drive architecture, including the erase-before-write constraint, the flash translation layer, wear levelling, garbage collection and write amplification.
• Compare storage technologies quantitatively and select one for a stated workload and cost envelope.
• Analyse I/O architectures and interconnects — SATA, SAS, NVMe, PCIe — and explain how protocol overhead becomes the limit as media get faster.
• Analyse RAID levels for capacity efficiency, performance and fault tolerance, and compute reliability and rebuild-time exposure.
• Describe file system structure — inodes, allocation strategies, metadata, journalling — and explain the consistency guarantees each provides.
• Describe distributed and parallel file systems (HDFS, Lustre, Ceph, GPFS) and their design trade-offs.
• Explain replication and erasure coding, and compare them on storage overhead, repair cost and durability.
• Explain the CAP theorem and consistency models, and identify which model a given system provides.
• Analyse caching and buffering strategies, including replacement policies, prefetching and write-back versus write-through.
• Characterise an I/O workload and use the characterisation to predict or explain system performance.
• Measure and benchmark storage system performance, and interpret the results critically.

Optional Outcomes

• Analyse object storage systems and their APIs.
• Analyse key-value stores and log-structured merge trees.
• Analyse the I/O behaviour of big data frameworks (MapReduce, Spark) and their shuffle stages.
• Analyse persistent memory and storage-class memory and their programming models.
• Analyse computational storage and near-data processing.
• Analyse data centre storage economics, power and total cost of ownership.
• Analyse storage security, encryption at rest, and secure deletion.
• Complete a project measuring or optimising a real storage or I/O system.

Major Topics

Required Topics

• The storage hierarchy and the I/O gap — latency and bandwidth at each level, the widening gap between processor and storage performance, Amdahl’s law applied to I/O, and why data movement dominates cost and energy at scale.
• Magnetic disk technology — mechanics and geometry, seek and rotational latency, transfer rate, disk scheduling algorithms, sequential versus random access, and shingled magnetic recording.
• Flash and solid-state storage — NAND organisation, SLC/MLC/TLC/QLC trade-offs, the read/program/erase asymmetry, the flash translation layer, wear levelling, garbage collection, write amplification, over-provisioning and endurance.
• I/O architecture and interconnects — the I/O path from application through system call, page cache, block layer, driver and controller to media; SATA, SAS, NVMe and PCIe; interrupt versus polling; DMA; and protocol overhead as the emerging bottleneck.
• RAID and redundancy — levels 0, 1, 5, 6 and 10; striping, mirroring and parity; write penalties; rebuild time and the exposure window; and the reliability arithmetic that makes RAID 5 inadequate at modern drive capacities.
• File systems — directory and inode structure, block allocation (contiguous, linked, indexed, extent-based), free space management, metadata, journalling and copy-on-write, crash consistency, and the durability guarantees of fsync.
• Distributed and parallel file systems — the architecture of HDFS (namenode/datanode, block replication, rack awareness), Lustre and GPFS in high-performance computing, Ceph and object-based storage; metadata scalability as the recurring hard problem.
• Replication, erasure coding and durability — n-way replication versus Reed–Solomon coding, storage overhead against repair bandwidth, durability calculations, and correlated failure.
• Consistency and the CAP theorem — strong, eventual and causal consistency; quorum systems; the practical consequences of each choice for application design.
• Caching and buffering — the page cache, replacement policies (LRU, LFU, ARC, CLOCK), prefetching and readahead, write-back versus write-through, and multi-tier caching with flash as a cache for disk.
• Workload characterisation — read/write ratio, sequential versus random, request size distribution, access locality, burstiness, and the use of traces.
• Measurement and benchmarking — IOPS, throughput and latency percentiles; why tail latency matters more than mean latency at scale; benchmarking pitfalls including cache effects and insufficient run length.

Optional Topics

• Object storage and S3-style interfaces; content-addressable storage.
• Key-value stores, LSM trees, compaction, and read/write amplification trade-offs.
• Big data frameworks: MapReduce and Spark I/O behaviour, shuffle, data locality scheduling.
• Persistent memory, storage-class memory, and crash-consistent programming.
• Computational storage and near-data processing.
• Data centre storage economics, power, cooling and total cost of ownership.
• Storage security: encryption at rest, key management, secure erase, and integrity verification.
• Deduplication and compression.

Resources & Tools

• Operating Systems: Three Easy Pieces (Arpaci-Dusseau and Arpaci-Dusseau) is free online and its persistence section is the best available treatment of disks, RAID, file systems and journalling at this level. It is the single most useful reference for this course.
• Computer Architecture: A Quantitative Approach (Hennessy and Patterson) supplies the storage and I/O chapters and the quantitative method the course uses.
• Designing Data-Intensive Applications (Martin Kleppmann) is the standard modern reference for replication, partitioning, consistency and the CAP material, and is widely read in industry.
• Storage Systems: Organization, Performance, Coding, Reliability and Their Data Processing (Thomasian) is a comprehensive academic reference where more depth is needed.
• Benchmarking and measurement tools — fio (the standard flexible I/O tester), iostat, blktrace, perf, IOzone and FileBench. Learning to drive fio properly is a directly marketable skill.
• Systems to experiment with — Linux with its various file systems (ext4, XFS, Btrfs, ZFS), Hadoop/HDFS, Ceph, MinIO, and Spark. Most can be run in containers on a laptop for coursework.
• Traces and datasets — the SNIA IOTTA trace repository is the standard public source of real storage workload traces and is the right basis for a workload-characterisation project.
• Reference material — the USENIX FAST (File and Storage Technologies) conference is the field’s principal venue and its proceedings are freely available; also USENIX ATC and OSDI, the SNIA technical library, and ACM Transactions on Storage.

Career Pathways

• Storage engineer and storage systems engineer (SOC 15-1244, Network and Computer Systems Administrators; SOC 15-1252, Software Developers) — the direct destination.
• Site reliability engineer and infrastructure engineer — roles in which understanding where I/O latency comes from is a daily requirement and a genuine differentiator.
• Systems software engineer — file systems, storage drivers, database storage engines.
• Data engineer — building and operating the pipelines that big data frameworks run on, where I/O behaviour determines cost.
• Cloud infrastructure engineer at a hyperscale provider; performance engineer.
• Database internals engineer — storage engines are where database performance is won or lost, and the LSM-tree and buffer-management material maps onto that work directly.
• Firmware engineer at a storage vendor — SSD controller and flash translation layer development, a substantial employment category at Micron, Western Digital, Seagate, Samsung and Kioxia.
• Employers include the hyperscale cloud providers (Amazon Web Services, Google, Microsoft, Meta), storage vendors (NetApp, Pure Storage, Dell EMC, Western Digital, Micron), and database and data-platform companies. In Florida: Amazon and Google have engineering presence in the state, Citrix/Cloud Software Group (Fort Lauderdale), Chewy and Carnival (Miami) run substantial data platforms, NextEra Energy operates large-scale data infrastructure, and the Miami financial and logistics sector employs data engineers heavily. ⚠ Deep storage-systems roles are concentrated at a modest number of companies, most outside Florida, but the infrastructure and SRE skills transfer very broadly — and this specialisation is notably amenable to remote work.

Special Information

⚠⚠ The number collision — what to do about it

As stated at the top of this guide, EEE 4775 carries two unrelated subjects in Florida:

	Statewide / FIU	UCF
Title	Massive Storage and I/O for Big Data Computing	Real-Time Systems
Subject	Storage hierarchies, file systems, distributed storage, I/O performance	Real-time scheduling theory, timing analysis, RTOS design
Prerequisite	EEL 4709C Computer Design, or instructor approval	COP 4600, EEL 4768 or EEL 4742C

These are not variants of one another. They share no significant content, no textbook and no professional skill set. The statewide record and FIU agree with each other, which is why this page carries the -SCNS designation and describes their reading.

Consequences to act on:

• A transfer evaluator matching on the number alone cannot distinguish them. If you took the storage course and a receiving programme credits you with real-time systems (or the reverse), the error will be invisible until it matters.
• State the title and carry the syllabus. On a transcript this number is ambiguous, and only the institution and the syllabus disambiguate it.
• If a degree requirement names EEE 4775, confirm which subject the requirement means before assuming your course satisfies it.
• SCNS “guaranteed transfer to an institution offering the same course” is doing no useful work here, because the two institutions offering this number are not offering the same course.

Prerequisites

The statewide prerequisite is EEL 4709C Computer Design, or instructor approval. What it stands for is a working understanding of computer organisation: memory hierarchy, buses, interrupts and DMA. Without it, the I/O path discussion has nothing to attach to.

⚠ Two requirements the prerequisite does not name. First, operating systems concepts — file systems, the page cache, system calls and the block layer are operating-system machinery, and a student who has not taken an operating systems course will be learning that material concurrently. Second, comfort with the command line and with Linux, since the measurement and benchmarking work is done there. Neither is difficult to acquire, but both are assumed from the first weeks.

The instructor-approval route is genuinely used and is worth taking up if you have equivalent background from an operating systems or computer architecture course.

⚠ Course-code variation across Florida

Storage and I/O systems is offered narrowly at undergraduate level in Florida:

• EEE 4775 — FIU (this subject) and UCF (a different subject entirely).
• Comparable material appears inside operating systems courses (COP 4600) and computer architecture courses (EEL 4768, CDA prefix) at most institutions, but rarely as a dedicated course.
• Distributed systems and big data courses under COP and CIS prefixes cover overlapping ground.

SCNS equivalency does not cross course numbers or prefixes. Expect this course to articulate as a technical elective rather than as a named requirement. Carry the syllabus, and keep any measurement or benchmarking project — it is concrete evidence of a skill that employers ask about directly.

Position in the curriculum

EEE 4775 is a senior-level elective following computer design. It complements operating systems and computer architecture coursework by going deep on the one subsystem those courses treat briefly, and it supports work in databases, distributed systems and data engineering.

Difficulty and time commitment

The conceptual content is moderate; the difficulty is in measurement. Storage performance is unusually hard to measure honestly: caches at several layers hide the media, short benchmark runs measure the cache rather than the device, and a result that looks clean is usually a result that measured the wrong thing. Learning to design a valid experiment is the real skill of the course, and it takes iterations.

Plan on eight to ten hours a week, more where a measurement project is set — benchmark runs take real wall-clock time and cannot be compressed.

Articulation and transfer

The course is upper-division, carries 3 credits, and has no general-education or Gordon Rule designation.

FE exam relevance

The NCEES Fundamentals of Engineering (Electrical and Computer) exam covers computer systems including memory hierarchy at a general level, but does not test storage systems specifically. This is an elective taken for its own value and for employability.

AI Integration

Storage and I/O sits underneath machine learning rather than alongside it, and that relationship is worth making explicit because students rarely see it.

Where the relationship is real and increasingly central. Training a large model is frequently I/O bound rather than compute bound: expensive accelerators sit idle waiting for training data, and the data pipeline — storage, network, decode, augmentation — is what determines utilisation. Checkpointing a large model writes enormous files under a tight time budget. Serving a model requires loading weights fast enough to meet a latency target. The skills in this course are directly on the critical path of machine learning infrastructure, which is a strong and under-appreciated career position: there are far more people who can train a model than who can make the storage feed it.

Machine learning is also used inside storage systems — for cache replacement and prefetch prediction, for tiering decisions between flash and disk, for failure prediction from SMART data, and for workload classification. These are real deployed applications, and learned index structures are an active research direction.

Where a general-purpose assistant helps in coursework. Explaining write amplification or why RAID 5 has a write penalty; generating fio job files, which are fiddly and poorly documented; interpreting iostat and blktrace output; writing analysis and plotting scripts for benchmark results; and explaining the field’s dense acronym vocabulary.

⚠ Where it fails, and why the failure is exactly this course’s subject. The characteristic error of an AI tool asked a storage question is to quote performance figures — IOPS, throughput, latency — with no workload, queue depth, block size or access pattern attached. That is precisely the misunderstanding the course exists to remove. A device rated at “500,000 IOPS” achieves that at 4 KB random reads at queue depth 32 and nothing like it at queue depth 1, or at 1 MB writes, or with a mixed read/write workload. A storage performance number without its workload is meaningless, and it is exactly the kind of number a confident generated answer supplies.

A second failure follows directly: models will produce benchmark configurations that measure the page cache rather than the device — omitting direct=1, using a working set smaller than RAM, or running for too few seconds to reach steady state on an SSD. All three produce impressive and meaningless results, and none of them errors. Designing a valid storage measurement is the core skill of this course, and generated benchmark configurations reliably get it wrong in the flattering direction.

Third: models tend to reason about mean latency when tail latency is what matters. At scale, a request that fans out to a hundred servers is as slow as the slowest of them, so the 99th percentile governs user-visible performance. This is a foundational idea in modern systems practice and it is largely absent from textbook-level generated answers.

The engineer’s responsibility. A storage performance claim is a claim about how a system will behave under a real workload, and capacity planning and purchasing decisions rest on it. The discipline is to state the workload with every number. The habit worth forming is to ask of any storage figure: what block size, what queue depth, what read/write mix, what working set relative to cache, and measured over how long? A number without those is not evidence.

Academic integrity. FIU maintains an academic integrity policy covering AI-generated work, and practice varies by instructor. Analysis and experimental design are normally expected to be your own even where scripting assistance is permitted. Generated benchmark results are data fabrication — treated more seriously than plagiarism, and in a measurement-based course a direct rehearsal of professional misconduct. Ask before you rely on a tool, and disclose its use where the syllabus requires it.