{"id":"b7be193b-db6c-49fa-b9a5-2efb139db5c6","arxiv_id":"2501.00068","paper_version":2,"verdict":"REJECT","confidence":"HIGH","novelty_score":2.0,"correctness_risk":"high","formal_verification":"none","parameter_count":6,"one_line_summary":"RL-Storage applies deep Q-learning to storage parameter tuning and claims up to 2.6x throughput gains and 43% latency reduction, but the evidence is not rigorously presented.","lead":"This paper proposes RL-Storage, a reinforcement learning framework that tunes storage parameters such as cache size and queue depth in real time. It reports large performance gains, but provides no code, data, or detailed experimental methodology to back them up.","discovery_kind":"incremental","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The headline results are internally inconsistent: abstract says 2.6x/43%, §IV.A says max 2.3x, conclusion says 3x/50%; no table or methodology explains the spread, so the central claim lacks a stable factual basis.","rationale":"The reader's verdict is REJECT, and I agree. However, the reader's stated weakest assumption is that the Data Collector features (request sizes, access frequencies, latency patterns) may be insufficient for generalization. That is a real concern, but it is secondary. The paper never establishes the primary experimental measurement: the reported gains are internally inconsistent across the abstract, §IV.A, and the Conclusion (2.6x vs. 2.3x max vs. 3x; 43% vs. 50%), and the experimental section is incomplete, with no hardware details, baseline definitions, trial counts, confidence intervals, or artifact. Feature sufficiency cannot be meaningfully assessed if the evaluation itself does not provide a reproducible, internally consistent quantity. The central claim depends on the existence of a large, low-overhead performance improvement; the load-bearing support for that claim is the experiments. Since those experiments are not reproducible and contain contradictory headline numbers, the claim fails on its evidence, not on its feature engineering. The concrete test is therefore to reconstruct a single results table from which all headline numbers can be derived; this would either rehabilitate the claim or make explicit that the numbers were selected inconsistently. No independent evidence offsets these problems: there is no machine-checked proof, no shipped code, and no parameter-free derivation. The paper's self-referential incomplete passages and missing sections, such as the inserted 'sectionExperimental Setup and Results' and equations whose variables are undefined, further support REJECT. I set verdict_should_be UNCHANGED because this stress-test does not move the reader's rejection; it sharpens the reason for it.","tokens_in":5249,"tokens_out":2887,"duration_ms":29749,"concrete_test":"Produce the complete per-configuration results table behind §IV.A: for RocksDB, PostgreSQL, and Redis on both NVMe and SATA SSD, list IOPS, mean latency, p99 latency, and CPU/memory overhead for the baseline heuristic and RL-Storage, with device models, FIO workload parameters, number of runs, and standard deviations. Then verify that the abstract's 2.6x/43%, §IV.A's 1.4–2.3x, and the conclusion's 3x/50% can each be computed as max/mean/median from that same table. If they cannot, or if no such table exists, the central claim is unsupported. A cheaper and still decisive check: rerun the stated FIO workloads with the same parameter ranges and a fixed seed, reporting means and 95% confidence intervals; if the claimed 2.6x improvement is outside the interval, or the baseline heuristic is not precisely defined, the headline result fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The most load-bearing concern is not feature sufficiency but whether the evaluation as presented supports the existence of any stable performance gain. The abstract reports throughput improvements up to 2.6x and latency reductions of 43%; Section IV.A reports '1.4x to 2.3x improvement in throughput' with the highest gains 'up to 2.3x' for mixed workloads on SATA SSDs; the Conclusion reports 'throughput improvements of up to 3x and latency reductions of up to 50%.' These are not minor editorial slips: at most two of the three sets can be correct, and the paper provides no table mapping each number to a workload, device, run, or statistic. The experimental section is also unprocessable: it is inserted as 'sectionExperimental Setup and Results', lists no hardware models, no baseline heuristic definitions, no number of trials, no confidence intervals, and no artifact. The equations intended to define the performance model are not coherent: Eq. (5) defines disk utilization efficiency as P_total divided by a sum of disk operations with no derivation, and Eq. (7) introduces an unexplained scaling factor. Without a table that ties §IV.A and the abstract/conclusion numbers to primary measurements, the central claim that RL-Storage produces 'up to 2.6x' gains is undefined; the inconsistency itself is strong evidence that the experiments were not fully run or reported.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes RL-Storage, a framework that integrates a deep Q-network into the storage stack to dynamically tune cache size, queue depth, and readahead settings. The system is described as having three components: a Data Collector, an RL Inference Engine, and a Feedback Loop. The central claim is that RL-Storage improves throughput by up to 2.6x, reduces latency by 43%, and incurs only 0.11% CPU overhead and 5 KB memory, based on experiments with RocksDB, PostgreSQL, Redis, FIO, and CloudLab traces. The writing is at a high level, but the experimental section appears as an unnumbered insert inside Section III and lacks the detail needed to support the reported gains.","tokens_in":5590,"tokens_out":2908,"duration_ms":31041,"significance":"If the claimed results were supported, RL-Storage would be a useful practical contribution to automated storage tuning: the overhead figures are attractive and the problem is well-motivated. However, the paper currently provides no processable experimental methodology, no stable set of headline numbers, and no generalization evidence. The strength of the claims is therefore not matched by the evidence presented, and the contribution cannot be assessed as it stands. I credit the authors for identifying a real problem and for the clear high-level architecture, but a systems paper requires reproducible measurements, which are absent here.","major_comments":[{"comment":"The reported performance gains are internally inconsistent. The Abstract states throughput gains up to 2.6x and latency reductions of 43%; Section IV.A reports an average 1.4x to 2.3x throughput improvement with a maximum of 2.3x for mixed workloads on SATA SSDs; the Conclusion reports throughput improvements up to 3x and latency reductions up to 50%. At most one of these sets can be correct, and no table or explanation reconciles the spread. This inconsistency makes the central claim, that RL-Storage achieves a specific quantitative improvement, undefined.","section":"Abstract vs. Section IV.A vs. Section V"},{"comment":"The experimental evaluation is not described in sufficient detail to be reproduced or checked. There is no hardware model list, no definition of the baseline heuristics, no number of trials per configuration, no confidence intervals or standard deviations, no statement of how training and evaluation workloads were separated, and no artifact or code. The section also does not specify how the RL agent was trained, what hyperparameters were used (beyond a vague 3-layer to 5-layer network sweep), or how the reported overhead of 0.11% CPU and 5 KB memory was measured. Without these details, the performance claims cannot be verified.","section":"Section III, unnumbered 'sectionExperimental Setup and Results'"},{"comment":"The performance model equations are not coherent and are not connected to any measured data. Equation (4) defines P_total as a weighted sum of workload/config terms plus a queue-depth term, but the variables are not defined operationally. Equation (5) defines utilization efficiency U_eff as P_total divided by the sum of disk operations D_k, yet the text says utilization efficiency scales proportionally with load, which is not what the formula states and no derivation is given. Equation (7) introduces an unexplained scaling factor beta. Since none of these equations are used in the analysis, they do not support the experimental claims and instead suggest an unfinished formalism.","section":"Equations (4), (5), and (7)"},{"comment":"The paper assumes that the features collected by the Data Collector—request sizes, access frequencies, and latency patterns—are sufficient for the DQN to learn a configuration policy that generalizes to unseen workloads, but no evidence for this is provided. The reported ablation (29% throughput drop when Feedback Loop and Data Collector are disabled) is given without standard deviations or workload breakdowns, and it is not connected to any held-out evaluation. Since the RL agent is trained and evaluated on the same kind of workload, the results cannot support the claimed generalization to production workloads.","section":"Section III, Data Collector and Section IV.B"},{"comment":"The description of the experiments says each benchmark executed 10,000 operations, but no rationale is given for this small count, no trace characteristics are described, and no per-workload results are reported. The claim that 'It summarizes the performance improvement achieved by RL-Storage' refers to a figure or table that is not present in the manuscript. Consequently, the reader cannot determine whether the reported gains are statistically meaningful or even what exactly was measured.","section":"Section III.A and Section IV"}],"minor_comments":[{"comment":"Several cited references appear unrelated to the paper's content: [7] is about extrinsic parameter estimation on unmanned surface vehicles, [14] is about advertising recommendation systems, and [22] is about collision-free motion planning for robot navigation. These citations do not support the storage-system claims and should either be removed or replaced with relevant literature.","section":"References [7], [14], [22]"},{"comment":"The text contains formatting and typesetting artifacts, including the unnumbered heading 'sectionExperimental Setup and Results', the trailing '[1]' in 'readahead settings[1]', the incomplete 'The architecture of RL-Storage includes the data collection, inference, and feedback loop are illustrated' sentence, and the dangling '[ ?]' in the Conclusion. These need to be corrected before any resubmission.","section":"Throughout"},{"comment":"Equation (1), f(I)=sum w_i x_i, is introduced as a 'mathematical representation of storage optimization' but is never used or defined in terms of measurable storage parameters. Either define it precisely or remove it to avoid confusion.","section":"Section I, Eq. (1)"}],"recommendation":"reject","confidential_remarks":"This manuscript appears to be an incomplete draft rather than a finished research paper. The experimental section is an unnumbered insert, the headline numbers conflict across the abstract, results, and conclusion, and no reproducible methodology is given. There are also signs of careless reference handling, with several citations pointing to unrelated arXiv papers. Even under a broad interpretation of the journal's scope, the absence of a stable factual basis for the central claim is a load-bearing flaw that cannot be fixed by local revisions. I would not recommend resubmission of this version; if the authors have real experimental data, they would need to rewrite the paper from the evaluation section up."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The short version: the core claim—that RL-Storage gives up to 2.6x throughput and 43% latency gains—is not supported by anything in the manuscript. The abstract says 2.6x/43%, Section IV.A says 1.4x to 2.3x, and the conclusion says 3x/50%. Those cannot all be right, and no table or appendix maps any of them to a workload, device, or run. That alone makes the paper unverifiable as a scientific contribution.\n\nWhat the paper does well is modest but real: it names a genuine problem (static storage heuristics fail under dynamic workloads) and gives a clean high-level architecture: a data collector, a DQN inference engine, and a feedback loop. If someone wanted to build an RL storage tuner, this sketch is a reasonable starting point. The related work section also correctly cites prior RL work on storage tiering, caching, and disk scheduling, which is honest but cuts against the novelty claim—the paper adds no new algorithm or analysis beyond combining known pieces.\n\nThe soft spots are not minor. The experimental section appears as literal placeholder text (“sectionExperimental Setup and Results”), with no hardware models, no baseline definitions, no trial counts, no confidence intervals, and no artifact. The equations (4), (5), and (7) are not derived and some terms are unexplained. The ablation study reports a “29% drop” and “5% accuracy” without showing any data. The production case study says a video service improved by 34% and 20% with no measurement details. The reference list is padded with unrelated arXiv preprints (autonomous surface vehicles, advertising recommendation, robot motion planning), which further weakens confidence in the citation care.\n\nOn the plus side, the paper does not invent entities or cite purely fake prior work; the references look real, even if some are irrelevant. But the internal contradictions and missing methods are load-bearing, not cosmetic. This is not a case where a sympathetic reader can fill in gaps—the main result is literally undefined.\n\nWho is this for? Possibly someone who wants a one-page survey of what an RL-based storage tuner might look like, but not a reader looking for validated results. It does not deserve peer review in its current state. My recommendation: desk reject, with an invitation to resubmit if the authors provide a real experiments section, consistent numbers, and a reproducibility artifact. As it stands, serious referee time would be wasted.","headline":"This paper reports internally inconsistent headline numbers and provides no reproducible experimental evidence; it should be desk-rejected, not sent to peer review.","tokens_in":6050,"tokens_out":1601,"would_cite":false,"duration_ms":17235,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"RL-Storage embeds a deep Q-network in the storage stack and reports up to 2.6x throughput gains and 43% latency cuts by tuning cache size, queue depths, and readahead in real time.","keywords":["reinforcement learning","deep Q-learning","storage optimization","cache size tuning","queue depth","readahead","I/O workload adaptation","kernel-level storage"],"falsifier":"Train RL-Storage on random and mixed workloads, then run it on a metadata-heavy or purely sequential trace whose optimal configuration is measured offline; if the agent's chosen settings stay far from that optimum and throughput equals or falls below the best fixed heuristic, the feature set or the learning loop is insufficient.","tokens_in":1374,"feed_emoji":"⚙️","tokens_out":3580,"duration_ms":65368,"temperature":0.7,"pith_summary":"This paper tries to establish that a reinforcement learning agent embedded in the storage stack can replace static heuristics by continuously reconfiguring cache size, queue depths, and readahead settings as workload patterns shift. The agent runs a deep Q-network on features extracted from live I/O requests, specifically request sizes, access frequencies, and latency patterns, and updates itself through a feedback loop. The claimed payoff is concrete: throughput gains up to 2.6x and latency reductions of 43% over baseline heuristics on benchmarks like RocksDB and PostgreSQL, with CPU overhead of 0.11% and a memory footprint of 5 KB. If correct, this makes automated, real-time storage tuning practical in production environments.","feed_headline":"RL tunes storage caches and queues on the fly","feed_subtitle":"Agent learns live I/O patterns; up to 2.6x throughput, 43% lower latency, 0.11% CPU overhead.","key_machinery":"The load-bearing object is the deep Q-network (DQN), a neural network that estimates the expected future reward of each configuration action, running inside the storage kernel. A Data Collector feeds it request sizes, access frequencies, and latency patterns, and the network outputs actions that set cache size, queue depths, and readahead values. Training follows the standard Q-learning update $Q(s,a) \\leftarrow Q(s,a) + \\alpha[r + \\gamma \\max_{a'} Q(s',a') - Q(s,a)]$, and the Feedback Loop closes the cycle by passing observed performance back as reward, which is what lets the policy adapt without human tuning.","core_discovery":"RL-Storage's central claim is that a deep Q-network can learn a mapping from observed I/O behavior to near-optimal storage configurations, and that this mapping can be applied inside the kernel with negligible cost. The paper reports that the learned policy, updated continuously by a feedback loop, outperforms fixed heuristic tuning across NVMe and SATA SSDs, with the largest gains on mixed and random workloads where static settings are most wrong. The measured results are throughput improvements of 1.4x to 2.3x on average and up to 2.6x, latency reductions of 43% (the conclusion states up to 50%), and a 29% throughput drop when the feedback loop is disabled in the ablation study.","pith_inferences":["The paper's feature set—request sizes, access frequencies, and latencies—is plausibly sufficient for the three tuned parameters, but the paper gives no direct evidence of transfer to unseen workload classes; a fair next experiment would test the trained agent on a held-out production trace.","If RL-Storage generalizes, the same Q-learning loop could plausibly tune other kernel parameters such as I/O scheduler weights, interrupt coalescing, or NUMA balancing, because the machinery is agnostic to what the actions mean.","The reported 5 KB memory footprint suggests the trained network is very small; extending the action space to more parameters or finer-grained adjustments may push memory and inference time up, and that trade-off is not measured.","The abstract reports up to 2.6x throughput and 43% latency reduction while the conclusion reports up to 3x and 50%, so a reader should treat a range rather than a single figure as the claimed improvement."],"forward_implications":["If the central claim is right, storage systems can self-tune continuously instead of requiring manual configuration by administrators.","Static heuristics for cache and queue sizing become unnecessary for the workloads tested, because the RL agent tracks the optimal settings in real time.","The tiny memory and CPU footprint means the same agent could run per device without crowding out application workloads.","The adaptive behavior should deliver the largest wins on mixed and random workloads, where no fixed setting is best, and only modest wins on sequential workloads, matching the paper's reported pattern.","The ablation result implies that the closed-loop feedback is the source of adaptation: without it, throughput drops by 29%."],"supporting_citations":[{"why":"Supplies the premise that reinforcement learning can manage storage tiering, the approach RL-Storage extends.","marker":"[1]"},{"why":"Provides learning-based cache replacement as a related baseline and source of cache-tuning methods.","marker":"[3]"},{"why":"Shows RL applied to disk scheduling, supporting the idea that RL fits storage control.","marker":"[6]"},{"why":"Offers reward-driven cache management, a direct baseline for cache-size decisions.","marker":"[9]"},{"why":"Demonstrates deep RL for storage efficiency, the method family RL-Storage builds on.","marker":"[12]"},{"why":"Applies RL to storage queue management, relevant to the queue-depth action.","marker":"[16]"},{"why":"Gives an intelligent tiering system that RL-Storage positions itself against.","marker":"[23]"}],"fun_headline_variants":["Deep Q-learning tunes storage caches in real time","RL agent adjusts storage settings on the fly","Reinforcement learning slashes storage latency by 43%","Storage tuned by AI: up to 2.6x throughput","Kernel-level RL optimizes storage for mixed workloads"],"cache_read_input_tokens":8192,"weakest_assumption_plain":"The load-bearing premise is that request sizes, access frequencies, and latency patterns capture enough of a workload's character for the learned policy to keep working on workloads the agent has never seen.","fun_headline_variants_meta":{"raw":{"variants":["Deep Q-learning tunes storage caches in real time","RL agent adjusts storage settings on the fly","Reinforcement learning slashes storage latency by 43%","Storage tuned by AI: up to 2.6x throughput","Kernel-level RL optimizes storage for mixed workloads"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00016,"raw_usage":{"total_tokens":1180,"prompt_tokens":840,"completion_tokens":340,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":456,"completion_tokens_details":{"reasoning_tokens":261}},"tokens_in":456,"tokens_out":340,"duration_ms":3495,"temperature":1.0,"reasoning_tokens":261,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T23:17:53.371209+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Train RL-Storage on random and mixed workloads, then run it on a metadata-heavy or purely sequential trace whose optimal configuration is measured offline; if the agent's chosen settings stay far from that optimum and throughput equals or falls below the best fixed heuristic, the feature set or the learning loop is insufficient.","supporting_citations":[{"cited_title":"Chen and R","cited_arxiv_id":null,"evidence_quote":"Supplies the premise that reinforcement learning can manage storage tiering, the approach RL-Storage extends."},{"cited_title":"Wang and H","cited_arxiv_id":null,"evidence_quote":"Provides learning-based cache replacement as a related baseline and source of cache-tuning methods."},{"cited_title":"Smith et al., ”LearnSched: Reinforcement Learning for Disk Schedul- ing,” IEEE Trans","cited_arxiv_id":null,"evidence_quote":"Shows RL applied to disk scheduling, supporting the idea that RL fits storage control."},{"cited_title":"Liu et al., ”Reward-Driven Cache Management with Reinforcement Learning,” VLDB, vol","cited_arxiv_id":null,"evidence_quote":"Offers reward-driven cache management, a direct baseline for cache-size decisions."},{"cited_title":"Xu and L","cited_arxiv_id":null,"evidence_quote":"Demonstrates deep RL for storage efficiency, the method family RL-Storage builds on."},{"cited_title":"Wright et al., ”QueueSched: Reinforcement Learning for Storage Queue Management,” USENIX ATC, pp","cited_arxiv_id":null,"evidence_quote":"Applies RL to storage queue management, relevant to the queue-depth action."},{"cited_title":"Peters et al., ”MLTier: Intelligent Tiering for Hybrid Storage Systems,” IEEE Trans","cited_arxiv_id":null,"evidence_quote":"Gives an intelligent tiering system that RL-Storage positions itself against."}],"review_version":1}