校正语法错误之前

bib/references.bib

@@ -548,4 +548,27 @@
 	number       = {2},
 	pages        = {49--60},
 	year         = {2016}
-}
+}
+
+@ARTICLE{Wang26RethinkingTuning,
+	author={Zhang, Wang and Wang, Hongyu and Shi, Zhan and Wu, Yutong and Li, Mingjin and Li, Tingfang and Wang, Fang and Feng, Dan},
+	journal={IEEE Transactions on Parallel and Distributed Systems}, 
+	title={Rethinking Parameter Tuning in Distributed Storage Systems via Knowledge Graph Query}, 
+	year={2026},
+	volume={37},
+	number={3},
+	pages={633-650},
+	keywords={Tuning;Knowledge graphs;Adaptation models;System performance;Costs;Convergence;Bayes methods;Manuals;Accuracy;Real-time systems;Distributed storage systems;automated parameter tuning;knowledge graph–based tuning;dynamic workload adaptation},
+	doi={10.1109/TPDS.2025.3650593}}
+	
+@ARTICLE{Peng26IOsurvey,
+	author={Peng, Jingxian and Yang, Lihua and Wu, Huijun and Zhang, Wenzhe and Wu, Zhenwei and Zhang, Wei and Li, Jiaxin and Dai, Yiqin and Dong, Yong},
+	journal={IEEE Transactions on Parallel and Distributed Systems}, 
+	title={A Survey on Machine Learning-Based HPC I/O Analysis and Optimization}, 
+	year={2026},
+	volume={37},
+	number={3},
+	pages={618-632},
+	keywords={Optimization;Surveys;Taxonomy;Libraries;Computer architecture;Soft sensors;Mathematical models;File systems;Data models;Servers;High performance computing(HPC);I/O;machine learning(ML);I/O analysis;I/O optimization},
+	doi={10.1109/TPDS.2025.3639682}}
+

mySkyline-v7.5.aux

@@ -33,15 +33,17 @@
 \citation{WangK16MVOCC}
 \citation{Hong25HDCC}
 \citation{Wu25OOCC}
+\citation{Peng26IOsurvey}
 \citation{Chen21Tuning1}
 \citation{Bez20TuningLayer}
 \@writefile{toc}{\contentsline {section}{\numberline {2}Related Work}{2}{}\protected@file@percent }
 \newlabel{sec:RW}{{2}{2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}I/O-Efficient Spatio-Temporal Query Processing}{2}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}I/O-Efficient Spatio-Temporal Retrieval Processing}{2}{}\protected@file@percent }
 \@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Concurrency Control}{2}{}\protected@file@percent }
 \@writefile{toc}{\contentsline {subsection}{\numberline {2.3}I/O Performance Tuning in Storage Systems}{2}{}\protected@file@percent }
 \citation{Behzad13HDF5}
 \citation{Rajesh24TunIO}
+\citation{Wang26RethinkingTuning}
 \@writefile{toc}{\contentsline {section}{\numberline {3}Definition}{3}{}\protected@file@percent }
 \newlabel{sec:DF}{{3}{3}}
 \newlabel{eqn:pre_rs}{{1}{3}}
@@ -51,171 +53,114 @@
 \@writefile{toc}{\contentsline {section}{\numberline {4}I/O-aware Indexing stucture}{3}{}\protected@file@percent }
 \newlabel{sec:Index}{{4}{3}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Index schema design}{3}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Index schema design.}}{4}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Index schema design}}{4}{}\protected@file@percent }
 \newlabel{fig:index}{{1}{4}}
-\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Query-time Execution}}{4}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Retrieval-time Execution}}{4}{}\protected@file@percent }
 \newlabel{fig_ST_Query}{{2}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Query-time Execution}{4}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Retrieval-time Execution}{5}{}\protected@file@percent }
 \newlabel{eqn_pre_spatial_query}{{5}{5}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.3}Why I/O-aware}{5}{}\protected@file@percent }
 \@writefile{toc}{\contentsline {section}{\numberline {5}Hybrid Concurrency-Aware I/O Coordination}{5}{}\protected@file@percent }
 \newlabel{sec:CC}{{5}{5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Query Admission and I/O Plan Generation}{5}{}\protected@file@percent }
 \citation{Hong25HDCC}
 \@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Hybrid Concurrency-Aware I/O Coordination.}}{6}{}\protected@file@percent }
 \newlabel{fig:cc}{{3}{6}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Retrieval Admission and I/O Plan Generation}{6}{}\protected@file@percent }
 \newlabel{eq:io_plan}{{6}{6}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Contention Estimation and Path Selection}{6}{}\protected@file@percent }
 \newlabel{eqn_tuning_table}{{7}{6}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Deterministic Coordinated and Non-deterministic Execution}{6}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Optimistic Read Execution and Completion}{6}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Optimistic Read Execution and Completion}{7}{}\protected@file@percent }
 \@writefile{toc}{\contentsline {section}{\numberline {6}I/O Stack Tuning}{7}{}\protected@file@percent }
 \newlabel{sec:Tuning}{{6}{7}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {6.1}Formulation of Online I/O Tuning}{7}{}\protected@file@percent }
 \newlabel{eqn_tuning_table}{{8}{7}}
 \newlabel{eqn_tuning_table}{{9}{7}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Surrogate-Assisted GMAB for Online I/O Tuning}{7}{}\protected@file@percent }
-\@writefile{loa}{\contentsline {algocf}{\numberline {1}{\ignorespaces Surrogate-Assisted Genetic Multi-Armed Bandit (SA-GMAB)}}{7}{}\protected@file@percent }
-\newlabel{alg:sa-gmab}{{1}{7}}
+\@writefile{loa}{\contentsline {algocf}{\numberline {1}{\ignorespaces Surrogate-Assisted Genetic Multi-Armed Bandit (SA-GMAB)}}{8}{}\protected@file@percent }
+\newlabel{alg:sa-gmab}{{1}{8}}
+\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Dataset Statistics}}{8}{}\protected@file@percent }
+\newlabel{table_dataset}{{1}{8}}
 \@writefile{toc}{\contentsline {section}{\numberline {7}Performance Evaluation}{8}{}\protected@file@percent }
 \newlabel{sec:EXP}{{7}{8}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {7.1}Experimental Setup}{8}{}\protected@file@percent }
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {7.1.1}Dataset}{8}{}\protected@file@percent }
-\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Dataset Statistics}}{8}{}\protected@file@percent }
-\newlabel{table_dataset}{{1}{8}}
-\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Cluster Configurations}}{8}{}\protected@file@percent }
-\newlabel{table_config}{{2}{8}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.1.2}Query Workload}{8}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.1.3}Experimental Environment}{8}{}\protected@file@percent }
-\newlabel{sec_exp_env}{{7.1.3}{8}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Evaluating the data indexing structure}{8}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.1}I/O Selectivity Analysis}{8}{}\protected@file@percent }
-\newlabel{sec:Index_exp_1}{{7.2.1}{8}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.1.2}Retrieval Workload}{8}{}\protected@file@percent }
+\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Cluster Configurations}}{9}{}\protected@file@percent }
+\newlabel{table_config}{{2}{9}}
 \newlabel{fig:index_exp1_1}{{7.2.1}{9}}
 \newlabel{fig:index_exp1_2}{{7.2.1}{9}}
-\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces The computing cost of spatial-keyword skylines}}{9}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {I/O Selectivity}}}{9}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {[Unnecessary data fraction}}}{9}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces The efficiency of I/O selectivity}}{9}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Query footprint ratios}}}{9}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Query spatial extents}}}{9}{}\protected@file@percent }
 \newlabel{fig:index_exp1}{{4}{9}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.1.3}Experimental Environment}{9}{}\protected@file@percent }
+\newlabel{sec_exp_env}{{7.1.3}{9}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Evaluating the data indexing structure}{9}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.1}I/O Selectivity Analysis}{9}{}\protected@file@percent }
+\newlabel{sec:Index_exp_1}{{7.2.1}{9}}
 \newlabel{fig:index_exp2_1}{{7.2.2}{9}}
 \newlabel{fig:index_exp2_2}{{7.2.2}{9}}
-\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces End-to-End Query Latency}}{9}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {The query latency}}}{9}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Latency Breakdownn}}}{9}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces End-to-End retrieval latency and latency breakdown}}{9}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Query footprint ratios}}}{9}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Various baselines}}}{9}{}\protected@file@percent }
 \newlabel{fig:index_exp2}{{5}{9}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.2}End-to-End Query Latency}{9}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.2}End-to-End Retrieval Latency}{9}{}\protected@file@percent }
 \newlabel{sec:Index_exp_2}{{7.2.2}{9}}
-\newlabel{fig:index_exp3_1}{{7.2.3}{9}}
-\newlabel{fig:index_exp3_2}{{7.2.3}{9}}
-\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Ablation Analysis}}{9}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {I/O Reduction Analysis}}}{9}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Latency Breakdown}}}{9}{}\protected@file@percent }
-\newlabel{fig:index_exp3}{{6}{9}}
-\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Impact of grid resolution on query latency}}{9}{}\protected@file@percent }
-\newlabel{fig:index_exp3_3}{{7}{9}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.3}Ablation Study}{9}{}\protected@file@percent }
-\newlabel{sec:Index_exp_3}{{7.2.3}{9}}
-\newlabel{fig:index_exp4_1}{{7.2.4}{10}}
+\newlabel{fig:index_exp3_1}{{7.2.3}{10}}
+\newlabel{fig:index_exp3_2}{{7.2.3}{10}}
+\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Ablation analysis}}{10}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {I/O reduction analysis}}}{10}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Latency breakdown}}}{10}{}\protected@file@percent }
+\newlabel{fig:index_exp3}{{6}{10}}
+\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Impact of grid resolution on query latency}}{10}{}\protected@file@percent }
+\newlabel{fig:index_exp3_3}{{7}{10}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.3}Ablation Study}{10}{}\protected@file@percent }
+\newlabel{sec:Index_exp_3}{{7.2.3}{10}}
 \newlabel{fig:index_exp4_2}{{7.2.4}{10}}
-\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Index Construction and Storage Overhead}}{10}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Ingestion Scalability}}}{10}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Storage Consumption Overhead}}}{10}{}\protected@file@percent }
+\newlabel{fig:index_exp4_1}{{7.2.4}{10}}
+\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Index construction and storage overhead}}{10}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Ingested images ($10^4$)}}}{10}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Various index types}}}{10}{}\protected@file@percent }
 \newlabel{fig:index_exp4}{{8}{10}}
 \@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.4}Index Construction and Storage Overhead}{10}{}\protected@file@percent }
 \@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Evaluating the Concurrency Control}{10}{}\protected@file@percent }
-\newlabel{fig:cc_exp1_1}{{7.3.1}{10}}
-\newlabel{fig:cc_exp1_2}{{7.3.1}{10}}
-\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces The computing cost of spatial-keyword skylines}}{10}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {The query latency}}}{10}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Aggregate Throughput}}}{10}{}\protected@file@percent }
-\newlabel{fig:cc_exp1}{{9}{10}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.1}Concurrency Scalability}{10}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.2}Tail Latency and Contention Sensitivity}{10}{}\protected@file@percent }
-\newlabel{fig:cc_exp2_1}{{7.3.2}{11}}
-\newlabel{fig:cc_exp2_2}{{7.3.2}{11}}
-\@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces Tail Latency and Contention Sensitivity}}{11}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Tail Latency Sensitivity}}}{11}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Fairness under Contention}}}{11}{}\protected@file@percent }
-\newlabel{fig:cc_exp2}{{10}{11}}
-\newlabel{fig:cc_exp3_1}{{7.3.3}{11}}
-\newlabel{fig:cc_exp3_2}{{7.3.3}{11}}
-\@writefile{lof}{\contentsline {figure}{\numberline {11}{\ignorespaces Storage-Level Effects and Request Collapse}}{11}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Data Volume Reduction}}}{11}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Request Collapse (IOPS)}}}{11}{}\protected@file@percent }
-\newlabel{fig:cc_exp3}{{11}{11}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.3}Storage-Level Effects and Request Collapse}{11}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {figure}{\numberline {12}{\ignorespaces Merging Efficiency}}{11}{}\protected@file@percent }
-\newlabel{fig:cc_exp3_3}{{12}{11}}
-\@writefile{lof}{\contentsline {figure}{\numberline {13}{\ignorespaces Adaptive Performance Switching}}{11}{}\protected@file@percent }
-\newlabel{fig:cc_exp4}{{13}{11}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.4}Deterministic vs Non-Deterministic Modes}{11}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.5}Microbenchmark of Window Merging}{11}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsection}{\numberline {7.4}Evaluating the I/O tuning}{11}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.4.1}Convergence Speed and Tuning Cost}{11}{}\protected@file@percent }
-\newlabel{fig:cc_exp5_1}{{14(a)}{12}}
-\newlabel{sub@fig:cc_exp5_1}{{(a)}{12}}
-\newlabel{fig:cc_exp5_2}{{14(b)}{12}}
-\newlabel{sub@fig:cc_exp5_2}{{(b)}{12}}
-\newlabel{fig:cc_exp5_3}{{14(c)}{12}}
-\newlabel{sub@fig:cc_exp5_3}{{(c)}{12}}
-\@writefile{lof}{\contentsline {figure}{\numberline {14}{\ignorespaces Microbenchmark of Window Merging}}{12}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Reduction Pipeline}}}{12}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Run Length Distribution}}}{12}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(c)}{\ignorespaces {Cost-Benefit Analysis}}}{12}{}\protected@file@percent }
-\newlabel{fig:cc_exp5}{{14}{12}}
-\newlabel{fig:tune_exp1_1}{{15(a)}{12}}
-\newlabel{sub@fig:tune_exp1_1}{{(a)}{12}}
-\newlabel{fig:tune_exp1_2}{{15(b)}{12}}
-\newlabel{sub@fig:tune_exp1_2}{{(b)}{12}}
-\newlabel{fig:tune_exp1_3}{{15(c)}{12}}
-\newlabel{sub@fig:tune_exp1_3}{{(c)}{12}}
-\@writefile{lof}{\contentsline {figure}{\numberline {15}{\ignorespaces Convergence Speed and Tuning Cost}}{12}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Convergence Speed}}}{12}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Cumulative Tuning Overhead}}}{12}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(c)}{\ignorespaces {Search Efficiency}}}{12}{}\protected@file@percent }
-\newlabel{fig:tune_exp1}{{15}{12}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.4.2}Robustness under Stochastic Interference}{12}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.4.3}Adaptation to Workload Shifts}{12}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.4.4}Impact on End-to-End Query Performance}{12}{}\protected@file@percent }
-\@writefile{toc}{\contentsline {section}{\numberline {8}Conclusions}{12}{}\protected@file@percent }
-\newlabel{sec:Con}{{8}{12}}
+\newlabel{fig:cc_exp1_3}{{9(a)}{11}}
+\newlabel{sub@fig:cc_exp1_3}{{(a)}{11}}
+\newlabel{fig:cc_exp1_2}{{9(b)}{11}}
+\newlabel{sub@fig:cc_exp1_2}{{(b)}{11}}
+\newlabel{fig:cc_exp1_1}{{9(c)}{11}}
+\newlabel{sub@fig:cc_exp1_1}{{(c)}{11}}
+\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces Concurrency scalability analysis under varying spatial overlap ratios ($\sigma $).}}{11}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {$\sigma =0.4$}}}{11}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {$\sigma =0.6$}}}{11}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(c)}{\ignorespaces {$\sigma =0.8$}}}{11}{}\protected@file@percent }
+\newlabel{fig:cc_exp1}{{9}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.1}Concurrency Scalability}{11}{}\protected@file@percent }
+\newlabel{fig:cc_exp3_1}{{7.3.2}{11}}
+\newlabel{fig:cc_exp3_2}{{7.3.2}{11}}
+\@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces The data volume reduction and request collapse}}{11}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {The number of clients}}}{11}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {The number of clients}}}{11}{}\protected@file@percent }
+\newlabel{fig:cc_exp3}{{10}{11}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.2}Storage-Level Effects and Request Collapse}{11}{}\protected@file@percent }
+\citation{Rajesh24TunIO}
+\@writefile{lof}{\contentsline {figure}{\numberline {11}{\ignorespaces Mode Switching}}{12}{}\protected@file@percent }
+\newlabel{fig:cc_exp4}{{11}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.3.3}Deterministic and Non-Deterministic Modes}{12}{}\protected@file@percent }
+\newlabel{sec:ModeSwitch}{{7.3.3}{12}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {7.4}Evaluating the I/O tuning}{12}{}\protected@file@percent }
+\newlabel{fig:tune_exp1_1}{{7.4.1}{12}}
+\newlabel{fig:tune_exp1_2}{{7.4.1}{12}}
+\@writefile{lof}{\contentsline {figure}{\numberline {12}{\ignorespaces Efficiency analysis of the tuning framework.}}{12}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Tuning steps}}}{12}{}\protected@file@percent }
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Time (mins)}}}{12}{}\protected@file@percent }
+\newlabel{fig:tune_exp1}{{12}{12}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.4.1}Convergence Speed and Tuning Cost}{12}{}\protected@file@percent }
+\newlabel{eq:roti}{{10}{12}}
 \bibstyle{IEEEtran}
 \bibdata{bib/references}
 \bibcite{Ma15RS_bigdata}{1}
