SSD FTL Labs

Four labs instrumenting and analyzing the internals of an SSD inside the MQSim simulator — the flash translation layer (FTL), cached mapping table, garbage collection, and wear leveling. Each lab is my modification to MQSim's C++ core plus the workload configs and analysis scripts used to produce the results.

The changes are provided as patches against upstream MQSim rather than a full fork, so it's obvious exactly what I changed. Apply a patch on top of a clean git clone https://github.com/CMU-SAFARI/MQSim to reproduce.

Labs

workload-characterization/ — workload & cell-type analysis

Workload configs and a Python analyzer (analyze_results.py) comparing SSD behavior across read/write ratios (run_scenarios.sh sweeps read percentages from a template) and across SLC vs. TLC configurations. No core changes — driven entirely through MQSim's XML config and result analysis.

mapping-table-cache/ — cached mapping table hit rate

Instruments the page-level address-mapping unit (the FTL's DRAM-cached mapping table) to report CMT capacity, entry size, and hit/miss statistics. The patch threads a Report_results() call from SSD_Device down through Address_Mapping_Unit_Base into Address_Mapping_Unit_Page_Level.

Finding: shrinking the CMT from 2 MB to 0.5 MB collapses the hit ratio from 0.23% to 0.058% (hits 841 → 217, misses 113k → 280k) — a direct demonstration of how mapping-table cache size drives address-translation overhead. Result files for each cache size are included (result_cmt_*.xml).

gc-erase-analysis/ — GC & erase-count observation

Adds an erase-count walk over the full channel/chip/die/plane/block hierarchy in Flash_Block_Manager_Base, dumping per-block erase counts, total GC executions, and min/avg/max erase counts.

Finding: under the Greedy GC policy, max erase count (8) sits close to the average (6.99) while cold-data blocks stay at 0 erases — showing Greedy's uneven wear, which motivates wear leveling.

wear-leveling/ — wear-leveling comparison + a fix for a bug in upstream MQSim

Extends the erase-count instrumentation and compares wear-leveling behavior across GC policies (GREEDY vs. FIFO) and data-distribution patterns (STREAMING, HOTCOLD, UNIFORM), with plot_wl.py generating the comparison charts.

Bug fix: this is a fix applied in my own patch, not a contribution merged upstream. MQSim's wear-level metric returned max_erased_block - min_erased_block — the block indices, not their erase counts. The patch corrects it to return the actual erase-count difference:

// before: return max_erased_block - min_erased_block;
return plane_record->Blocks[max_erased_block].Erase_count
     - plane_record->Blocks[min_erased_block].Erase_count;

Charts for each policy/distribution combination are in this directory.

Applying a patch

git clone https://github.com/CMU-SAFARI/MQSim.git
cd MQSim
git apply /path/to/wear-leveling/mqsim-wear-leveling.patch
make
# then run with the lab's config and workload, e.g.:
./MQSim -i /path/to/wear-leveling/ssdconfig.xml -w /path/to/wear-leveling/workload.xml

Each lab directory follows the same convention: ssdconfig.xml (SSD configuration), workload.xml (I/O scenario), result*.xml (sample MQSim outputs), plus the patch and any analysis scripts. Full reports with tables and figures are in docs/.

Context

Lab work for Memory and Storage Systems at NTU (Fall 2025), taught by Prof. Yuan-Hao Chang. MQSim is a third-party simulator from CMU-SAFARI; the patches, workload configs, and analysis scripts here are my own. Cleaned up and documented for release.