<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Dear Suho, </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
First off, congratulations on your paper's acceptance to HotStorage. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Yes, we expect one or more authors to travel to the workshop and present their work orally. The final program (schedule of the workshop) is to be determined, and we will later share more details on the length of the presentation. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you, and we look forward to learning more about your work at the workshop. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-Bryan S. Kim</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Hotstorage-chairs <hotstorage-chairs-bounces@fsl.cs.sunysb.edu> on behalf of 손수호 via Hotstorage-chairs <hotstorage-chairs@fsl.cs.sunysb.edu><br>
<b>Sent:</b> Friday, July 31, 2026 22:08<br>
<b>To:</b> chairs26@hotstorage.org <chairs26@hotstorage.org><br>
<b>Cc:</b> Suho Son <suho.son@samsung.com>; Kiyoung Ki <kiyoung77.lee@samsung.com>; Jinheon Kim <jinheon09.kim@samsung.com><br>
<b>Subject:</b> Re: [Hotstorage-chairs] [HotStorage 2026] Accepted submission #50 "<a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,g_q8PuaWINQq__NuSLe4sIoD7zr0HIAgYulbRa2CT52Guh-fdeKZ0IO4dTFmf65l88pP-K-zgpcCJ0DjjDr4pMWfFD_kBeqLhpfOpQIWzxwusWVqYUvtkZKxj14,&typo=1&ancr_add=1">io.stream</a>: cgroup-Granular FDP for..."</font>
<div> </div>
</div>
<div>
<div dir="auto">Dear HotStorage 2026 Program Chairs,<br>
<br>
Thank you for the constructive reviews for our submission, #50. We will address the feedback in our camera-ready version by the August 12 deadline.<br>
<br>
Regarding the presentation format, our company policy only funds travel for oral presentations. Could you please confirm if our accepted paper will be presented as an oral presentation?<br>
<br>
Thank you for your time and assistance.<br>
<br>
Best regards,<br>
<br>
Suho Son
<div><br>
</div>
<div class="x_gmail_quote x_gmail_quote_container">
<div dir="ltr" class="x_gmail_attr">2026년 7월 25일 (토) 오전 11:58, HotStorage 2026 HotCRP <<a href="mailto:noreply-hotstorage26@hotcrp.com">noreply-hotstorage26@hotcrp.com</a>>님이 작성:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
Dear authors,<br>
<br>
The program committee for the 2026 ACM Workshop on Hot Topics in Storage <br>
and File Systems (HotStorage 2026) is delighted to inform you that your <br>
submission #50 has been accepted to appear in the workshop.<br>
<br>
* Title: <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,FN2vL2tXxHzeMmPcieUVsaNzqb79gCx_-D_4fJuj7nEmFi-MKXazEmwZD6u5fBNMiFDjc4zeKgcQuAGEWK8Y1rwgfs0oFxRXXP6ha-Yi6JyN&typo=1&ancr_add=1">
io.stream</a>: cgroup-Granular FDP for Unmodified Workloads<br>
* Site: <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fhotstorage26.hotcrp.com%2fpaper%2f50&c=E,1,4svyARJML6j04ECFS_llBKnHJ0npz74EURBaqG-7EnbszwLrK5p5Mpi8I3tY8cgdFBC0VakxT4N6ciz4aDEmq3iqV9bGLlv_Ory9O-gUh_asXOYWhrQnUlJC&typo=1" rel="noreferrer noreferrer" target="_blank">
https://hotstorage26.hotcrp.com/paper/50</a><br>
<br>
23 of 78 submissions were accepted. Congratulations!<br>
<br>
The camera-ready version is due August 12, 2026 (Wednesday); this is a <br>
hard deadline. The page limit for the camera-ready version is 6 pages, <br>
excluding the references. Please improve your draft by addressing the <br>
concerns mentioned in the reviews.<br>
<br>
Please visit the HotStorage'26 HotCRP site for reviews, comments, and <br>
related information. Reviews and comments are also included below.<br>
<br>
Contact PC chairs <<a href="mailto:chairs26@hotstorage.org" target="_blank" rel="noreferrer">chairs26@hotstorage.org</a>> with any questions or
<br>
concerns.<br>
<br>
Sincerely,<br>
Young-ri Choi and Bryan S. Kim<br>
HotStorage 2026 Program Co-Chairs<br>
<br>
Review #50A<br>
===========================================================================<br>
<br>
Overall merit<br>
-------------<br>
3. Weak accept<br>
<br>
Reviewer expertise<br>
------------------<br>
3. Knowledgeable<br>
<br>
Paper summary<br>
-------------<br>
The paper proposes assigning data placement hints via a new cgroup control knob, <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,ah1Mhx88DF3KqTrzoM0hqvOQFYYEZXqGPA9P-a8922oyvNgE-t7eXTSIOciJ6lfpeju6wdRNMdAfDzrkH_T6Zxge8a10Ik8d1WywX8amulf1SUaC3_1ybo3Z&typo=1&ancr_add=1">
io.stream</a>, enabling per-device stream allocation for tenants or workloads. This approach improves NAND flash storage efficiency by reducing write amplification and performance interference. The mechanism is transparent and operator-friendly, although the
paper notes that the ideal party to set these hints remains an open question.<br>
<br>
Comments for authors<br>
--------------------<br>
Thank you for submitting your work to HotStorage ’26.<br>
<br>
Strengths<br>
<br>
1. Writing. The paper is clearly written and easy to follow. The motivation and implementation are described in enough detail to support reproducibility.<br>
2. Rationale and design of <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,0qL6M1dzHoYDnfv5z8jB2GqpduNW8VIf1BGjUSuRkc6nksurbTbth-rBo0iqKtX8agJvkwyQrNhTTBc7bloGEzlfYplxZs2sORm1LkuyMKauMCJfpb_s&typo=1&ancr_add=1">
io.stream</a> The design is elegant and focused. <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,aTrkzCj_VGdUbeJcK9HrS-PU50YWeCjLsw6ZmWxqRRFRH5IUcEkeX-xzRLPcuzx2eRCdlbwKcBSZKuG-COUT3YHyXgjUzT3xVMBXZT0c&typo=1&ancr_add=1">
io.stream</a> performs a single task and only requires configuration from operators.<br>
3. Potential impact. <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,mK_D-x-n_y08NWH7C9aFTnFtSXFNFuEDwYhJRfQj7owrZcTIHxtUXfvmqoooq8E1U5oSPeISwwum0OKIsopM8Bskv1Avw_0d6MFWm5Fv&typo=1&ancr_add=1">
io.stream</a> can reduce write amplification transparently with little overhead. The evaluation shows substantial improvements without requiring application changes.<br>
<br>
Weaknesses<br>
<br>
1. Evaluation soundness. The evaluation relies on synthetic workloads and lacks important experimental details. It is difficult to judge how well the results translate to practice. The paper does not describe the FDP SSD characteristics, preconditioning, or
GC behavior. It is therefore unclear whether the results are stable or influenced by garbage collection peaks. Standard deviations, runtime measurements, and workload parameters, such as the number of keys used in fillrandom, are also missing.<br>
2. Limited discussion of usefulness and use cases. The paper argues that operators should configure streams but provides little justification. It is unclear who deploys FDP SSDs, whether they are commonly used in multi-workload environments, and when operators
should configure hints. These questions are largely deferred to future work.<br>
3. Limited discussion of trade-offs. The paper advocates using cgroups but does not discuss when they may be unsuitable. Alternative approaches, such as implementing hints in the file system or applications, are mentioned but not evaluated. A comparison with
these alternatives would better demonstrate the value of <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,dVaA4eGifsC2yrdgvU6wVhzYbyWLVviX9RWfABfKX9J_tmYSrFfBfvvmvRbR-UBdISIkXXz8LnD4v-UAlM9bUDg-PmByLT9jerKyoWvK-iUNJ_bE_tkc&typo=1&ancr_add=1">
io.stream</a><br>
<br>
Suggestions for improvement<br>
<br>
1. Expand the evaluation. Include more details about the FDP SSD, even if anonymized. Report results on conventional NVMe SSDs, standard deviations, preconditioning, GC behavior, and workload parameters.<br>
2. Use more realistic benchmarks. Consider YCSB with RocksDB instead of only db_bench. Benchmarks representing multi-tenant environments would better demonstrate practical relevance.<br>
3. Evaluate alternative approaches. Expand the discussion and, if possible, compare
<a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,EAeEFUxRD3QGcspS-DX_icR3HxFQl6F1ujc0kCx6nDNO3EVFRVHcZTtoikAbNzJGPbP54BvHab53udPpeG7X8OCHc0NCee6IiyF3IYDgFS6bcNSdQK6DznhZAjCE&typo=1&ancr_add=1">
io.stream</a> with application-level or file system based hinting mechanisms.<br>
<br>
Conclusion<br>
<br>
Overall, the paper explains <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,FjWjAKWsHDQ3-xT-UySG_cIMmkv-8xmb1t-601GOr_3ckf85MVebMBsPbLkI75479WGT0s2CGzaK_qQYECSGy2MoOHE1ldyIpu9hfqc_r6TZs-cd&typo=1&ancr_add=1">
io.stream</a> clearly. The question of who should assign FDP write streams is interesting.<br>
<br>
The paper would be stronger with a broader evaluation on both synthetic and realistic workloads. It would also benefit from a deeper discussion of when operators should configure streams and how
<a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,LhuK_ZzGb4Uex0Wch9jXVXIx7hdkH7xgxDYybHt2T-5E9sITIvuf5zrIBD3YFIt88SCY6PJsrh05JxDgEVZWgqUOxjAkUWXeJobJOUL-RD1SXtCV0Obf1cOS3Hk,&typo=1&ancr_add=1">
io.stream</a> compares with alternative approaches.<br>
<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *<br>
<br>
<br>
Review #50B<br>
===========================================================================<br>
<br>
Overall merit<br>
-------------<br>
4. Accept<br>
<br>
Reviewer expertise<br>
------------------<br>
3. Knowledgeable<br>
<br>
Paper summary<br>
-------------<br>
The paper proposes that FDP placement streams should be added to control groups to isolate tenants without application modification. The proposed mechanism defaults to conventional placement across the device, and lets application-defined placement take precedence.
It is implemented in the Linux kernel. The evaluation illustrates the potential pitfall of the approach: in case the number of streams defined in cgroups is larger than the number of FDP placement units, there is a risk that tenants with very different writing
patterns are placed together -- the experiment shows that this results in worse performance than a conventional SSD.<br>
<br>
Comments for authors<br>
--------------------<br>
Thanks for submitting this paper to HotStorage.<br>
The idea of using cgroups for tenants isolation with FDP is obvious in retrospect. The paper does a very good job at explaining the precedence issues and the fallback mechanism, which is not obvious. The experiment shows that the fallback works as intended.<br>
Some issues:<br>
1. The paper repeatedly mentions "operators", but they are not defined. <br>
2. The paper does not explain how an "operator" can take decisions about lifetime for a tenant and about lifetime coherence across tenants. This question is crucial for performance but it is not addressed in the paper.<br>
3. The experimental framework is not clear. Which SSD model did you use for your experiments?<br>
Stage1-3 are referenced in 5/Setup without being defined. This is confusing.<br>
<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *<br>
<br>
<br>
Review #50C<br>
===========================================================================<br>
<br>
Overall merit<br>
-------------<br>
4. Accept<br>
<br>
Reviewer expertise<br>
------------------<br>
3. Knowledgeable<br>
<br>
Paper summary<br>
-------------<br>
This work proposes <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,DvhEpPJvGK7sYLyOXEk3NqkdLai2bukYlBHR-_lr7DgaO32PyBXiQ6TzMF6FLdpcvWenEtNGqvjkjguYyGRSMlAqqJv3KQzn7mabJzdgxJuP4l9ApOyx&typo=1&ancr_add=1">
io.stream</a>, a cgroup-v2 interface for assigning NVMe Flexible Data Placement (FDP) streams at cgroup granularity. The key idea is to enable an operator to assign a placement stream to a cgroup, so that the kernel can direct otherwise unplaced block I/Os
from that cgroup to the corresponding FDP placement identifier, including both buffered and file-system writeback paths. Doing so makes FDP usable for unmodified workloads without requiring application-level per-I/O stream tagging. The proposal is easy to
implement, requiring roughly 300 lines of code on Linux, and the evaluation shows that
<a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,a3kkDZ15dKgO8gEJpPtCdCeL6zRE0OKkxT977F-VbOQDtSRKoZyShW7Vm-mPldZmFiNBdSjVD4mMtDdOLwqAcgYvcLszETnd0ca7V2Vv&typo=1&ancr_add=1">
io.stream</a> can substantially reduce WAF when cgroups are mapped to streams in a lifetime-aware manner.<br>
<br>
Comments for authors<br>
--------------------<br>
## Strengths<br>
+ The work addresses an important and timely problem.<br>
+ The proposed cgroup-based interface is simple, practical, and well aligned with how multi-tenant workloads are deployed and managed.<br>
+ The implementation appears lightweight and minimally invasive.<br>
+ The evaluation is fairly comprehensive for a workshop paper.<br>
<br>
## Weaknesses<br>
- The motivation and positioning sometimes overstate the limitation of current FDP support.<br>
- The assumption that cgroups capture data lifetime is reasonable in some deployment settings, but should be stated more carefully.<br>
<br>
## Detailed Comments<br>
Thank you for submitting the work to HotStorage 2026. I found the work interesting and practically motivated. FDP is an important direction for reducing write amplification, but its practical benefit depends on whether placement hints can be provided properly.
The proposal is a simple and compelling step toward making FDP usable for unmodified workloads, especially in multi-tenant or containerized environments where cgroups already represent an operator-visible unit of deployment and control.<br>
My main concern is not with the proposal itself, but with how the current manuscript positions the limitation of existing FDP support and how clearly it separates the mechanism from the remaining policy problem.<br>
<br>
### Positioning Should Be More Carefully Stated<br>
The manuscript motivates <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,cZ9AfJTwrE4u_VMA1hGlNwkxx2pVAzbk4zgqMA9XxRmwLUlmQVPLy9Uxb_dtF6K583_IAGr0_zU4A9ja37BCGLsHTBXHulhVsAjgf0Z-UHpGV_uhm-Z2R_jo&typo=1&ancr_add=1">
io.stream</a> by arguing that current Linux FDP support mainly reaches rewritten direct-I/O applications that explicitly provide per-I/O stream hints. This is valid, but the manuscript sometimes reads as if FDP adoption faces a more fundamental limitation,
which I think should be toned down. The limitation appears to be due to the current Linux interface and ecosystem support, rather than a fundamental limitation of FDP itself. As Linux evolves, appropriate kernel, VFS, writeback, or file-system extensions could
also improve FDP applicability. In this sense, <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,NMDfVD19glIu9XWMWjxMJfJhY-6HMLT5S1PtK5qbFpyVhUmwyA2RoEj8WSXqyVwuNCW27bJDRvyyslNZn_w1ZHe-ZR1oEddJpA8fDy9TPdNsRz8,&typo=1&ancr_add=1">
io.stream</a> should be positioned as a practical and minimally invasive first step toward broader FDP adoption, not necessarily as the only or definitive way to make FDP useful for unmodified workloads. This distinction matters because the contribution is
already strong without overstating the problem. The manuscript can simply say that current upstream support lacks an operator-controlled, application-transparent producer of FDP placement hints for buffered and writeback I/O, and that
<a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,XQF6SmbUp-17rufBUOTA4wkxT7DltaVARlXhvaliKyzAnsqbCPa7QWj4IjjsruDn_1olemYzbigstWvt7DhX9chatiEW7QcgFjTWRg0mI1EVpWll9PEXL6k,&typo=1&ancr_add=1">
io.stream</a> fills this gap by reusing cgroup attribution already available in the block layer.<br>
<br>
### Clarify the Scope of Cgroup-Level Placement<br>
Using cgroups as the placement granularity is a reasonable and deployable choice, but cgroups primarily capture ownership, deployment, and resource-control boundaries; they do not always capture data lifetime. A single application cgroup may contain data with
very different lifetimes, such as WAL files, SSTables, indexes, temporary files, and metadata. The manuscript acknowledges this in the discussion by contrasting macro-level cgroup placement with micro-level per-I/O tagging, but I think this point should be
emphasized more carefully. In my view, <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,3rM03cOSl2zcs2JJYrCYuW8UgDO8r8OhHUBvZGRFXGO3SABor9R-zRhfQq3lSGYStfVo17HYZk3zdCV2vV9X-6_L_soBmWmE-OqXjVbQtsg20htXghKwIWO9&typo=1&ancr_add=1">
io.stream</a> is best positioned as complementary to other FDP mechanisms. Per-I/O tagging can express fine-grained lifetime information within an application, while cgroup-level tagging can provide operator-controlled placement across tenants or services.
This complementary framing is strong and avoids implying that cgroups are always the right abstraction for data lifetime.<br>
<br>
<br>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *<br>
<br>
<br>
Review #50D<br>
===========================================================================<br>
<br>
Overall merit<br>
-------------<br>
4. Accept<br>
<br>
Reviewer expertise<br>
------------------<br>
2. Some familiarity<br>
<br>
Paper summary<br>
-------------<br>
FDP devices allow users to specify placement hints to reduce write amplification. However, it requires application cooperation: direct I/O using io_uring, kernel write back and mmap cannot leverage the feature. This paper observes that production deployments
use cgroup, which carries tenant id that can be used as a hint. The paper proposes
<a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,yG5n26gen9QmWfN9qr3Ssmtw9EVLrBYbWSh_2bTyJzY2T-YLRgXC49qWl1M9MMIfcO52L-CaGak8nJdsNFcVCe347-PQK3tqFsuIZ5l9W-gU&typo=1&ancr_add=1">
io.stream</a> and demonstrates that <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,0GcEhxLa5u-cutGwnsTcuBlF0RhBTrht4TTvp2o6OhZ04fCU3StuSp-zwD9Wf2KymIuRjPGLRELyeetvz6WUuibg0-tY5TExhMylyBfCcUbAYis,&typo=1&ancr_add=1">
io.stream</a> passes cgroups tenant information that can better utilize FDP and reduce write amplification.<br>
<br>
Comments for authors<br>
--------------------<br>
Thank you for submitting to hotStorage! I enjoy reading this paper. Leveraging cgroups as a hint is an interesting and effective idea. I like the new design and the results shown by the authors. While this paper provides a mechanism, one key algorithm design
for future work is to map logical IDs to physical ones on SSD. The authors show that it is effective in an offline setting, but how to achieve it online remains a challenging task.<br>
<br>
Comment @A1 by Reviewer A<br>
---------------------------------------------------------------------------<br>
Congratulations on the acceptance of your paper.<br>
<br>
The reviewers agreed that <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fio.stream&c=E,1,tGHOqeEHmOtEoRCigyXQQCyBidhk2JE5ndPMbcuxgMZQ1meN3KHbwCFSah2gbCDZjdLnxKBcLLgBKWJodD6Z-5eI5Dkm2tUt3W12IaRMotyWSZnD9Fq7&typo=1&ancr_add=1">
io.stream</a> offers a simple and practical cgroup-based mechanism for FDP placement in unmodified, multi-tenant workloads.<br>
<br>
The main concerns were the limited evaluation, unclear experimental details, and the unresolved challenge of mapping diverse data lifetimes onto a limited number of streams. Reviewers also noted that cgroups may not always reflect data lifetimes and there may
be a need to complement them with file-system or per-I/O approaches.<br>
<br>
The paper was recognized as a good fit for HotStorage, and we are excited for the engaging discussions it will inspire.<br>
<br>
</blockquote>
</div>
</div>
</div>
</body>
</html>