-\newlabel{fig:tune_exp2_1}{{16(a)}{13}}
-\newlabel{sub@fig:tune_exp2_1}{{(a)}{13}}
-\newlabel{fig:tune_exp2_2}{{16(b)}{13}}
-\newlabel{sub@fig:tune_exp2_2}{{(b)}{13}}
-\newlabel{fig:tune_exp2_3}{{16(c)}{13}}
-\newlabel{sub@fig:tune_exp2_3}{{(c)}{13}}
-\@writefile{lof}{\contentsline {figure}{\numberline {16}{\ignorespaces Robustness under Stochastic Interference}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Reward Stability under Noise}}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Regret Growth}}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(c)}{\ignorespaces {Configuration Stability}}}{13}{}\protected@file@percent }
-\newlabel{fig:tune_exp2}{{16}{13}}
-\newlabel{fig:tune_exp3_1}{{17(a)}{13}}
-\newlabel{sub@fig:tune_exp3_1}{{(a)}{13}}
-\newlabel{fig:tune_exp3_2}{{17(b)}{13}}
-\newlabel{sub@fig:tune_exp3_2}{{(b)}{13}}
-\newlabel{fig:tune_exp3_3}{{17(c)}{13}}
-\newlabel{sub@fig:tune_exp3_3}{{(c)}{13}}
-\@writefile{lof}{\contentsline {figure}{\numberline {17}{\ignorespaces Adaptation to Workload Shifts}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Response to Workload Shift}}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {Parameter Adaptation}}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(c)}{\ignorespaces {Speed of Adaptation}}}{13}{}\protected@file@percent }
-\newlabel{fig:tune_exp3}{{17}{13}}
-\newlabel{fig:tune_exp4_1}{{18(a)}{13}}
-\newlabel{sub@fig:tune_exp4_1}{{(a)}{13}}
-\newlabel{fig:tune_exp4_2}{{18(b)}{13}}
-\newlabel{sub@fig:tune_exp4_2}{{(b)}{13}}
-\newlabel{fig:tune_exp4_3}{{18(c)}{13}}
-\newlabel{sub@fig:tune_exp4_3}{{(c)}{13}}
-\@writefile{lof}{\contentsline {figure}{\numberline {18}{\ignorespaces Impact on End-to-End Query Performance}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {Steady-State Stability}}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {End-to-End Throughput}}}{13}{}\protected@file@percent }
-\@writefile{lof}{\contentsline {subfigure}{\numberline{(c)}{\ignorespaces {I/O Efficiency Tuning}}}{13}{}\protected@file@percent }
-\newlabel{fig:tune_exp4}{{18}{13}}
-\@writefile{toc}{\contentsline {section}{References}{13}{}\protected@file@percent }
 \bibcite{Haut21DDL_RS}{2}
 \bibcite{LEWIS17datacube}{3}
 \bibcite{Yan21RS_manage1}{4}
@@ -229,6 +174,12 @@
 \bibcite{Thomson12Calvin}{12}
 \bibcite{Lim17OCC}{13}
 \bibcite{Rajesh24TunIO}{14}
+\@writefile{lof}{\contentsline {figure}{\numberline {13}{\ignorespaces Mode Switching}}{13}{}\protected@file@percent }
+\newlabel{fig:tune_exp3}{{13}{13}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.4.2}Adaptation to Workload Shifts}{13}{}\protected@file@percent }
+\@writefile{toc}{\contentsline {section}{\numberline {8}Conclusions}{13}{}\protected@file@percent }
+\newlabel{sec:Con}{{8}{13}}
+\@writefile{toc}{\contentsline {section}{References}{13}{}\protected@file@percent }
 \bibcite{Preil25GMAB}{15}
 \bibcite{Tang12Quad-Tree}{16}
 \bibcite{Bernstein812PL}{17}
@@ -236,7 +187,9 @@
 \bibcite{WangK16MVOCC}{19}
 \bibcite{Hong25HDCC}{20}
 \bibcite{Wu25OOCC}{21}
-\bibcite{Chen21Tuning1}{22}
-\bibcite{Bez20TuningLayer}{23}
-\bibcite{Behzad13HDF5}{24}
+\bibcite{Peng26IOsurvey}{22}
+\bibcite{Chen21Tuning1}{23}
+\bibcite{Bez20TuningLayer}{24}
+\bibcite{Behzad13HDF5}{25}
+\bibcite{Wang26RethinkingTuning}{26}
 \gdef \@abspage@last{14}

mySkyline-v7.5.bbl

@@ -147,6 +147,12 @@ H.~Wu, M.~Zhang, K.~Chen, X.~Liao, Y.~Shan, and Y.~Wu, ``{OOCC:} one-round
   Hong Kong, May 19-23, 2025}.\hskip 1em plus 0.5em minus 0.4em\relax {IEEE},
   2025, pp. 238--250.
 
+\bibitem{Peng26IOsurvey}
+J.~Peng, L.~Yang, H.~Wu, W.~Zhang, Z.~Wu, W.~Zhang, J.~Li, Y.~Dai, and Y.~Dong,
+  ``A survey on machine learning-based hpc i/o analysis and optimization,''
+  \emph{IEEE Transactions on Parallel and Distributed Systems}, vol.~37, no.~3,
+  pp. 618--632, 2026.
+
 \bibitem{Chen21Tuning1}
 T.~Chen and M.~Li, ``Multi-objectivizing software configuration tuning (for a
   single performance concern),'' \emph{CoRR}, vol. abs/2106.01331, 2021.
@@ -165,4 +171,10 @@ B.~Behzad, J.~Huchette, H.~V.~T. Luu, R.~A. Aydt, S.~Byna, Y.~Yao, Q.~Koziol,
   M.~Parashar, J.~B. Weissman, D.~H.~J. Epema, and R.~J.~O. Figueiredo,
   Eds.\hskip 1em plus 0.5em minus 0.4em\relax {ACM}, 2013, pp. 127--128.
 
+\bibitem{Wang26RethinkingTuning}
+W.~Zhang, H.~Wang, Z.~Shi, Y.~Wu, M.~Li, T.~Li, F.~Wang, and D.~Feng,
+  ``Rethinking parameter tuning in distributed storage systems via knowledge
+  graph query,'' \emph{IEEE Transactions on Parallel and Distributed Systems},
+  vol.~37, no.~3, pp. 633--650, 2026.
+
 \end{thebibliography}

mySkyline-v7.5.blg

@@ -18,45 +18,45 @@ Warning--empty author in LEWIS17datacube
 Warning--empty booktitle in Lim17OCC
 
 Done.
-You've used 24 entries,
+You've used 26 entries,
             4087 wiz_defined-function locations,
-            1260 strings with 18869 characters,
-and the built_in function-call counts, 22607 in all, are:
-= -- 1767
-> -- 651
-< -- 206
-+ -- 351
-- -- 115
-* -- 1121
-:= -- 3172
-add.period$ -- 58
-call.type$ -- 24
-change.case$ -- 36
-chr.to.int$ -- 489
-cite$ -- 27
-duplicate$ -- 1566
-empty$ -- 1751
-format.name$ -- 140
-if$ -- 5308
+            1273 strings with 19424 characters,
+and the built_in function-call counts, 24787 in all, are:
+= -- 1934
+> -- 735
+< -- 226
++ -- 397
+- -- 132
+* -- 1233
+:= -- 3473
+add.period$ -- 62
+call.type$ -- 26
+change.case$ -- 38
+chr.to.int$ -- 531
+cite$ -- 29
+duplicate$ -- 1714
+empty$ -- 1899
+format.name$ -- 159
+if$ -- 5822
 int.to.chr$ -- 0
-int.to.str$ -- 24
-missing$ -- 284
-newline$ -- 97
-num.names$ -- 31
-pop$ -- 676
+int.to.str$ -- 26
+missing$ -- 315
+newline$ -- 103
+num.names$ -- 33
+pop$ -- 745
 preamble$ -- 1
 purify$ -- 0
 quote$ -- 2
-skip$ -- 1709
+skip$ -- 1873
 stack$ -- 0
-substring$ -- 1182
-swap$ -- 1346
-text.length$ -- 43
+substring$ -- 1282
+swap$ -- 1484
+text.length$ -- 49
 text.prefix$ -- 0
 top$ -- 5
-type$ -- 24
+type$ -- 26
 warning$ -- 3
-while$ -- 109
-width$ -- 26
-write$ -- 263
+while$ -- 117
+width$ -- 28
+write$ -- 285
 (There were 3 warnings)

mySkyline-v7.5.log

@@ -1,4 +1,4 @@
-This is XeTeX, Version 3.141592653-2.6-0.999995 (MiKTeX 23.4) (preloaded format=xelatex 2025.11.26)  27 JAN 2026 15:21
+This is XeTeX, Version 3.141592653-2.6-0.999995 (MiKTeX 23.4) (preloaded format=xelatex 2025.11.26)  31 JAN 2026 15:42
 entering extended mode
  restricted \write18 enabled.
  %&-line parsing enabled.
@@ -366,110 +366,71 @@ LaTeX Font Info:    ... okay on input line 176.
 LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 176.
 LaTeX Font Info:    ... okay on input line 176.
 LaTeX Font Info:    Trying to load font information for T1+phv on input line 27
-9.
+8.
 
 (D:\software\ctex\MiKTeX\tex/latex/psnfss\t1phv.fd
 File: t1phv.fd 2020/03/25 scalable font definitions for T1/phv.
 )
 LaTeX Font Info:    Font shape `T1/phv/m/it' in size <10> not available
-(Font)              Font shape `T1/phv/m/sl' tried instead on input line 279.
-LaTeX Font Info:    Trying to load font information for U+msa on input line 279
+(Font)              Font shape `T1/phv/m/sl' tried instead on input line 278.
+LaTeX Font Info:    Trying to load font information for U+msa on input line 278
 .
 
 (D:\software\ctex\MiKTeX\tex/latex/amsfonts\umsa.fd
 File: umsa.fd 2013/01/14 v3.01 AMS symbols A
 )
-LaTeX Font Info:    Trying to load font information for U+msb on input line 279
+LaTeX Font Info:    Trying to load font information for U+msb on input line 278
 .
 
 (D:\software\ctex\MiKTeX\tex/latex/amsfonts\umsb.fd
 File: umsb.fd 2013/01/14 v3.01 AMS symbols B
 )
-** ATTENTION: \keywords is deprecated (line 279). Use \IEEEkeywords instead.
-LaTeX Font Info:    Trying to load font information for U+pzd on input line 279
+Missing character: There is no ， in font phvr8t!
+** ATTENTION: \keywords is deprecated (line 278). Use \IEEEkeywords instead.
+LaTeX Font Info:    Trying to load font information for U+pzd on input line 278
 .
 (D:\software\ctex\MiKTeX\tex/latex/psnfss\upzd.fd
 File: upzd.fd 2001/06/04 font definitions for U/pzd.
 )
-** ATTENTION: \keywords is deprecated (line 279). Use \IEEEkeywords instead.
-Missing character: There is no ’ in font pplr8t!
-
-Underfull \hbox (badness 1622) in paragraph at lines 320--321
-\T1/ppl/m/n/9 Compute-then-Read" model: af-ter iden-ti-fy-ing can-di-date
- []
-
+Missing character: There is no ， in font phvr8t!
+** ATTENTION: \keywords is deprecated (line 278). Use \IEEEkeywords instead.
 [1
 
 
-]
-Underfull \hbox (badness 2875) in paragraph at lines 325--326
-[]\T1/ppl/m/n/9 We pro-pose an I/O-aware "Index-as-an-Execution-
- []
-
-[2]
+] [2]
 Missing character: There is no – in font pplr8t!
 
-Underfull \hbox (badness 3460) in paragraph at lines 407--409
-[]\T1/ppl/b/n/9 Problem State-ment (Latency-Optimized Con-cur-rent
- []
-
-
 Overfull \hbox (10.31828pt too wide) detected at line 412
 [][] [] []\OML/cmm/m/it/9 ;
  []
 
 File: fig/index.png Graphic file (type bmp)
 <fig/index.png>
+File: fig/st-query.png Graphic file (type bmp)
+<fig/st-query.png>
 Missing character: There is no ’ in font pplr8t!
 [3]
 Missing character: There is no – in font pplri8t!
-
-Underfull \hbox (badness 1881) in paragraph at lines 462--464
-[]\T1/ppl/m/it/9 Temporal Meta-data. \T1/ppl/m/n/9 To sup-port spatio-temporal 
-range
- []
-
 Missing character: There is no – in font pplr8t!
 Missing character: There is no ’ in font pplr8t!
-File: fig/st-query.png Graphic file (type bmp)
-<fig/st-query.png>
 
 Underfull \hbox (badness 2318) in paragraph at lines 484--487
 \T1/ppl/m/n/9 The I/O-aware in-dex en-ables ef-fi-cient spatio-temporal
  []
 
 
-Underfull \hbox (badness 1990) in paragraph at lines 484--487
-\T1/ppl/m/n/9 range queries by di-rectly trans-lat-ing query pred-i-cates
+Underfull \hbox (badness 1616) in paragraph at lines 484--487
+\T1/ppl/m/n/9 range re-trievals by di-rectly trans-lat-ing re-trieval pred-i-
  []
 
 
-Underfull \hbox (badness 1874) in paragraph at lines 484--487
-\T1/ppl/m/n/9 into win-dowed read plans, while avoid-ing both full-
- []
-
-
-Underfull \hbox (badness 1895) in paragraph at lines 484--487
-\T1/ppl/m/n/9 image load-ing and ex-pen-sive ge-o-met-ric com-pu-ta-tions.
- []
-
-
-Underfull \hbox (badness 7504) in paragraph at lines 484--487
-\T1/ppl/m/n/9 Given a user-specified spatio-temporal query $\OML/cmm/m/it/9 q \
-OT1/cmr/m/n/9 =
- []
-
-
-Underfull \hbox (badness 1874) in paragraph at lines 484--487
-\OMS/cmsy/m/n/9 h\OT1/cmr/m/n/9 [\OML/cmm/m/it/9 x[]; y[]; x[]; y[]\OT1/cmr/m/n
-/9 ]\OML/cmm/m/it/9 ; \OT1/cmr/m/n/9 [\OML/cmm/m/it/9 t[]; t[]\OT1/cmr/m/n/9 ]\
-OMS/cmsy/m/n/9 i$\T1/ppl/m/n/9 , the sys-tem re-solves the
+Underfull \hbox (badness 2644) in paragraph at lines 484--487
+\T1/ppl/m/n/9 full-image load-ing and ex-pen-sive ge-o-met-ric com-pu-ta-
  []
 
 [4]
 Missing character: There is no – in font pplr8t!
 Missing character: There is no – in font pplr8t!
-Missing character: There is no ’ in font pplr8t!
 Missing character: There is no — in font pplr8t!
 
 Underfull \hbox (badness 6927) in paragraph at lines 550--551
@@ -483,40 +444,55 @@ Underfull \hbox (badness 7944) in paragraph at lines 550--551
 
 File: fig/cc.png Graphic file (type bmp)
 <fig/cc.png>
+[5]
 Missing character: There is no – in font pplr8t!
-[5] [6]
-Underfull \hbox (badness 4132) in paragraph at lines 660--660
+[6]
+Underfull \hbox (badness 4132) in paragraph at lines 656--656
 []\T1/ppl/b/n/9 Algorithm 1: \T1/ppl/m/n/9 Surrogate-Assisted Ge-netic Multi-
  []
 
 LaTeX Font Info:    Trying to load font information for T1+pcr on input line 66
-8.
+4.
 (D:\software\ctex\MiKTeX\tex/latex/psnfss\t1pcr.fd
 File: t1pcr.fd 2001/06/04 font definitions for T1/pcr.
 )
-Underfull \hbox (badness 1448) in paragraph at lines 712--713
+Underfull \hbox (badness 3039) in paragraph at lines 708--709
+\T1/ppl/m/n/9 To ad-dress the on-line I/O tun-ing prob-lem, we use
+ []
+
+
+Underfull \hbox (badness 1448) in paragraph at lines 708--709
 \T1/ppl/m/n/9 a Surrogate-Assisted Ge-netic Multi-Armed Ban-dit (SA-
  []
 
+Missing character: There is no – in font pplr8t!
 Missing character: There is no – in font pplr8t!
 [7]
 Missing character: There is no – in font pplr8t!
-Missing character: There is no – in font pplr8t!
+
+Underfull \vbox (badness 1048) has occurred while \output is active []
+
+
 Missing character: There is no – in font pplr8t!
 LaTeX Font Info:    Font shape `T1/phv/m/it' in size <9> not available
