[Hotstorage-chairs] [HotStorage 2026] Rejected, but invited as poster, submission #44 "Regular: SplitNav-Lite: Trading Compact..."

[HotStorage 2026 HotCRP]

Dear authors,

The program committee for the 2026 ACM Workshop on Hot Topics in Storage 
and File Systems (HotStorage 2026) regrets to inform you that your 
submission 44 was rejected to appear in the proceedings of the workshop.

However, your work incited exciting discussion among the program 
committee members, and we would like to invite you to present your work 
during the poster session. Please let us know by August 12, 2026 
(Wednesday) whether or not you accept or decline the poster invitation.

* Title: Regular: SplitNav-Lite: Trading Compact Navigation State for 
  SSD Bytes in Disk-Resident ANN Search
* Site: https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fhotstorage26.hotcrp.com%2fpaper%2f44&c=E,1,Zp4H7Qlq77CuCQ79miQj4CjdupAYwQsMN1N2lxetQP6Fh2fEN_9b4rhYoXbyI8vnwiAVrDr-KmjuK5-xvzT9eOg43LuOLFgd9CGypEfbRlcQfw,,&typo=1

23 of 78 submissions were accepted.

Visit the submission site for reviews, comments, and related 
information. Reviews and comments are also included below.

Contact chairs26 at hotstorage.org with any questions or concerns.

Sincerely,
Young-ri Choi and Bryan S. Kim
HotStorage 2026 Program Co-Chairs

Review #44A
===========================================================================

Overall merit
-------------
2. Weak reject

Reviewer expertise
------------------
3. Knowledgeable

Paper summary
-------------
The paper proposes SplitNav-Lite, a storage-system optimization for SSD-resident ANN search that separates graph navigation from full vector payload access. By keeping compact int8 navigation codes and adjacency in memory and fetching full vectors only during final reranking, SplitNav-Lite reduces SSD bytes per query by about 76% while maintaining or improving recall on several 100K-scale workloads.

Comments for authors
--------------------
The paper presents a new perspective on disk-based ANN systems by separating the search/navigation stage from the final ranking stage. The idea is interesting, but the proposed design appears relatively simple, and the scheme may have several issues as below.

First, the proposed scheme requires storing the full graph topology and low-resolution navigation vectors in memory. This introduces a non-trivial main-memory requirement and may limit the scalability of the approach for truly large-scale disk-based ANN workloads.

Second, using low-resolution vectors, such as int8 navigation vectors, may hurt recall accuracy. Since these compressed vectors are used during graph traversal, quantization error could lead the search along suboptimal paths and prevent it from reaching high-quality candidates.

Third, the evaluated datasets are relatively small and may not adequately represent realistic disk-based ANN scenarios. Also, the paper misses the comparison with important disk-based ANN baselines such as SPANN, OdinANN, Starling, and related systems.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #44B
===========================================================================

Overall merit
-------------
4. Accept

Reviewer expertise
------------------
3. Knowledgeable

Paper summary
-------------
SplitNav-Lite proposes a change to the DiskANN-like style architecture by decoupling  the graph navigation stage from full vector payloads in order to reduce I/O to disk.

Comments for authors
--------------------
The paper targets a relevant use-case: DiskANN-like approaches produce a lot of read amplification. I have a few comments:
 - The core idea of decoupling navigation and payload is intuitively valuable. For a full paper, I would like to see more real-world datasets and workloads. The question is if this approach is significantly better than the quantized / partial in-memory tables like DiskANN already does. My main question is if the reads we spare during navigation end up being issued at the end (which would imply that the vectors read during navigation are useful), or whether they are not issued at all (and therefore we have less reads overall).
- If we consider DRAM-constrained scenarios, would there be a benefit from issuing separate I/O for navigation and payload? Or is the benefit strictly bounded to the DRAM table?
- It would be good to explore more corner / boundary cases to see if there is any loss in accuracy
- The comparison with DiskANN's partial in-memory methods should be more robust in a full paper
- How well would this work at scale with billions of nodes?


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #44C
===========================================================================

Overall merit
-------------
3. Weak accept

Reviewer expertise
------------------
2. Some familiarity

Paper summary
-------------
The paper proposes, SplitNav-Lite, SSD-based ANN search method to reduce SSD bytes/query, which decouples graph adjacency and vector payloads and fetches full vectors from SSD in a lazy way.

Comments for authors
--------------------
Strengths:
1. This work improves SSD-based ANN search by decoupling graph adjacency and vector payloads.

Weaknesses:
1. Lack of clear and strong motivation.
2. Less sufficient evaluation.

The paper can be improved as below:
1. The paper needs to provide a more detailed and compelling motivation for using approximate nearest-neighbor (ANN) search, explicitly clarifying why ANNs remain useful and important in the current LLM era. Furthermore, the authors should justify the specific necessity of DiskANN-style graph search over other alternatives. 
2. The paper mentions in Intro Section that ‘the remaining bottleneck is no longer only the number of distance computations. It is also the shape of the bytes fetched from storage during graph navigation’. To support this claim, the paper should provide relevant citations and/or empirical motivational observations. In this way, readers and reviewers can clearly spot the exact problem that the paper aims to solve.
3. The paper conducts evaluation on RAG-like workloads with 100K base vectors and ANN-Benchmarks Fashion-MNIST Euclidean HDF5 workload with 60K base vectors. However, these workloads are less realistic workloads, thus, the paper needs to provide evaluation on more realistic workloads. Without this comparison, it is not clear that the proposed approach can achieves how much improvement on real workloads.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Review #44D
===========================================================================

Overall merit
-------------
2. Weak reject

Reviewer expertise
------------------
4. Expert

Paper summary
-------------
This paper tackles DiskANN inefficiency: on-disk records couple adjacency with full payloads, so every hop reads payload bytes which later will be discarded. This paper moves adjacency + int8 codes into RAM, navigates in memory, and fetches full vectors from SSD only for final rerank. This redesign is reported to have 75.8–76.3% fewer SSD bytes/query at equal or better recall.

Comments for authors
--------------------
The described mismatch between navigation and payload is generally reasonable. But I feel the issue is overclaimed. DiskANN already uses in-memory PQ codes for approximate navigation and reads full vectors mainly for reranking, so the real issue is just the block-utilization problem of being forced to read and discard a full payload when expanding a node. 
Thus, the contribution seems less novel than claimed: DiskANN++ targets the same I/O redundancy but is not compared and SPANN is only cited. I'd encourage the authors to tighten the framing to a block-utilization problem, compare explicitly against these works, and soften the "first-class navigation object" language accordingly.


Comment @A1 by Reviewer D
---------------------------------------------------------------------------
Thank you for submitting your work to HotStorage.

This paper has been discussed at length by the program committee. Reviewers agree that the paper addresses a practical problem in disk-resident ANN search and presents an intuitive approach to reducing unnecessary SSD traffic by decoupling graph navigation from full-vector access.

However, concerns remain about the novelty of the proposed design relative to DiskANN and related systems, as the distinction from prior approaches that reduce redundant I/O is not sufficiently established. We encourage the authors to strengthen the novelty positioning, add comparisons with the most relevant systems, and evaluate the design on larger-scale workloads in a future submission.