-(Font)              Font shape `T1/phv/m/sl' tried instead on input line 736.
+(Font)              Font shape `T1/phv/m/sl' tried instead on input line 732.
 
-Underfull \hbox (badness 2073) in paragraph at lines 737--738
-\T1/ppl/m/n/9 We em-ployed a large-scale real-world re-mote sens-ing
+Overfull \hbox (4.42578pt too wide) in paragraph at lines 744--744
+[]|\T1/ppl/b/n/8 Resolution| 
  []
 
 
-Underfull \hbox (badness 3482) in paragraph at lines 782--783
-[]|\T1/ppl/m/n/8 Dual In-tel Xeon Gold 6248 (20 cores,
+Overfull \hbox (2.21104pt too wide) in paragraph at lines 744--745
+[]|\T1/ppl/b/n/8 Number| 
  []
 
 
-Overfull \hbox (4.28609pt too wide) in paragraph at lines 778--800
+Overfull \hbox (14.45601pt too wide) in paragraph at lines 742--756
+ [][] 
+ []
+
+[8]
+Overfull \hbox (4.28609pt too wide) in paragraph at lines 778--801
  [][] 
  []
 
@@ -524,7 +500,6 @@ File: exp/index_exp1_1.pdf Graphic file (type pdf)
 <use exp/index_exp1_1.pdf>
 File: exp/index_exp1_2.pdf Graphic file (type pdf)
 <use exp/index_exp1_2.pdf>
-[8]
 File: exp/index_exp2_1.pdf Graphic file (type pdf)
 <use exp/index_exp2_1.pdf>
 File: exp/index_exp2_2.pdf Graphic file (type pdf)
@@ -533,83 +508,41 @@ File: exp/index_exp3_1.pdf Graphic file (type pdf)
 <use exp/index_exp3_1.pdf>
 File: exp/index_exp3_2.pdf Graphic file (type pdf)
 <use exp/index_exp3_2.pdf>
+[9]
 File: exp/index_exp3_3.pdf Graphic file (type pdf)
 <use exp/index_exp3_3.pdf>
- [9]
-File: exp/index_exp4_1.pdf Graphic file (type pdf)
-<use exp/index_exp4_1.pdf>
 File: exp/index_exp4_2.pdf Graphic file (type pdf)
 <use exp/index_exp4_2.pdf>
-
-Underfull \hbox (badness 10000) in paragraph at lines 900--900
-[]\T1/phv/m/n/9 (b) Stor-age Con-sump-tion
- []
-
-
-Underfull \hbox (badness 2181) in paragraph at lines 916--917
-[]\T1/ppl/b/n/9 Baseline A (Naive): \T1/ppl/m/n/9 Queries func-tion as iso-late
-d
- []
-
-File: exp/cc_exp1_1.pdf Graphic file (type pdf)
-<use exp/cc_exp1_1.pdf>
+File: exp/index_exp4_1.pdf Graphic file (type pdf)
+<use exp/index_exp4_1.pdf>
+File: exp/cc_exp1_3.pdf Graphic file (type pdf)
+<use exp/cc_exp1_3.pdf>
 File: exp/cc_exp1_2.pdf Graphic file (type pdf)
 <use exp/cc_exp1_2.pdf>
-File: exp/cc_exp2_1.pdf Graphic file (type pdf)
-<use exp/cc_exp2_1.pdf>
-File: exp/cc_exp2_2.pdf Graphic file (type pdf)
-<use exp/cc_exp2_2.pdf>
-
-Underfull \hbox (badness 10000) in paragraph at lines 962--962
-[]\T1/phv/m/n/9 (b) Fair-ness un-der
- []
-
-Missing character: There is no ’ in font pplr8t!
-[10]
+File: exp/cc_exp1_1.pdf Graphic file (type pdf)
+<use exp/cc_exp1_1.pdf>
+ [10]
+Missing character: There is no — in font pplr8t!
 File: exp/cc_exp3_1.pdf Graphic file (type pdf)
 <use exp/cc_exp3_1.pdf>
 File: exp/cc_exp3_2.pdf Graphic file (type pdf)
 <use exp/cc_exp3_2.pdf>
-File: exp/cc_exp3_3.pdf Graphic file (type pdf)
-<use exp/cc_exp3_3.pdf>
-File: exp/cc_exp4_1.pdf Graphic file (type pdf)
-<use exp/cc_exp4_1.pdf>
-File: exp/cc_exp5_1.pdf Graphic file (type pdf)
-<use exp/cc_exp5_1.pdf>
-File: exp/cc_exp5_2.pdf Graphic file (type pdf)
-<use exp/cc_exp5_2.pdf>
-File: exp/cc_exp5_3.pdf Graphic file (type pdf)
-<use exp/cc_exp5_3.pdf>
+[11]
+File: exp/cc_exp4.pdf Graphic file (type pdf)
+<use exp/cc_exp4.pdf>
 File: exp/tune_exp1_1.pdf Graphic file (type pdf)
 <use exp/tune_exp1_1.pdf>
 File: exp/tune_exp1_2.pdf Graphic file (type pdf)
 <use exp/tune_exp1_2.pdf>
-File: exp/tune_exp1_3.pdf Graphic file (type pdf)
-<use exp/tune_exp1_3.pdf>
-File: exp/tune_exp2_1.pdf Graphic file (type pdf)
-<use exp/tune_exp2_1.pdf>
-File: exp/tune_exp2_2.pdf Graphic file (type pdf)
-<use exp/tune_exp2_2.pdf>
-File: exp/tune_exp2_3.pdf Graphic file (type pdf)
-<use exp/tune_exp2_3.pdf>
- [11]
+ [12]
 File: exp/tune_exp3_1.pdf Graphic file (type pdf)
 <use exp/tune_exp3_1.pdf>
-File: exp/tune_exp3_2.pdf Graphic file (type pdf)
-<use exp/tune_exp3_2.pdf>
-File: exp/tune_exp3_3.pdf Graphic file (type pdf)
-<use exp/tune_exp3_3.pdf>
-File: exp/tune_exp4_1.pdf Graphic file (type pdf)
-<use exp/tune_exp4_1.pdf>
-File: exp/tune_exp4_2.pdf Graphic file (type pdf)
-<use exp/tune_exp4_2.pdf>
-File: exp/tune_exp4_3.pdf Graphic file (type pdf)
-<use exp/tune_exp4_3.pdf>
- [12]
-Underfull \vbox (badness 10000) has occurred while \output is active []
 
+Underfull \hbox (badness 1383) in paragraph at lines 1059--1060
+\T1/ppl/m/n/9 a-lyt-ics. By in-tro-duc-ing the "Index-as-an-Execution-Plan"
+ []
 
-(mySkyline-v7.5.bbl [13]
+(mySkyline-v7.5.bbl
 Missing character: There is no — in font pplr8t!
 
 Underfull \hbox (badness 2837) in paragraph at lines 85--88
@@ -617,7 +550,9 @@ Underfull \hbox (badness 2837) in paragraph at lines 85--88
  []
 
 Missing character: There is no – in font pplr8t!
-) [14] (mySkyline-v7.5.aux)
+[13]) [14
+
+] (mySkyline-v7.5.aux)
 
 LaTeX Font Warning: Some font shapes were not available, defaults substituted.
 
@@ -626,12 +561,12 @@ LaTeX Warning: There were multiply-defined labels.
 
  ) 
 Here is how much of TeX's memory you used:
- 5953 strings out of 411463
- 92963 string characters out of 5822269
- 1869290 words of memory out of 5000000
- 26069 multiletter control sequences out of 15000+600000
+ 5814 strings out of 411463
+ 89753 string characters out of 5822269
+ 1871290 words of memory out of 5000000
+ 25944 multiletter control sequences out of 15000+600000
  578963 words of font info for 122 fonts, out of 8000000 for 9000
  1351 hyphenation exceptions out of 8191
- 55i,17n,62p,1922b,503s stack positions out of 10000i,1000n,20000p,200000b,200000s
+ 55i,17n,62p,1677b,503s stack positions out of 10000i,1000n,20000p,200000b,200000s
 
 Output written on mySkyline-v7.5.pdf (14 pages).

mySkyline-v7.5.tex

@@ -258,8 +258,7 @@
 \IEEEcompsoctitleabstractindextext{%
 \begin{abstract}
 %\boldmath
-High-performance remote sensing analytics workflows require ingesting and retrieving massive image archives to support real-time spatio-temporal applications. While modern systems utilize window-based I/O reading to reduce data transfer, they face a dual bottleneck: the prohibitive overhead of runtime geospatial computations caused by the decoupling of logical indexing from physical storage, and severe storage-level I/O contention triggered by uncoordinated concurrent reads. To address these limitations, we present a comprehensive I/O-aware retrieval processing approach based on a novel "Index-as-an-Execution-Plan" paradigm. We introduce a dual-layer inverted structure that serves as a deterministic I/O planner, pre-materializing grid-to-pixel mappings to completely eliminate runtime geometric calculations. Furthermore, we design a hybrid concurrency-aware I/O coordination protocol that adaptively integrates Calvin-style deterministic ordering with optimistic execution, effectively converting I/O contention into request merging opportunities. To handle fluctuating workloads, we incorporate a Surrogate-Assisted Genetic Multi-Armed Bandit mechanism for automatic parameter tuning. Evaluated on a distributed cluster with Sentinel-2 datasets, our approach reduces end-to-end latency by an order of magnitude compared to standard window-based reading, achieves linear throughput scaling under high concurrency, and demonstrates superior convergence speed in automatic tuning.
-
+High-performance remote sensing analytics workflows require ingesting and retrieving massive image archives to support real-time spatio-temporal applications. While modern systems utilize window-based I/O reading to reduce data transfer, they face a dual bottleneck: the prohibitive overhead of runtime geospatial computations caused by the decoupling of logical indexing from physical storage, and severe storage-level I/O contention triggered by uncoordinated concurrent reads. To address these limitations, we present a comprehensive I/O-aware retrieval approach based on a novel "Index-as-an-Execution-Plan" paradigm. We introduce a dual-layer inverted index that serves as a I/O planner, pre-materializing grid-to-pixel mappings to completely eliminate runtime geometric calculations. Furthermore, we design a hybrid concurrency-aware I/O coordination protocol that adaptively integrates Calvin-style deterministic ordering with optimistic execution, effectively converting I/O contention into request merging opportunities. To handle fluctuating workloads, we incorporate a Surrogate-Assisted Genetic Multi-Armed Bandit (SA-GMAB) for automatic parameter tuning. Evaluated on a distributed cluster with martian datasets, the experimental results indicate that (1) I/O-aware indexing reduces retrieval latency by an order of magnitude， (2) hybrid concurrency-aware I/O coordination achieves a 54x speedup under high contention through request merging and automates optimal mode switching (3) SA-GMAB has the fastest convergence speed and recovers from workload shifts $2\times$ faster than TunIO.
 \end{abstract}
 % IEEEtran.cls defaults to using nonbold math in the Abstract.
 % This preserves the distinction between vectors and scalars. However,
@@ -317,12 +316,13 @@ Existing RS data management systems \cite{LEWIS17datacube, Yan21RS_manage1, liu2
 \par
 The second phase is the data extraction phase, where the system reads the actual pixel data from the identified raw image files stored in distributed file systems or object stores. A critical observation in modern high-performance RS analytics is that the primary system bottleneck has fundamentally shifted from the first phase to the second. While the metadata search completes in milliseconds, the end-to-end retrieval latency is now dominated by the massive I/O overhead required to fetch, decompress, and process large-scale raw images. Traditional systems attempted to reduce I/O overhead by pre-slicing tiles and building pyramids (e.g., approaches used in Google Earth Engine \cite{gorelick17GEE} that store metadata in HBase and serve pre-tiled image pyramids), but aggressive tiling increases management complexity and produces many small files. More recent Cloud-Optimized GeoTIFF (COG) formats and COG-aware frameworks \cite{LEWIS17datacube}, \cite{riotiler25riotiler} exploit internal overviews and window-based I/O to read only the portions of files that spatially intersect a retrieval. 
 
-While window-based I/O effectively reduces raw data transfer, it introduces a new "computation wall" due to the decoupling of logical indexing from physical storage. Current state-of-the-art systems operate on a "Search-then-Compute-then-Read" model: after identifying candidate files, they must perform fine-grained, per-image geospatial computations at runtime to map retrieval coordinates to precise file offsets and clip boundaries. This runtime geometric resolution ($C_{geo}$) becomes computationally prohibitive when processing a large volume of candidate images, often negating the benefits of I/O reduction. Moreover, under concurrent workloads, the lack of coordination among these independent read requests leads to severe I/O contention and storage thrashing, rendering traditional indexing-centric optimizations insufficient for real-time applications.
+\par
+While window-based I/O effectively reduces raw data transfer, it introduces a new computational burden due to the decoupling of logical indexing from physical storage. Current systems operate on a "Search-then-Compute-then-Read" model: after identifying candidate files, they must perform fine-grained, per-image geospatial computations at runtime to map retrieval coordinates to precise file offsets and clip boundaries. This runtime geometric resolution becomes computationally prohibitive when processing a large volume of candidate images, often negating the benefits of I/O reduction. Moreover, under concurrent workloads, the lack of coordination among these independent read requests leads to severe I/O contention and storage thrashing, rendering traditional indexing-centric optimizations insufficient for real-time applications.
 
-To address the problems above, we propose a novel "Index-as-an-Execution-Plan" paradigm to strictly bound the retrieval latency. Unlike conventional approaches that treat indexing and I/O execution as separate stages, our approach integrates fine-grained partial retrieval directly into the indexing structure. By pre-materializing the mapping between logical spatial grids and physical pixel windows, our system enables deterministic I/O planning without runtime geometric computation. To further ensure scalability, we introduce a concurrency control protocol tailored for spatio-temporal range retrievals and an automatic I/O tuning mechanism. The principal contributions of this paper are summarized as follows:
+To address the problems above, we propose a novel "Index-as-an-Execution-Plan" paradigm to bound the retrieval latency. Unlike conventional approaches that treat indexing and I/O execution as separate stages, our approach integrates fine-grained partial retrieval directly into the indexing structure. By pre-materializing the mapping between logical spatial grids and physical pixel windows, our system enables deterministic I/O planning without runtime geometric computation. To further ensure scalability, we introduce a concurrency control protocol tailored for spatio-temporal range retrievals and an automatic I/O tuning mechanism. The principal contributions of this paper are summarized as follows:
 
 \begin{enumerate}
-	\item We propose an I/O-aware "Index-as-an-Execution-Plan" schema. Instead of merely returning candidate image identifiers, our index directly translates high-level spatio-temporal predicates into concrete, byte-level windowed read plans. This design bridges the semantic gap between logical retrievals and physical storage, eliminating expensive runtime geospatial computations and ensuring that I/O cost is proportional strictly to the retrieval footprint.
+	\item We propose an I/O-aware index schema. Instead of merely returning candidate image identifiers, our index directly translates high-level spatio-temporal predicates into concrete, byte-level windowed read plans. This design bridges the semantic gap between logical retrievals and physical storage, eliminating expensive runtime geospatial computations and ensuring that I/O cost is proportional strictly to the retrieval footprint.
 
 	\item We propose a hybrid concurrency-aware I/O coordination protocol. This protocol adapts transaction processing principles by integrating Calvin-style deterministic ordering \cite{Thomson12Calvin} with optimistic execution \cite{Lim17OCC}. It shifts the focus from protecting database rows to coordinating shared I/O flows. This protocol dynamically switches strategies based on spatial contention, effectively converting "I/O contention" into "request merging opportunities."
 
@@ -355,7 +355,7 @@ Concurrency control has long been studied to provide correctness and high throug
 Overall, existing concurrency control mechanisms are largely designed around transaction-level correctness and throughput, assuming record- or key-based access patterns and treating storage I/O as a black box. Their optimization objectives rarely account for I/O amplification or fine-grained storage contention induced by concurrent range retrievals. Consequently, these approaches are ill-suited for data-intensive spatio-temporal workloads, where coordinating overlapping window reads and mitigating storage-level interference are critical to achieving scalable performance under multi-user access.
 
 \subsection{I/O Performance Tuning in Storage Systems}
-I/O performance tuning has been extensively studied in the context of HPC and data-intensive storage systems, where complex multi-layer I/O stacks expose a large number of tunable parameters. These parameters span different layers, including application-level I/O libraries, middleware, and underlying storage systems, and their interactions often lead to highly non-linear performance behaviors. As a result, manual tuning is time-consuming and error-prone, motivating a wide range of auto-tuning approaches.
+I/O performance tuning has been extensively studied in the context of HPC and data-intensive storage systems, where complex multi-layer I/O stacks expose a large number of tunable parameters. These parameters span different layers, including application-level I/O libraries, middleware, and underlying storage systems, and their interactions often lead to highly non-linear performance behaviors. As a result, manual tuning is time-consuming and error-prone, motivating a wide range of auto-tuning approaches \cite{Peng26IOsurvey}.
 
 \par
 Several studies focus on improving the efficiency of the tuning pipeline itself by reformulating the search space or optimization objectives. Chen et al. \cite{Chen21Tuning1} proposed a meta multi-objectivization (MMO) model that introduces auxiliary performance objectives to mitigate premature convergence to local optima. While such techniques can improve optimization robustness, they are largely domain-agnostic and do not explicitly account for the characteristics of I/O-intensive workloads. Other works, such as the contextual bandit-based approach by Bez et al. \cite{Bez20TuningLayer}, optimize specific layers of the I/O stack (e.g., I/O forwarding) by exploiting observed access patterns. However, these methods are primarily designed for administrator-level tuning and target isolated components rather than end-to-end application I/O behavior.
@@ -364,7 +364,7 @@ Several studies focus on improving the efficiency of the tuning pipeline itself
 User-level I/O tuning has also been explored, most notably by H5Tuner \cite{Behzad13HDF5}, which employs genetic algorithms to optimize the configuration of the HDF5 I/O library. Although effective for single-layer tuning, H5Tuner does not consider cross-layer interactions and lacks mechanisms for reducing tuning cost, such as configuration prioritization or early stopping.
 
 \par
-More recently, TunIO \cite{Rajesh24TunIO} proposed an AI-powered I/O tuning framework that explicitly targets the growing configuration spaces of modern I/O stacks. TunIO integrates several advanced techniques, including I/O kernel extraction, smart selection of high-impact parameters, and reinforcement learning–driven early stopping, to balance tuning cost and performance gain across multiple layers. Despite its effectiveness, TunIO and related frameworks primarily focus on single-application or isolated workloads, assuming stable access patterns during tuning. Retrieval-level I/O behaviors, such as fine-grained window access induced by spatio-temporal range retrievals, as well as interference among concurrent users, are generally outside the scope of existing I/O tuning approaches.
+More recently, TunIO \cite{Rajesh24TunIO} proposed an AI-powered I/O tuning framework that explicitly targets the growing configuration spaces of modern I/O stacks. TunIO integrates several advanced techniques, including I/O kernel extraction, smart selection of high-impact parameters, and reinforcement learning–driven early stopping, to balance tuning cost and performance gain across multiple layers. Despite its effectiveness, TunIO and related frameworks primarily focus on single-application or isolated workloads, assuming stable access patterns during tuning. Retrieval-level I/O behaviors, such as fine-grained window access induced by spatio-temporal range retrievals, as well as interference among concurrent users, are generally outside the scope of existing I/O tuning approaches \cite{Wang26RethinkingTuning}.
 
 \section{Definition}\label{sec:DF}
 This section formalizes the spatio-temporal range retrieval problem and establishes the cost models for retrieval execution. We assume a distributed storage environment where large-scale remote sensing images are stored as objects or files.
@@ -422,10 +422,17 @@ This section introduces the details of indexing structre for spatio-temporal ran
 \begin{figure*}[htb]
 	\centering
 	\includegraphics[width=0.90\textwidth]{fig/index.png}
-	\caption{Index schema design.}
+	\caption{Index schema design}
 	\label{fig:index}
 \end{figure*}
 
+\begin{figure}
+	\centering
+	\includegraphics[width=2.2in]{fig/st-query.png}
+	\caption{Retrieval-time Execution}
+	\label{fig_ST_Query}
+\end{figure}
+
 \subsection{Index schema design}
 \par
 To enable I/O-efficient spatio-temporal query processing, we first decompose the global spatial domain into a uniform grid that serves as the basic unit for query pruning and data access coordination. Specifically, we adopt a fixed-resolution global tiling scheme based on the Web Mercator (or EPSG:4326) coordinate system, using zoom level 14 to partition the Earth’s surface into fine-grained grid cells (experiments show that the 14-level grid has the highest indexing efficiency which can be referred to Section~\ref{sec:Index_exp_3}). This resolution strikes a practical balance between spatial selectivity and index size: finer levels would significantly increase metadata volume and maintenance cost, while coarser levels would reduce pruning effectiveness and lead to unnecessary image I/O. At this scale, each grid cell typically corresponds to a spatial extent comparable to common query footprints and to the internal tiling granularity used by modern raster formats, making it well suited for partial data access.
@@ -474,13 +481,6 @@ During data ingestion, the grid–window mappings are generated by projecting gr
 
 \subsection{Retrieval-time Execution}
 
-\begin{figure}
-	\centering
-	\includegraphics[width=2.2in]{fig/st-query.png}
-	\caption{Retrieval-time Execution}
-	\label{fig_ST_Query}
-\end{figure}
-
 The I/O-aware index enables efficient spatio-temporal range retrievals by directly translating retrieval predicates into windowed read plans, while avoiding both full-image loading and expensive geometric computations. Given a user-specified spatio-temporal retrieval
 $q = \langle [x_{\min}, y_{\min}, x_{\max}, y_{\max}], [t_s, t_e] \rangle$,
 the system resolves the retrieval through three consecutive stages: \emph{Grid Enumeration}, \emph{Candidate Image Retrieval with Temporal Pruning}, and \emph{Windowed Read Plan Generation}. As illustrated in Fig.~\ref{fig_ST_Query}, this execution pipeline bridges high-level retrieval predicates and low-level I/O operations in a fully deterministic manner.
@@ -549,13 +549,12 @@ In contrast, our I/O-aware indexing approach fundamentally alters this trade-off
 \section{Hybrid Concurrency-Aware I/O Coordination}\label{sec:CC}
 In this section, we propose a hybrid coordination mechanism that adaptively employs either lock-free non-deterministic execution or deterministic coordinated scheduling based on the real-time contention level of spatio-temporal workloads.
 
-\begin{figure}
+\begin{figure*}
 	\centering
-	\includegraphics[width=3.0in]{fig/cc.png}
+	\includegraphics[width=0.90\textwidth]{fig/cc.png}
 	\caption{Hybrid Concurrency-Aware I/O Coordination.}
 	\label{fig:cc}
-\end{figure}
-
+\end{figure*}
 
 \subsection{Retrieval Admission and I/O Plan Generation}
 When a spatio-temporal range retrieval $Q$ arrives, the system first performs index-driven plan generation. The retrieval footprint is rasterized into the global grid to enumerate the intersecting grid cells. The G2I table is then consulted to retrieve the set of candidate images, followed by selective lookups in the I2G table to obtain the corresponding pixel windows.
@@ -590,7 +589,7 @@ The system utilizes a rule-based assignment mechanism similar to HDCC \cite{Hong
 \end{enumerate}
 
 \subsection{Deterministic Coordinated and Non-deterministic Execution}
-When $\sigma \ge \tau$, the system switches to a deterministic path to mitigate storage-level contention and I/O amplification, as shown in Fig.~\ref{fig:cc}. To coordinate concurrent access to shared storage resources, we introduce a \emph{Global I/O Plan Queue} that enforces a deterministic ordering over all admitted I/O plans. Each windowed access $(img, w)$ derived from incoming retrievals is inserted into this queue according to a predefined policy, such as FIFO based on arrival time or lexicographic ordering by $(timestamp, RetrievalID)$.
+When $\sigma \ge \tau$, the system switches to a deterministic path to mitigate storage-level contention and I/O amplification, as shown in Fig.~\ref{fig:cc}. To coordinate concurrent access to shared storage resources, we introduce a Global I/O Plan Queue that enforces a deterministic ordering over all admitted I/O plans. Each windowed access $(img, w)$ derived from incoming retrievals is inserted into this queue according to a predefined policy, such as FIFO based on arrival time or lexicographic ordering by $(timestamp, RetrievalID)$.
 
 \par
 This design is inspired by deterministic scheduling in systems such as Calvin, but differs fundamentally in its scope: the ordering is imposed on \emph{window-level I/O operations} rather than on transactions. As a result, accesses to the same image region across different retrievals follow a globally consistent order, preventing uncontrolled interleaving of reads and reducing contention at the storage layer. The deterministic ordering also provides a stable foundation for subsequent I/O coordination and sharing.
@@ -623,7 +622,6 @@ Overall, this concurrency-aware I/O coordination mechanism reinterprets concurre
 We first describe an I/O stack tuning problem and then the surrogate-assisted GMAB algorithm is proposed to solve the problem.
 
 \subsection{Formulation of Online I/O Tuning}
-% TODO 这一节的小标题：Tuning Model？
 We study a concurrency spatio-temporal retrieval engine that processes many range retrievals at the same time. The system works on large remote sensing images stored in shared storage. Different from traditional HPC jobs or single-application I/O workloads, the system does not run one fixed job. Instead, it keeps receiving a stream of user retrievals. Each retrieval is turned into many small I/O operations that often touch overlapping regions in large raster files.
 
 \par
@@ -652,8 +650,6 @@ Given a stream of retrievals $\mathcal{Q}$ and the resulting sequence of executi
 \end{equation}
 subject to practical constraints on tuning overhead and system stability.
 
-% TODO：加个限制条件的表格
-
 \subsection{Surrogate-Assisted GMAB for Online I/O Tuning}
 
 \begin{algorithm}[!htb]
@@ -734,7 +730,7 @@ First, we introduce the experimental setup, covering the dataset characteristics
 \subsection{Experimental Setup}
 
 \subsubsection{Dataset}
-We employed a large-scale real-world remote sensing dataset derived from the Sentinel-2 mission \footnote[1]{https://sentinel.esa.int/web/sentinel/missions/sentinel-2}, specifically the Level-2A atmospherically corrected products. The dataset comprises multi-spectral images covering global land surfaces from 2019 to 2023. To simulate a cloud-native storage environment, all images are converted into Cloud-Optimized GeoTIFF (COG) format and stored in a distributed object store. The statistics of the dataset are summarized in Table~\ref{table_dataset}.
+We employed a large-scale, multi-source planetary remote sensing dataset derived from major Martian exploration missions to evaluate the system under heterogeneous workloads. Specifically, the dataset integrates imagery from the Tianwen-1 Medium Resolution Imaging Camera (MoRIC), the Context Camera (CTX), the Thermal Emission Imaging System (THEMIS), and the High Resolution Imaging Science Experiment (HiRISE). These datasets encompass a diverse range of spatial resolutions and spectral bands, covering extensive global Martian surface features. To facilitate efficient window-based I/O and random access, all raw planetary data products were pre-processed and converted into the Cloud-Optimized GeoTIFF (COG) format. The detailed specifications and statistics of the dataset are summarized in Table~\ref{table_dataset}.
 
 % table 1: Dataset
 \begin{table}
@@ -743,14 +739,18 @@ We employed a large-scale real-world remote sensing dataset derived from the Sen
 	\label{table_dataset}
 	\vspace{-0.13in}
 	\centering
-	\begin{tabular}{|m{1.5cm}|m{1.5cm}|m{1.5cm}|m{2.0cm}|}
+	\begin{tabular}{|m{1.25cm}|m{1.25cm}|m{1.5cm}|m{1.75cm}|m{1cm}|}
 		\hline
-		\makecell[c]{\textbf{Dataset}} &\bfseries Resolution & \bfseries Time Span & \bfseries Total Volume \\
+		\makecell[c]{\textbf{Dataset}} &\bfseries Resolution & \bfseries Time Span & \bfseries Total Volume & \bfseries Number \\
 		\hline
 		\hline
-		\makecell[c]{Sentinel-2}&\makecell[c]{10m - 60m} & \makecell[c]{2019--2023} & \makecell[c]{15.4 TB}\\
+		\makecell[c]{MoRIC}&\makecell[c]{76m} & \makecell[c]{2021--2022} & \makecell[c]{1.1 TB}&\makecell[c]{12060}\\
 		\hline
-		\makecell[c]{Landsat-8}&\makecell[c]{30m} & \makecell[c]{2020--2022} & \makecell[c]{4.2 TB}\\
+		\makecell[c]{CTX}&\makecell[c]{5m} & \makecell[c]{2007--2024} & \makecell[c]{3.1 TB}&\makecell[c]{3960}\\
+		\hline
+		\makecell[c]{THEMIS}&\makecell[c]{100m} & \makecell[c]{2003--2024} & \makecell[c]{6.5 TB}&\makecell[c]{669641}\\
+		\hline
+		\makecell[c]{HiRISE}&\makecell[c]{0.5m} & \makecell[c]{2007--2024} & \makecell[c]{41.2 TB}&\makecell[c]{96693}\\
 		\hline
 	\end{tabular}
 \end{table}
@@ -759,14 +759,14 @@ We employed a large-scale real-world remote sensing dataset derived from the Sen
 \par
 To evaluate the system performance under diverse scenarios, we developed a synthetic workload generator that simulates concurrent spatio-temporal range retrievals. The retrieval parameters are configured as follows:
 \begin{itemize}
-	\item \textbf{Spatial Extent:} The spatial range of retrievals follows a log-uniform distribution, ranging from small tile-level access ($0.001\%$ of the scene) to large-scale regional mosaics ($1\%$ to $100\%$ of the scene).
-	\item \textbf{Temporal Range:} Each retrieval specifies a time interval randomly chosen between 1 day and 1 month.
-	\item \textbf{Concurrency \& Contention:} The number of concurrent clients $N$ varies from 1 to 64. To test the coordination mechanism, we control the Spatial Overlap Ratio $\sigma \in [0, 0.9]$ to simulate workloads ranging from disjoint access to highly concentrated hotspots.
+	\item Spatial Extent: The spatial range of retrievals follows a log-uniform distribution, ranging from small tile-level access ($0.0001\%$ of the scene) to large-scale regional mosaics ($1\%$ to $100\%$ of the scene).
+	\item Temporal Range: Each retrieval specifies a time interval randomly chosen between 1 day and 1 month.
+	\item Concurrency \& Contention: The number of concurrent clients $N$ varies from 1 to 64. To test the coordination mechanism, we control the Spatial Overlap Ratio $\sigma \in [0, 0.9]$ to simulate workloads ranging from disjoint access to highly concentrated hotspots.
 \end{itemize}
 
 \subsubsection{Experimental Environment}
 \label{sec_exp_env}
-All experiments are conducted on a cluster with 9 homogenous nodes (1 master node and 8 worker nodes). The cluster is connected via a 10Gbps high-speed Ethernet to ensure that network bandwidth is not the primary bottleneck compared to storage I/O. Table \ref{table_config} lists the detailed hardware and software configurations. The I/O-aware index (G2I/I2G) is deployed on HBase, while the raw image data is served by a MinIO distributed object storage cluster.
+All experiments are conducted on a cluster with 9 homogenous nodes (1 master node and 8 worker nodes). The cluster is connected via a 10Gbps high-speed Ethernet to ensure that network bandwidth is not the primary bottleneck compared to storage I/O. Table \ref{table_config} lists the detailed hardware and software configurations. The I/O-aware index (G2I/I2G) is deployed on HBase, while the raw image data is served by the Lustre parallel file system.
 
 % table 2: Environment
 \begin{table}
@@ -779,96 +779,101 @@ All experiments are conducted on a cluster with 9 homogenous nodes (1 master nod
 		\hline
 		\multicolumn{2}{|c|}{\textbf{Hardware Configuration (Per Node)}} \\
 		\hline
-		\makecell[c]{CPU} & Dual Intel Xeon Gold 6248 (20 cores, 2.50GHz)\\
+		\makecell[c]{CPU} & Intel Xeon Gold 6248 (20 cores,
+		2.50GHz)\\
 		\hline
-		\makecell[c]{Memory} & \makecell[c]{128GB DDR4 ECC}\\
+		\makecell[c]{Memory} & \makecell[c]{128GB}\\
 		\hline
-		\makecell[c]{Storage} & \makecell[c]{4TB NVMe SSD (Data) + 500GB SSD (OS)}\\
+		\makecell[c]{Storage} & \makecell[c]{18TB NVMe SSD (Data) + 500GB SSD (OS)}\\
 		\hline
 		\makecell[c]{Network} & \makecell[c]{10 Gigabit Ethernet (10GbE)}\\
 		\hline\hline
 		
 		\multicolumn{2}{|c|}{\textbf{Software Stack}} \\
 		\hline
-		\makecell[c]{OS} & \makecell[c]{Ubuntu 20.04 LTS} \\
+		\makecell[c]{OS} & \makecell[c]{Ubuntu 22.04 LTS} \\
 		\hline
-		\makecell[c]{Storage} & \makecell[c]{Hadoop 3.3.1, HBase 2.4.5, Lustre}\\
+		\makecell[c]{Storage} & \makecell[c]{Hadoop 3.2.1, HBase 2.4.5, Lustre}\\
 		\hline
-		\makecell[c]{Framework} & \makecell[c]{OpenJDK 11, Spark 3.2.1}\\
+		\makecell[c]{Framework} & \makecell[c]{OpenJDK 11}\\
 		\hline
 	\end{tabular}
 \end{table}
 
-
-
-
 \subsection{Evaluating the data indexing structure}
-In the following experiments, we measured the indexing on a single node in the cluster, bacause each nodes needs to the indexing for spatial retrieval. We investigated of retrieval performance of the indexing for remote sensing images.
+In the following experiments, we measured the indexing on a single node in the cluster, bacause each nodes needs to the indexing for spatial retrieval. We investigated of retrieval performance of the indexing for remote sensing images. 
+
+For comparison, we compare three representative execution schemes: 
+
+\begin{enumerate} 
+	\item \textbf{Baseline 1 (Full-file Retrieval):} A traditional system that utilizes spatio-temporal indexing for metadata filtering but performs full-file retrieval during data extraction. 
+	\item \textbf{Baseline 2 (Window-based I/O):} A state-of-the-art system (e.g., OpenDataCube) that supports fine-grained partial reading to minimize I/O volume, representing the theoretical optimum for data selectivity. \item \textbf{Ours (I/O-aware Indexing):} The proposed approach utilizing the dual-layer G2I and I2G inverted structure, which pre-materializes grid-to-pixel mappings to enable deterministic partial reading without runtime geometric computations.
+\end{enumerate}
 
 \subsubsection{I/O Selectivity Analysis}\label{sec:Index_exp_1}
 
 \begin{figure}[tb]
 	\centering
-	\subfigure[I/O Selectivity]{
+	\subfigure[Query footprint ratios]{
 		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.98\textwidth]{exp/index_exp1_1.pdf}
+			\includegraphics[width=0.95\textwidth]{exp/index_exp1_1.pdf}
 		\end{minipage}
 	}
 	\label{fig:index_exp1_1}
-	\subfigure[[Unnecessary data fraction]{
+	\subfigure[Query spatial extents]{
 		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.905\textwidth]{exp/index_exp1_2.pdf}
+			\includegraphics[width=0.95\textwidth]{exp/index_exp1_2.pdf}
 		\end{minipage}
 	}
 	\label{fig:index_exp1_2}
-	\caption{The computing cost of spatial-keyword skylines}
+	\caption{The efficiency of I/O selectivity}
 	\label{fig:index_exp1}
 \end{figure}
 
 \par
-First, we evaluated the effectiveness of data reduction by measuring the I/O selectivity, defined as the ratio of the retrieved data volume to the total file size. Fig.~\ref{fig:index_exp1} compares our method against Baseline 1 (full-file retrieval) and Baseline 2 (exact window-based reading, e.g., OpenDataCube). As illustrated in Fig.~\ref{fig:index_exp1}(a), Baseline 1 exhibits a linear increase in I/O volume proportional to the file size, resulting in poor selectivity regardless of the retrieval footprint. In contrast, both Baseline 2 and Ours significantly reduce I/O traffic by enabling partial reads. It is worth noting that our method incurs slightly higher I/O volume (approximately $16\%-23\%$ of the file size for small retrievals) compared to the theoretically optimal Baseline 2 ($10\%-20\%$). This marginal data redundancy is attributed to the grid alignment effect: our index retrieves pixel blocks based on fixed grid boundaries, whereas Baseline 2 performs precise geospatial clipping. Fig.~\ref{fig:index_exp1}(b) further presents the distribution of unnecessary data fraction. While our method introduces a small amount of "over-reading" due to grid padding, it successfully avoids the massive data waste observed in Baseline 1. As we will demonstrate in the next section, this slight compromise in I/O precision is a strategic trade-off that eliminates expensive runtime computations.
+First, we evaluated the effectiveness of data reduction by measuring the I/O selectivity, defined as the ratio of the retrieved data volume to the total file size. Fig.~\ref{fig:index_exp1} compares our method against Baseline 1 and Baseline 2. As illustrated in Fig.~\ref{fig:index_exp1}(a), Baseline 1 always reads the entire image regardless of the proportion of the intersection between the query range and the image. In contrast, both Baseline 2 and Ours significantly reduce I/O traffic by enabling partial reads. It is worth noting that our method incurs slightly higher I/O volume compared to the theoretically optimal Baseline 2. This marginal data redundancy is attributed to the grid alignment effect: our index retrieves pixel blocks based on fixed grid boundaries, whereas Baseline 2 performs precise geospatial clipping. Fig.~\ref{fig:index_exp1}(b) further presents the distribution of unnecessary data fraction. While our method introduces a small amount of "over-reading" due to grid padding, it successfully avoids the massive data waste observed in Baseline 1. As we will demonstrate in the next section, this slight compromise in I/O precision is a strategic trade-off that eliminates expensive runtime computations.
 
 \subsubsection{End-to-End Retrieval Latency}\label{sec:Index_exp_2}
 
 \begin{figure}[tb]
 	\centering
-	\subfigure[The retrieval latency]{
+	\subfigure[Query footprint ratios]{
 		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.98\textwidth]{exp/index_exp2_1.pdf}
+			\includegraphics[width=0.95\textwidth]{exp/index_exp2_1.pdf}
 		\end{minipage}
 	}
 	\label{fig:index_exp2_1}
-	\subfigure[Latency Breakdownn]{
+	\subfigure[Various baselines]{
 		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.905\textwidth]{exp/index_exp2_2.pdf}
+			\includegraphics[width=0.95\textwidth]{exp/index_exp2_2.pdf}
 		\end{minipage}
 	}
 	\label{fig:index_exp2_2}
-	\caption{End-to-End Retrieval Latency}
+	\caption{End-to-End retrieval latency and latency breakdown}
 	\label{fig:index_exp2}
 \end{figure}
 
 \par
-We next measured the end-to-end retrieval latency to verify whether the I/O reduction translates into time efficiency. Fig.~\ref{fig:index_exp2}(a) reports the mean and 95th percentile (P95) latency across varying retrieval footprint ratios (log scale).The results reveal three distinct performance behaviors:Baseline 1 shows a high and flat latency curve ($\approx 4500$ ms), dominated by the cost of transferring entire images.Baseline 2, despite its optimal I/O selectivity, exhibits a significant latency floor ($\approx 380$ ms for small retrievals). This overhead stems from the on-the-fly geospatial computations required to calculate precise read windows.Ours achieves the lowest latency, ranging from 34 ms to 59 ms for typical tile-level retrievals ($10^{-4}$ coverage).Crucially, for small-to-medium retrievals, our method outperforms Baseline 2 by an order of magnitude. The gap between the two curves highlights the advantage of our deterministic indexing approach: by pre-materializing grid-to-window mappings, we eliminate runtime coordinate transformations. Although our I/O volume is slightly larger (as shown in Sec.~\ref{sec:Index_exp_1}), the time saved by avoiding computational overhead far outweighs the cost of transferring a few extra kilobytes of padding data.
+We next measured the end-to-end retrieval latency to verify whether the I/O reduction translates into time efficiency. Fig.~\ref{fig:index_exp2}(a) reports the mean and 95th percentile (P95) latency across varying retrieval footprint ratios. The results reveal three distinct performance behaviors: Baseline 1 shows a high and flat latency curve ($\approx 4500$ ms), dominated by the cost of transferring entire images. Baseline 2, despite its optimal I/O selectivity, exhibits a significant latency floor ($\approx 380$ ms for small tile-level retrievals). This overhead stems from the on-the-fly geospatial computations required to calculate precise read windows. Ours achieves the lowest latency, ranging from 34 ms to 59 ms for typical tile-level retrievals. Crucially, for small-to-medium retrievals, our method outperforms Baseline 2 by an order of magnitude. The gap between the two curves highlights the advantage of our deterministic indexing approach: by pre-materializing grid-to-window mappings, we eliminate runtime coordinate transformations. Although our I/O volume is slightly larger (as shown in Sec.~\ref{sec:Index_exp_1}), the time saved by avoiding computational overhead far outweighs the cost of transferring a few extra kilobytes of padding data.
 
-To empirically validate the cost model proposed in Eq.~\ref{eqn:cost_total}, we further decomposed the retrieval latency into three components: metadata lookup ($C_{meta}$), geospatial computation ($C_{geo}$), and I/O access ($C_{io}$). Fig.~\ref{fig:index_exp2}(b) presents the time consumption breakdown for a representative medium-scale retrieval (involving approx. 50 image tiles). As expected, the latency of Baseline 1 is entirely dominated by $C_{io}$ ($>99\%$), rendering $C_{meta}$ and $C_{geo}$ negligible. The massive data transfer masks all other overheads. While $C_{io}$ of Baseline 2 is successfully reduced to the window size, a new bottleneck emerges in $C_{geo}$. The runtime coordinate transformations and polygon clipping consume nearly $70\%$ of the total execution time (approx. 350 ms). This observation confirms our theoretical analysis that window-based I/O shifts the bottleneck from storage to CPU. The proposed method exhibits a balanced profile. Although $C_{meta}$ increases slightly (approx. 60 ms) due to the two-phase index lookup (G2I + I2G), this cost is well-amortized. Crucially, $C_{geo}$ is effectively eliminated ($<1$ ms) thanks to the pre-computed grid-window mappings. Consequently, our approach achieves a total latency of approx. 150 ms, providing a $3\times$ speedup over Baseline 2 by removing the computational bottleneck without regressing on I/O performance.
+To empirically validate the cost model proposed in Eq.~\ref{eqn:cost_total}, we further decomposed the retrieval latency into three components: metadata lookup ($C_{meta}$), geospatial computation ($C_{geo}$), and I/O access ($C_{io}$). Fig.~\ref{fig:index_exp2}(b) presents the time consumption breakdown for a representative medium-scale retrieval (involving approx. 50 image tiles). As expected, the latency of Baseline 1 is entirely dominated by $C_{io}$, rendering $C_{meta}$ and $C_{geo}$ negligible. The massive data transfer masks all other overheads. While $C_{io}$ of Baseline 2 is successfully reduced to the window size, a new bottleneck emerges in $C_{geo}$. The runtime coordinate transformations and polygon clipping consume nearly $40\%$ of the total execution time ($\approx 350 ms$). This observation confirms our theoretical analysis that window-based I/O shifts the bottleneck from storage to CPU. The proposed method exhibits a balanced profile. Although $C_{meta}$ increases slightly ($\approx 35 ms$) due to the two-phase index lookup (G2I + I2G), this cost is well-amortized. Crucially, $C_{geo}$ is effectively eliminated thanks to the pre-computed grid-window mappings. Consequently, our approach achieves a total latency of 580 ms, providing a $1.7\times$ speedup over Baseline 2 by removing the computational bottleneck without regressing on I/O performance.
 
 \subsubsection{Ablation Study}\label{sec:Index_exp_3}
 \begin{figure}[tb]
 	\centering
-	\subfigure[I/O Reduction Analysis]{
+	\subfigure[I/O reduction analysis]{
 		\begin{minipage}[b]{0.227\textwidth}
 			\includegraphics[width=0.9\textwidth]{exp/index_exp3_1.pdf}
 		\end{minipage}
 	}
 	\label{fig:index_exp3_1}
-	\subfigure[Latency Breakdown]{
+	\subfigure[Latency breakdown]{
 		\begin{minipage}[b]{0.227\textwidth}
 			\includegraphics[width=0.9\textwidth]{exp/index_exp3_2.pdf}
 		\end{minipage}
 	}
 	\label{fig:index_exp3_2}
-	\caption{Ablation Analysis}
+	\caption{Ablation analysis}
 	\label{fig:index_exp3}
 \end{figure}
 
@@ -880,272 +885,178 @@ To empirically validate the cost model proposed in Eq.~\ref{eqn:cost_total}, we
 \end{figure}
 
 \par
-To quantify the individual contributions of the G2I (coarse filtering) and I2G (fine-grained access) components, we decomposed the system into four variants. Fig.~\ref{fig:index_exp3} breaks down the performance in terms of I/O volume and latency components (Metadata Lookup vs. Storage I/O). Fig.~\ref{fig:index_exp3}(a) confirms that removing either component leads to suboptimal I/O behavior. The "No Index" and "G2I Only" variants result in 100\% I/O volume (full-file reads), as they lack the window information required for partial access. Conversely, "I2G Only" and "Full" (Ours) achieve minimal I/O volume ($\approx 10\%$).However, I/O volume alone does not tell the full story. Fig.~\ref{fig:index_exp3}(b) reveals the latency breakdown:No Index: Suffers from both high metadata scanning cost (full table scan) and high storage I/O cost.G2I Only: Efficiently reduces metadata lookup time ($\approx 50$ ms) but fails to reduce storage I/O ($\approx 8000$ ms).I2G Only: Although it minimizes storage I/O ($\approx 100$ ms), it incurs prohibitive metadata lookup overhead ($\approx 1500$ ms) because the system must scan the entire I2G table to identify relevant images without spatial pruning.G2I + I2G (Ours): Achieves the "best of both worlds," maintaining low metadata latency ($\approx 60$ ms) via G2I pruning while ensuring minimal storage I/O ($\approx 100$ ms) via I2G windowing.
+To quantify the individual contributions of the G2I (coarse filtering) and I2G (fine-grained access) components, we decomposed the system into four variants. Fig.~\ref{fig:index_exp3} breaks down the performance in terms of I/O volume and latency components. Fig.~\ref{fig:index_exp3}(a) confirms that removing either component leads to suboptimal I/O behavior. The "No Index" and "G2I Only" variants result in 100\% I/O volume, as they lack the window information required for partial access. Conversely, "I2G Only" and "Full" (Ours) achieve minimal I/O volume ($\approx 10\%$).
 
-Moreover, the choice of grid resolution (Zoom Level) is a critical parameter that dictates the trade-off between metadata management overhead ($C_{meta}$) and I/O precision ($C_{io}$). To justify our selection of Zoom Level 14, we conducted a sensitivity analysis by varying the grid resolution from Level 12 to Level 16 under a fixed workload of medium-scale range queries. Fig.~\ref{fig:index_exp3_3} illustrates the latency breakdown across different resolutions. The results reveal a clear convex trajectory in total query latency, driven by two opposing forces. For coarse-grained grids (Level $\le 13$), while metadata lookup is extremely fast ($C_{meta} < 30$ ms) due to the small number of grid keys, the I/O cost ($C_{io}$) is prohibitively high. Large grid cells force the system to read significant amounts of irrelevant pixel data outside the actual query boundary (high read amplification), serving as the dominant bottleneck. Conversely, finer grids (Level 15, 16) maximize I/O precision, reducing $C_{io}$ to its theoretical minimum. However, this comes at the cost of an explosion in metadata volume. A single query may intersect thousands of Level 16 micro-grids, causing $C_{meta}$ to surge drastically ($>280$ ms) due to the overhead of scanning and processing massive key lists in the G2I/I2G tables. As evidenced by the trough in the total latency curve, Zoom Level 14 represents the optimal "sweet spot" for our dataset. At this resolution, the grid cell size (approx. $20 \times 20$ meters at the equator) roughly matches the typical internal tile size of remote sensing images, keeping I/O waste low while maintaining a manageable number of index keys. Consequently, our system adopts Level 14 as the default global configuration.
+Fig.~\ref{fig:index_exp3}(b) reveals the latency breakdown. "No Index" suffers from both high full table scanning cost and high storage I/O cost. "G2I Only" efficiently reduces metadata lookup time ($\approx 50$ ms) but fails to reduce storage I/O ($\approx 8000$ ms). Although "I2G Only" minimizes storage I/O ($\approx 100$ ms), it incurs prohibitive metadata lookup overhead ($\approx 1500$ ms) because the system must scan the entire I2G table to identify relevant images without spatial pruning. "G2I + I2G" achieves the best performance, maintaining low metadata latency ($\approx 60$ ms) via G2I pruning while ensuring minimal storage I/O ($\approx 100$ ms) via I2G windowing.
+
+Moreover, the choice of grid resolution (Zoom Level) is a critical parameter that dictates the trade-off between metadata management overhead and I/O precision. To justify our selection of Zoom Level 14, we conducted a sensitivity analysis by varying the grid resolution from Level 12 to Level 16 under a fixed workload of medium-scale range queries. Fig.~\ref{fig:index_exp3_3} illustrates the latency breakdown across different resolutions. The results reveal a clear convex trajectory in total query latency, driven by two opposing forces. For coarse-grained grids (Level $\le 13$), while metadata lookup is extremely fast ($C_{meta} < 30$ ms) due to the small number of grid keys, the I/O cost is prohibitively high. Large grid cells force the system to read significant amounts of irrelevant pixel data outside the actual query boundary, serving as the dominant bottleneck. Conversely, finer grids (Level 15, 16) maximize I/O precision, reducing $C_{io}$ to its theoretical minimum. However, this comes at the expense of increased metadata volume. A single query may intersect thousands of Level 16 micro-grids, causing $C_{meta}$ to surge drastically ($>100$ ms) due to the overhead of scanning and processing massive key lists in the G2I/I2G tables. As evidenced by the trough in the total latency curve, Zoom Level 14 represents the optimal spot for our dataset. At this resolution, the grid cell size roughly matches the typical internal tile size of remote sensing images, keeping I/O waste low while maintaining a manageable number of index keys. Consequently, our system adopts Level 14 as the default global configuration.
 
 \subsubsection{Index Construction and Storage Overhead}
 \begin{figure}[tb]
 	\centering
-	\subfigure[Ingestion Scalability]{
+		\subfigure[Ingested images ($10^4$)]{
 		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.9\textwidth]{exp/index_exp4_1.pdf}
-		\end{minipage}
-	}
-	\label{fig:index_exp4_1}
-	\subfigure[Storage Consumption Overhead]{
-		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.9\textwidth]{exp/index_exp4_2.pdf}
+			\includegraphics[width=0.98\textwidth]{exp/index_exp4_2.pdf}
 		\end{minipage}
 	}
 	\label{fig:index_exp4_2}
-	\caption{Index Construction and Storage Overhead}
+	\subfigure[Various index types]{
+		\begin{minipage}[b]{0.227\textwidth}
+			\includegraphics[width=0.92\textwidth]{exp/index_exp4_1.pdf}
+		\end{minipage}
+	}
+	\label{fig:index_exp4_1}
+	\caption{Index construction and storage overhead}
 	\label{fig:index_exp4}
 \end{figure}
 
 \par
-Finally, we evaluated the scalability and cost of maintaining the index. Fig.~\ref{fig:index_exp4} compares our method against PostGIS (R-tree) and GeoMesa (Z-order) during the ingestion of $10^6$ images.Fig.~\ref{fig:index_exp4}(a) illustrates the ingestion throughput. PostGIS exhibits a degrading trend as the dataset grows, bottlenecked by the logarithmic cost of R-tree rebalancing. In contrast, Ours maintains a stable throughput ($\approx 2100$ img/sec). Although slightly lower than the lightweight GeoMesa ($\approx 2500$ img/sec) due to the dual-table write overhead, our method demonstrates linear scalability suitable for high-velocity streaming data.Regarding storage cost (Fig.~\ref{fig:index_exp4}(b)), our index occupies approximately 0.83\% of the raw data size. While this is higher than GeoMesa (0.15\%) and PostGIS (0.51\%) due to the storage of grid-window mappings, it remains strictly below the 1\% threshold. This result validates that the proposed method achieves significant performance gains with a negligible storage penalty.
+Finally, we evaluated the scalability and cost of maintaining the index. Fig.~\ref{fig:index_exp4} compares our method against PostGIS (R-tree) and GeoMesa (Z-order) during the ingestion of $7\times 10^5$ images. Fig.~\ref{fig:index_exp4}(a) illustrates the ingestion throughput. PostGIS exhibits a degrading trend as the dataset grows, bottlenecked by the logarithmic cost of R-tree rebalancing. In contrast, Ours maintains a stable throughput ($\approx 2100$ img/s). Although slightly lower than the lightweight GeoMesa ($\approx 2500$ img/s) due to the dual-table write overhead, our method demonstrates linear scalability suitable for high-velocity streaming data. Regarding storage cost (Fig.~\ref{fig:index_exp4}(b)), our index occupies approximately 0.83\% of the raw data size. While this is higher than GeoMesa (0.15\%) and PostGIS (0.51\%) due to the storage of grid-window mappings, it remains strictly below the 1\% threshold. This result validates that the proposed method achieves significant performance gains with a negligible storage penalty.
 
 \subsection{Evaluating the Concurrency Control}
-In this section, we evaluate the proposed hybrid coordination mechanism on a distributed storage cluster to assess its scalability, robustness under contention, and internal storage efficiency. We investigated end-to-end latency, throughput, tail latency, and I/O amplification under varying degrees of concurrency and spatial contention.
+In this section, we evaluate the proposed hybrid coordination mechanism on a distributed storage cluster to assess its scalability, robustness under contention, and internal storage efficiency.
 
 \par
-To systematically control the workload characteristics, we developed a synthetic workload generator. We define the \textit{Spatial Overlap Ratio} ($\sigma$) to quantify the extent of shared data regions among concurrent queries, ranging from $\sigma=0$ (disjoint) to $\sigma=0.9$ (highly concentrated hotspots). The number of concurrent clients varies from $N=1$ to $N=64$.
+To systematically control the workload characteristics, we developed a synthetic workload generator. We define the Spatial Overlap Ratio ($\sigma$) to quantify the extent of shared data regions among concurrent queries, ranging from $\sigma=0$ (disjoint) to $\sigma=0.9$ (highly concentrated hotspots). The number of concurrent clients varies from $N=1$ to $N=64$. It is worth noting that given the data-intensive nature of remote sensing queries where a single request triggers GB-scale I/O and complex decoding, 64 concurrent streams are sufficient to fully saturate the aggregate I/O bandwidth and CPU resources of our experimental cluster, representing a heavy-load scenario in operational scientific computing environments.
+
 For comparison, we evaluate the following execution schemes:
 \begin{enumerate}
-	\item \textbf{Baseline A (Naive):} Queries function as isolated threads with independent I/O execution.
-	\item \textbf{Baseline B (Shared Index):} Metadata access is shared, but data retrieval remains uncoordinated, representing the state-of-the-practice in systems like GeoMesa.
+	\item \textbf{Baseline (Shared Index):} Metadata access is shared, but data retrieval remains uncoordinated, representing the state-of-the-art systems like OpenDataCube.
 	\item \textbf{Ours:} The proposed mechanism featuring contention-aware switching, global I/O plan ordering, and window merging.
 \end{enumerate}
 
 \subsubsection{Concurrency Scalability}
-\begin{figure}[tb]
+\begin{figure*}[htb]
 	\centering
-	\subfigure[The query latency]{
-		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.98\textwidth]{exp/cc_exp1_1.pdf}
-		\end{minipage}
-	}
-	\label{fig:cc_exp1_1}
-	\subfigure[Aggregate Throughput]{
-		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.905\textwidth]{exp/cc_exp1_2.pdf}
-		\end{minipage}
-	}
-	\label{fig:cc_exp1_2}
-	\caption{The computing cost of spatial-keyword skylines}
+	\subfigure[$\sigma=0.4$]{\label{fig:cc_exp1_3}
+		\includegraphics[width=2.1in]{exp/cc_exp1_3.pdf}}
+	\subfigure[$\sigma=0.6$]{\label{fig:cc_exp1_2}
+		\includegraphics[width=2.1in]{exp/cc_exp1_2.pdf}}
+	%\subfigure[]{\label{fig:trans_candidate}
+		%\includegraphics[width=0.6in]{trans_candidate.eps}}
+	\subfigure[$\sigma=0.8$]{\label{fig:cc_exp1_1}
+		\includegraphics[width=2.1in]{exp/cc_exp1_1.pdf}}
+	%\subfigure[]{\label{fig:diagram3}
+		%\includegraphics[width=0.7in]{routing.eps}}
+	\caption{% (a) Illustration of avoiding couplers.
+		Concurrency scalability analysis under varying spatial overlap ratios ($\sigma$).}
 	\label{fig:cc_exp1}
-\end{figure}
+\end{figure*}
 
-\par
-First, we investigated the system scalability by increasing the number of concurrent clients from 1 to 64 under a high-overlap scenario ($\sigma \approx 0.8$). Fig.~\ref{fig:cc_exp1} reports the mean latency, P95 tail latency, and aggregate throughput. Note that the latency axes in Fig.~\ref{fig:cc_exp1}(a) are plotted on a log scale to visualize the orders-of-magnitude difference.
+To evaluate the system's robustness under different workload characteristics, we conducted a sensitivity analysis by manipulating the Spatial Overlap Ratio ($\sigma$). We examined three distinct scenarios: low overlap ($\sigma=0.4$, simulating dispersed random queries), medium overlap ($\sigma=0.6$), and high overlap ($\sigma=0.8$, simulating hotspot analysis). Note that $\sigma=0.4$ is defined as a low overlap scenario because: when $\sigma \le 0.35$, the performance of the deterministic scheduling mode is even lower than that of the optimistic mode (See Sec.~\ref{sec:ModeSwitch}). So, the performance of our method is the same as the Baseline when $\sigma \le 0.35$. Fig.~\ref{fig:cc_exp1} illustrates the query latency trends as the number of concurrent clients increases from 1 to 64.
 
-\par
-As shown in Fig.~\ref{fig:cc_exp1}(a), both Baseline A and Baseline B exhibit exponential latency degradation. At 64 clients, the mean latency of Baseline A spikes to 12,000 ms, indicating severe storage saturation. This bottleneck arises from the ``I/O blender effect,'' where randomized concurrent reads trigger severe disk seek thrashing. In contrast, Ours maintains a stable latency profile, increasing only marginally to 110 ms at 64 clients.
+The results reveal a fundamental divergence in how the two systems respond to data contention. As shown in Fig.~\ref{fig:cc_exp1}(a), when query footprints are spatially dispersed, the opportunities for physical I/O merging are minimal. Consequently, the performance of both systems is primarily constrained by the aggregate physical bandwidth of the storage cluster. Both approaches exhibit linear latency growth with respect to the client count. At $N=64$, the Baseline reaches a mean latency of approx. 37,000 ms, while our method records approx. 30,000 ms. Although our method maintains a slight performance edge due to the reduced read amplification provided by the I/O-aware index, it inevitably degrades to a linear query processing mode similar to the Baseline. This confirms that without spatial locality to leverage request collapsing, the system is bound by the hardware's I/O throughput limits.
 
-\par
-Fig.~\ref{fig:cc_exp1}(b) further demonstrates the throughput advantage. While Baselines saturate at approximately 16--32 clients, Ours demonstrates super-linear throughput scaling relative to logical requests. This is attributed to the request collapse mechanism, where higher concurrency increases the probability of window merging, thereby reducing the physical I/O cost per query.
+A sharp performance divergence is observed as the overlap ratio increases to $\sigma=0.8$ (Fig.~\ref{fig:cc_exp1}(b)). The Baseline suffers from severe performance degradation, with latency spiking from 37,000 ms (at $\sigma=0.2$) to 60,000 ms (at $\sigma=0.8$) under peak load. This deterioration is attributed to the "I/O blender effect" and lock convoys: highly concurrent requests competing for the same index pages and disk blocks cause excessive disk seek thrashing and thread blocking, significantly reducing effective throughput. Conversely, our method demonstrates \textit{sub-linear scalability} in this scenario. The latency at $N=64$ drops significantly to 1,100 ms—a $54\times$ speedup over the Baseline. This result validates the efficacy of the \textit{Request Collapse} mechanism. As $\sigma$ increases, the probability of multiple logical queries targeting the same physical byte ranges rises, allowing the scheduler to merge $N$ concurrent requests into a single physical I/O operation.
 
-\subsubsection{Tail Latency and Contention Sensitivity}
-\begin{figure}[tb]
-	\centering
-	\subfigure[Tail Latency Sensitivity]{
-		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.9\textwidth]{exp/cc_exp2_1.pdf}
-		\end{minipage}
-	}
-	\label{fig:cc_exp2_1}
-	\subfigure[Fairness under Contention]{
-		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.9\textwidth]{exp/cc_exp2_2.pdf}
-		\end{minipage}
-	}
-	\label{fig:cc_exp2_2}
-	\caption{Tail Latency and Contention Sensitivity}
-	\label{fig:cc_exp2}
-\end{figure}
-
-\par
-Next, we fixed the concurrency at $N=32$ and swept the Spatial Overlap Ratio $\sigma$ from 0 to 0.9 to evaluate the system's resilience to hotspots. Fig.~\ref{fig:cc_exp2} depicts the P95 latency and fairness index.
-
-\par
-Intuitively, higher contention typically degrades performance. However, Fig.~\ref{fig:cc_exp2}(a) reveals a \emph{counter-intuitive} phenomenon for our system: the P95 latency remains flat ($\approx 48$ ms) even as $\sigma$ approaches 0.9. This indicates that our coordination mechanism successfully converts contention'' into optimization opportunities'' via window merging. Conversely, both Baselines exhibit a sharp ``performance cliff'' when $\sigma > 0.5$, with Baseline A reaching 8,500 ms at $\sigma=0.9$.
-
-\par
-Furthermore, Fig.~\ref{fig:cc_exp2}(b) shows that our system maintains a Jain’s Fairness Index near 1.0, whereas Baselines drop to 0.25--0.35. This confirms that the deterministic plan queue effectively prevents the starvation of queries accessing contended regions.
+The medium-overlap scenario (Fig.~\ref{fig:cc_exp1}(c)) serves as a transition point, where our method achieves a mean latency of approx. 6,000 ms at peak load, compared to 40,000 ms for the Baseline. This indicates that the system's efficiency scales dynamically with the degree of data contention. The experimental results demonstrate the workload-adaptive nature of the proposed architecture. While the system performs comparably to traditional approaches under dispersed workloads (limited by physical bandwidth), its advantages become order-of-magnitude significant in data-intensive, high-contention scenarios, effectively turning I/O contention into an opportunity for optimization.
 
 \subsubsection{Storage-Level Effects and Request Collapse}
 \begin{figure}[tb]
 	\centering
-	\subfigure[Data Volume Reduction]{
+	\subfigure[The number of clients]{
 		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.9\textwidth]{exp/cc_exp3_1.pdf}
+			\includegraphics[width=0.95\textwidth]{exp/cc_exp3_1.pdf}
 		\end{minipage}
 	}
 	\label{fig:cc_exp3_1}
-	\subfigure[Request Collapse (IOPS)]{
+	\subfigure[The number of clients]{
 		\begin{minipage}[b]{0.227\textwidth}
-			\includegraphics[width=0.9\textwidth]{exp/cc_exp3_2.pdf}
+			\includegraphics[width=0.95\textwidth]{exp/cc_exp3_2.pdf}
 		\end{minipage}
 	}
 	\label{fig:cc_exp3_2}
-	\caption{Storage-Level Effects and Request Collapse}
+	\caption{The data volume reduction and request collapse}
 	\label{fig:cc_exp3}
 \end{figure}
 
-\begin{figure}
-	\centering
-	\includegraphics[width=1.8in]{exp/cc_exp3_3.pdf}
-	\caption{Merging Efficiency}
-	\label{fig:cc_exp3_3}
-\end{figure}
+To uncover the cause of the significant latency reduction observed in high-contention scenarios ($\sigma=0.8$),, we further analyzed the internal I/O behavior of the system. Specifically, we measured the total volume of physical data transferred from disk and the number of backend I/O requests issued to the storage system. Fig.~\ref{fig:cc_exp3} compares the physical storage pressure between the shared index baseline and ours method.
+
+Fig.~\ref{fig:cc_exp3}(a) plots the total physical data read size. The baseline exhibits a strict linear increase in data volume. At $N=64$, the system is forced to fetch 32 GB of data. This confirms that without coordination, logically overlapping queries translate into redundant physical reads, leading to severe bandwidth saturation. In contrast, our approach effectively decouples logical demand from physical execution. Although 64 clients logically request 32 GB of data, the request collapse mechanism merges these overlapping windows, resulting in only 5 GB of actual disk traffic. This 84\% reduction in data volume explains why our system avoids the bandwidth bottleneck.
+
+Fig.~\ref{fig:cc_exp3}(b) illustrates the number of backend I/O requests (IOPS). The baseline generates distinct I/O requests for every client, reaching 12,800 requests at $N=64$. This massive influx of small random reads overwhelms the storage scheduler, causing excessive disk head seek latency. Our system keeps the request count low and stable. Even at peak load ($N=64$), the number of physical I/O requests is suppressed to 2,000.
 
 \par
 To explain the performance gains observed above, we analyzed the internal I/O behavior. Fig.~\ref{fig:cc_exp3} compares the physical data movement against logical query demands. Note that in this experiment, Baseline A and Baseline B are grouped as a single baseline, as neither implements window-level coordination.
 
 \par
-Fig.~\ref{fig:cc_exp3}(a) and Fig.~\ref{fig:cc_exp3}(b) demonstrate the Request Collapse effect. While 64 concurrent clients generate 12,800 IOPS in the baseline, our system collapses them into fewer than 600 physical operations. Fig.~\ref{fig:cc_exp3_3} quantifies this using the Merging Efficiency. As the overlap ratio $\sigma$ increases, the I/O amplification factor of our system drops linearly from 1.0 to 0.15. This mathematically proves that the throughput gains are derived from a fundamental reduction in physical I/O volume rather than mere CPU scheduling.
+Fig.~\ref{fig:cc_exp3}(a) and Fig.~\ref{fig:cc_exp3}(b) demonstrate the Request Collapse effect. While 64 concurrent clients generate 12,800 IOPS in the baseline, our system collapses them into fewer than 600 physical operations.
 
-\subsubsection{Deterministic vs Non-Deterministic Modes}
+\subsubsection{Deterministic and Non-Deterministic Modes}\label{sec:ModeSwitch}
 \begin{figure}
 	\centering
-	\includegraphics[width=1.8in]{exp/cc_exp4_1.pdf}
-	\caption{Adaptive Performance Switching}
+	\includegraphics[width=1.8in]{exp/cc_exp4.pdf}
+	\caption{Mode Switching}
 	\label{fig:cc_exp4}
 \end{figure}
 
 \par
-We then validated the effectiveness of the hybrid switching logic by comparing it against static Forced Optimistic'' and Forced Deterministic'' policies. As shown in Fig.~\ref{fig:cc_exp4}, the static policies exhibit distinct weaknesses: the Deterministic mode incurs high coordination overhead ($\approx 60$ ms) at low $\sigma$, while the Optimistic mode suffers from exponential thrashing at high $\sigma$. The Hybrid curve successfully tracks the lower performance envelope of the two.
+To validate the necessity of the proposed hybrid switching mechanism, we compared our adaptive approach against two static execution policies: non-deterministic and deterministic mode. We swept the spatial overlap ratio from 0 to 0.9 to capture the performance crossover zone. The workload concurrency was fixed at a moderate level ($N=16$) to highlight the sensitivity to spatial contention.
 
-\subsubsection{Microbenchmark of Window Merging}
-\begin{figure*}[htb]
-	\centering
-	\subfigure[Reduction Pipeline]{\label{fig:cc_exp5_1}
-		\includegraphics[width=2.1in]{exp/cc_exp5_1.pdf}}
-	\subfigure[Run Length Distribution]{\label{fig:cc_exp5_2}
-		\includegraphics[width=2.1in]{exp/cc_exp5_2.pdf}}
-	%\subfigure[]{\label{fig:trans_candidate}
-		%\includegraphics[width=0.6in]{trans_candidate.eps}}
-	\subfigure[Cost-Benefit Analysis]{\label{fig:cc_exp5_3}
-		\includegraphics[width=2.1in]{exp/cc_exp5_3.pdf}}
-	%\subfigure[]{\label{fig:diagram3}
-		%\includegraphics[width=0.7in]{routing.eps}}
-	\caption{% (a) Illustration of avoiding couplers.
-		Microbenchmark of Window Merging}
-	\label{fig:cc_exp5}
-\end{figure*}
+Fig.~\ref{fig:cc_exp4} depicts the average latency curves for the three strategies. The results demonstrate that neither static policy is universally optimal, validating the design of our contention-aware switch. In the low-overlap condition, the non-deterministic mode achieves the lower latency. In contrast, the deterministic mode incurs a higher baseline latency. This performance gap is attributed to the inherent coordination overhead. Even when no conflicts exist, the deterministic scheduler must still perform time-window batching and plan sorting. Consequently, enforcing global ordering for disjoint queries introduces unnecessary serialization latency.
 
-\par
-Finally, we dissected the efficiency of the three-stage reduction pipeline. Fig.~\ref{fig:cc_exp5_1} shows that the combination of De-duplication (Stage 1) and Range Merging (Stage 2) achieves a cumulative reduction in request count consistent with the findings in Section 5.3.3.
+As $\sigma$ increases, the non-deterministic approach suffers from rapid performance deterioration, exhibiting an exponential growth trend. At $\sigma=0.4$, its latency spikes to 146 ms. This degradation is caused by severe lock and "I/O" contention and at the storage layer, where uncoordinated threads compete for the same disk blocks. Conversely, the deterministic mode exhibits stable, linear scalability thanks to its request merging capability, maintaining a latency of 110 ms at $\sigma=0.4$.
 
-\par
-Fig.~\ref{fig:cc_exp5_2} presents the Run Length Distribution (CDF) of I/O requests. The proposed mechanism shifts the I/O pattern from small, fragmented reads (typical in baselines) to larger, sequential chunks, which significantly amortizes disk seek times.Fig.~\ref{fig:cc_exp5_3} presents the cost-benefit analysis. The CPU overhead of the dispatcher remains negligible ($< 2.5 \mu s$ per window) compared to the benefit of achieving a $>90\%$ zero-copy ratio, verifying that the algorithmic complexity of coordination yields a high return on investment in terms of system throughput.
+Our hybrid approach successfully combines the benefits of both worlds. As shown in Fig.~\ref{fig:cc_exp4}, the hybrid curve (blue line) tightly tracks the lower performance envelope of the two static policies. The system identifies the intersection point at $\sigma \approx 0.34$. When contention is below this threshold, it operates optimistically to minimize latency. Once contention exceeds it, the system automatically engages the deterministic scheduler to prevent thrashing.
 
 \subsection{Evaluating the I/O tuning}
 In this section, we evaluate the effectiveness of the proposed SA-GMAB tuning framework. The experiments are designed to verify four key properties: fast convergence speed, robustness against stochastic noise, adaptability to workload shifts, and tangible end-to-end performance gains.
 
+For comparison, For comparison, we benchmark against three representative tuning strategies: 
+
+\begin{enumerate} 
+	\item \textbf{Genetic algorithm (GA):} The standard genetic algorithm to explore the configuration space, serving as the basic algorithm in the TunIO.
+	\item \textbf{TunIO:} A state-of-the-art framework that integrates high-impact parameter selection and Reinforcement Learning (RL)-driven early stopping to balance tuning cost and performance in complex HPC I/O stacks.
+	\item \textbf{SA-GMAB (Ours):} The proposed framework combining surrogate modeling with a Genetic Multi-Armed Bandit strategy, explicitly designed to accelerate convergence and handle the stochastic performance fluctuations of concurrent workloads.
+\end{enumerate}
+
 \subsubsection{Convergence Speed and Tuning Cost}
-\begin{figure*}[htb]
+\begin{figure}[tb]
 	\centering
-	\subfigure[Convergence Speed]{\label{fig:tune_exp1_1}
-		\includegraphics[width=2.1in]{exp/tune_exp1_1.pdf}}
-	\subfigure[Cumulative Tuning Overhead]{\label{fig:tune_exp1_2}
-		\includegraphics[width=2.1in]{exp/tune_exp1_2.pdf}}
-	%\subfigure[]{\label{fig:trans_candidate}
-		%\includegraphics[width=0.6in]{trans_candidate.eps}}
-	\subfigure[Search Efficiency]{\label{fig:tune_exp1_3}
-		\includegraphics[width=2.1in]{exp/tune_exp1_3.pdf}}
-	%\subfigure[]{\label{fig:diagram3}
-		%\includegraphics[width=0.7in]{routing.eps}}
-	\caption{% (a) Illustration of avoiding couplers.
-		Convergence Speed and Tuning Cost}
+	\subfigure[Tuning steps]{
+		\begin{minipage}[b]{0.227\textwidth}
+			\includegraphics[width=0.95\textwidth]{exp/tune_exp1_1.pdf}
+		\end{minipage}
+	}
+	\label{fig:tune_exp1_1}
+	\subfigure[Time (mins)]{
+		\begin{minipage}[b]{0.227\textwidth}
+			\includegraphics[width=0.95\textwidth]{exp/tune_exp1_2.pdf}
+		\end{minipage}
+	}
+	\label{fig:tune_exp1_2}
+	\caption{Efficiency analysis of the tuning framework.}
 	\label{fig:tune_exp1}
-\end{figure*}
+\end{figure}
 
-\par
-First, we initiated a cold-start tuning session to evaluate how efficiently each method identifies high-quality configurations. Fig.~\ref{fig:tune_exp1} reports the convergence trajectory, cumulative tuning cost, and search efficiency.
+We first initiated a cold-start tuning session to evaluate how efficiently each method identifies high-quality configurations starting from a default, unoptimized state. Fig.~\ref{fig:tune_exp1}(a) reports the convergence trajectory of the best-observed latency over tuning steps.
 
-\par
-As shown in Fig.~\ref{fig:tune_exp1_1}, the \textbf{Default} configuration remains trapped in a high-latency state ($\approx 450$ ms). While \textbf{H5Tuner} and \textbf{TunIO} gradually improve performance, they exhibit slow decay rates, requiring over 80 steps to stabilize. In contrast, \textbf{SA-GMAB} achieves a sharp drop in best-observed latency within the first 15--20 steps. This acceleration is attributed to the surrogate model, which effectively prunes unpromising configurations before costly execution.
+As illustrated in Fig.~\ref{fig:tune_exp1}(a), the three methods exhibit distinct search behaviors. The GA baseline demonstrates the slowest convergence. It exhibits a staircase-like descent with prolonged plateaus, requiring over 100 steps to reduce latency significantly. This sluggishness is attributed to its "blind" mutation mechanism, which lacks historical memory and repeatedly explores ineffective parameter spaces. The RL-based TunIO outperforms GA but still suffers from a slow start. While it eventually reaches a competitive latency ($\approx 277$ ms at step 140), its exploration phase is costly. The reinforcement learning agent requires a substantial number of interaction samples to learn the complex mapping between I/O parameters and reward signals. Our method achieves the fastest latency drop, rapidly decreasing from $500$ ms to a near-optimal zone ($\approx 315$ ms) within a short window. Unlike GA and TunIO, SA-GMAB leverages the surrogate model to pre-screen candidates. By effectively pruning unpromising configurations before they incur actual execution costs, SA-GMAB maximizes the information gain per step, making it particularly suitable for online scenarios where tuning overhead must be minimized.
 
-\par
-Fig.~\ref{fig:tune_exp1_2} plots the cumulative tuning overhead (regret). The steep slope of the GA-based baselines indicates that they repeatedly explore poor configurations due to their memory-less nature. Our method exhibits the flattest curve, minimizing the cumulative performance loss during exploration. Furthermore, Fig.~\ref{fig:tune_exp1_3} confirms the high sample efficiency: SA-GMAB reaches the near-optimal zone ($\approx 50$ ms) after evaluating significantly fewer unique configurations compared to H5Tuner and TunIO.
+To strictly quantify the cost-effectiveness of the tuning process, we adopt the \textit{Return on Tuning Investment} (RoTI) metric proposed in TunIO \cite{Rajesh24TunIO}. We define the application performance $\mathcal{P}$ as the reciprocal of the query latency (i.e., $\mathcal{P} \propto 1/\mathcal{L}$). The RoTI metric is formalized as follows:
 
-\subsubsection{Robustness under Stochastic Interference}
-\begin{figure*}[htb]
-	\centering
-	\subfigure[Reward Stability under Noise]{\label{fig:tune_exp2_1}
-		\includegraphics[width=2.1in]{exp/tune_exp2_1.pdf}}
-	\subfigure[Regret Growth]{\label{fig:tune_exp2_2}
-		\includegraphics[width=2.1in]{exp/tune_exp2_2.pdf}}
-	%\subfigure[]{\label{fig:trans_candidate}
-		%\includegraphics[width=0.6in]{trans_candidate.eps}}
-	\subfigure[Configuration Stability]{\label{fig:tune_exp2_3}
-		\includegraphics[width=2.1in]{exp/tune_exp2_3.pdf}}
-	%\subfigure[]{\label{fig:diagram3}
-		%\includegraphics[width=0.7in]{routing.eps}}
-	\caption{% (a) Illustration of avoiding couplers.
-		Robustness under Stochastic Interference}
-	\label{fig:tune_exp2}
-\end{figure*}
+\begin{equation}
+	\label{eq:roti}
+	RoTI(t) = \frac{\mathcal{P}_{achieved}(t) - \mathcal{P}_{initial}}{t},
+\end{equation}
+where $t$ denotes the cumulative tuning time (overhead). $\mathcal{P}_{initial} = 1 / \mathcal{L}_{0}$ represents the baseline performance derived from the default configuration, and $\mathcal{P}_{achieved}(t) = 1 / \mathcal{L}_{t}$ represents the maximum performance achieved up to time $t$. Functionally, this metric represents the "performance gain purchased per unit of tuning time." A higher RoTI value signifies that the optimizer rapidly identifies low-latency configurations with minimal computational overhead.
 
-\par
-In concurrent I/O environments, performance measurements are inherently noisy. Fig.~\ref{fig:tune_exp2} evaluates the robustness of the tuning algorithms under such stochastic interference.
-
-\par
-Fig.~\ref{fig:tune_exp2_1} tracks the instantaneous reward over time. \textbf{H5Tuner} exhibits high variance, frequently dropping to low-reward regions because it discards good configurations that perform poorly once due to transient noise. In contrast, \textbf{SA-GMAB} maintains a stable high-reward trajectory. By aggregating historical observations in the memory table, our method ``smooths out'' the noise and correctly identifies optimal configurations despite fluctuations. Fig.~\ref{fig:tune_exp2_3} further breaks down the decision quality. Our method selects the \textbf{Optimal Configuration} for \textbf{88\%} of the rounds, whereas H5Tuner selects it only \textbf{35\%} of the time, wasting the majority of its budget on suboptimal or poor parameters.
+Fig.~\ref{fig:tune_exp1_2} plots the RoTI curves over time. Our method (SA-GMAB) reaches a remarkable RoTI peak ($\approx 100$) at the early stage ($t=825$). This indicates that SA-GMAB yields the highest immediate return on investment, successfully locating high-quality configurations when the tuning budget is strictly limited. In contrast, TunIO peaks at a significantly lower value ($\approx 68$), while GA remains flat and inefficient ($\approx 46$). This confirms that the surrogate-assisted mechanism effectively amplifies the value of each exploration step. All curves exhibit a decaying trend as time progresses ($t \rightarrow \infty$). This is expected behavior: as the system converges to the global optimum, the marginal performance gain ($\Delta \mathcal{P}$) saturates while the accumulated time $t$ continues to grow. Notably, SA-GMAB's RoTI decays faster in the late stages simply because it has already exhausted the potential for improvement much earlier than the baselines.
 
 \subsubsection{Adaptation to Workload Shifts}
-\begin{figure*}[htb]
+\begin{figure}
 	\centering
-	\subfigure[Response to Workload Shift]{\label{fig:tune_exp3_1}
-		\includegraphics[width=2.1in]{exp/tune_exp3_1.pdf}}
-	\subfigure[Parameter Adaptation]{\label{fig:tune_exp3_2}
-		\includegraphics[width=2.1in]{exp/tune_exp3_2.pdf}}
-	%\subfigure[]{\label{fig:trans_candidate}
-		%\includegraphics[width=0.6in]{trans_candidate.eps}}
-	\subfigure[Speed of Adaptation]{\label{fig:tune_exp3_3}
-		\includegraphics[width=2.1in]{exp/tune_exp3_3.pdf}}
-	%\subfigure[]{\label{fig:diagram3}
-		%\includegraphics[width=0.7in]{routing.eps}}
-	\caption{% (a) Illustration of avoiding couplers.
-		Adaptation to Workload Shifts}
+	\includegraphics[width=1.8in]{exp/tune_exp3_1.pdf}
+	\caption{Mode Switching}
 	\label{fig:tune_exp3}
-\end{figure*}
+\end{figure}
 
-\par
-We then investigated the system's ability to adapt to non-stationary environments. We introduced a sudden workload shift at $t=60$, changing the query pattern from sparse random access to dense sequential scans.
-
-\par
-As illustrated in Fig.~\ref{fig:tune_exp3_1}, the shift causes an immediate latency spike ($>300$ ms) for all methods. The \textbf{Default} policy fails to adapt. \textbf{H5Tuner} reacts sluggishly, requiring many generations to evolve parameters for the new regime. \textbf{SA-GMAB}, however, detects the context change and leverages its surrogate model to rapidly propose new candidates, achieving a full recovery to the new optimal latency ($\approx 80$ ms) within fewer than 15 batches (Fig.~\ref{fig:tune_exp3_3}).Fig.~\ref{fig:tune_exp3_2} traces the evolution of the \textit{Merge Threshold} parameter. While baselines drift slowly, our method executes a decisive shift from 0.2 to 0.8, effectively locking onto the new optimal region required by the sequential workload.
-
-\subsubsection{Impact on End-to-End Query Performance}
-\begin{figure*}[htb]
-	\centering
-	\subfigure[Steady-State Stability]{\label{fig:tune_exp4_1}
-		\includegraphics[width=2.1in]{exp/tune_exp4_1.pdf}}
-	\subfigure[End-to-End Throughput]{\label{fig:tune_exp4_2}
-		\includegraphics[width=2.1in]{exp/tune_exp4_2.pdf}}
-	%\subfigure[]{\label{fig:trans_candidate}
-		%\includegraphics[width=0.6in]{trans_candidate.eps}}
-	\subfigure[I/O Efficiency Tuning]{\label{fig:tune_exp4_3}
-		\includegraphics[width=2.1in]{exp/tune_exp4_3.pdf}}
-	%\subfigure[]{\label{fig:diagram3}
-		%\includegraphics[width=0.7in]{routing.eps}}
-	\caption{% (a) Illustration of avoiding couplers.
-		Impact on End-to-End Query Performance}
-	\label{fig:tune_exp4}
-\end{figure*}
-
-\par
-Finally, we measured the steady-state performance of the fully optimized system. Fig.~\ref{fig:tune_exp4} compares the end-to-end metrics across different tuning methods.
-
-\par
-Fig.~\ref{fig:tune_exp4_1} presents a latency trace during steady-state operation. While \textbf{Default} suffers from high latency and \textbf{GA-based} methods exhibit jitter due to unstable exploration, \textbf{SA-GMAB} maintains a consistently low and smooth latency profile ($\approx 45$ ms). This stability is critical for meeting SLA requirements in real-time analytics. Fig.~\ref{fig:tune_exp4_2} summarizes the aggregate throughput gain. Our method achieves a \textbf{5.6$\times$} improvement over the default configuration. Fig.~\ref{fig:tune_exp4_3} reveals the underlying reason: under high contention, the tuner automatically selects aggressive batching and merging parameters, driving the I/O amplification factor down to \textbf{0.2}. This confirms that SA-GMAB effectively aligns the system configuration with real-time workload characteristics to maximize I/O efficiency.
+We further investigated the system's resilience in non-stationary environments. We introduced a sudden workload shift at tuning step $t=60$, drastically changing the query pattern, from sparse random access to dense sequential scans to invalidate the previously learned optimal parameters.
 
+Fig.~\ref{fig:tune_exp3} illustrates the latency evolution before and after the shift. At $t=60$, the workload transition causes an immediate performance collapse across all methods, with latency spiking from a stable $\approx 50$ ms to $>300$ ms. This confirms that the configuration optimal for the previous phase is detrimental in the new environment. The GA-based method fails to adapt effectively. Post-shift, its latency hovers around $290-300$ ms. Lacking a mechanism to quickly reset or guide exploration, the genetic algorithm remains trapped in the local optima of the previous workload, exhibiting almost zero recovery within the observation window. TunIO manages to reduce latency but at a slow pace. It takes 40 steps to lower the latency from 308 ms to 134 ms ($t=100$). While the RL agent eventually learns the new reward function, the high sample complexity delays the recovery, leaving the system in a suboptimal state for a prolonged period. In contrast, SA-GMAB executes a decisive recovery. By leveraging the surrogate model to filter high-uncertainty candidates, it rapidly identifies the new optimal region. The latency drops to $\approx 88$ ms at $t=80$ and further stabilizes at $\approx 74$ ms at $t=100$.
 
 \section{Conclusions}\label{sec:Con}
-Modern high-performance remote sensing data management systems face a critical bottleneck shift from metadata discovery to data extraction, driven by prohibitive runtime geospatial computations ($C_{geo}$) and severe I/O contention under concurrent access. This paper presents a comprehensive I/O-aware retrieval processing framework designed to strictly bound retrieval latency and maximize throughput for large-scale spatio-temporal analytics. By introducing the "Index-as-an-Execution-Plan" paradigm and a dual-layer inverted structure (G2I and I2G), we bridge the semantic gap between logical indexing and physical storage, effectively shifting the computational burden from retrieval time to ingestion time.To address the scalability challenges in multi-user environments, we developed a hybrid concurrency-aware I/O coordination protocol that adaptively switches between deterministic ordering and optimistic execution based on spatial contention. Furthermore, to handle the complexity of parameter configuration in fluctuating workloads, we integrated a Surrogate-Assisted Genetic Multi-Armed Bandit (SA-GMAB) mechanism for online automatic I/O tuning.Our empirical evaluation on large-scale Sentinel-2 datasets demonstrates that the proposed I/O-aware index reduces end-to-end latency by an order of magnitude compared to standard window-based reading approaches. The hybrid coordination mechanism effectively converts I/O contention into request merging opportunities, achieving linear throughput scaling significantly superior to traditional isolated execution. Additionally, the SA-GMAB tuning method exhibits faster convergence speed and greater robustness against stochastic noise compared to existing genetic baselines. These findings provide a scalable and predictable path for next-generation remote sensing platforms to support real-time, data-intensive concurrent workloads.
+This paper presents a comprehensive I/O-aware retrieval approach designed to strictly bound retrieval latency and maximize throughput for large-scale spatio-temporal analytics. By introducing the "Index-as-an-Execution-Plan" paradigm, the dual-layer inverted index bridge the semantic gap between logical indexing and physical storage, effectively shifting the computational burden from retrieval time to ingestion time. To address the scalability challenges in concurrent environments, we developed a hybrid concurrency-aware I/O coordination protocol that adaptively switches between deterministic ordering and optimistic execution based on spatial contention. Furthermore, to handle the complexity of parameter configuration in fluctuating workloads, we integrated SA-GMAB nethod for online automatic I/O tuning. The experimental results indicate that (1) I/O-aware index achieves an order-of-magnitude latency reduction with negligible storage overhead, (2) the hybrid coordination protocol realizes a $54\times$ throughput improvement in high-overlap scenarios, (3) SA-GMAB method recovers from workload shifts $2\times$ faster than RL baselines while maximizing RoTI. Future work will explore extending the coordination protocol to support more complex analytical operators, such as distributed pixel-level join and aggregation, and integrating the tuning framework with tiered storage hierarchies to further optimize performance in cloud-native environments.
 
 % if have a single appendix:
 %\appendix[Proof of the Zonklar Equations]