Pith. sign in

REVIEW 3 major objections 4 minor 55 references

ByteFS: System Support for (CXL-based) Memory-Semantic Solid-State Drives

T0 review · 3 major / 4 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A file system that uses byte- and block-granular writes to memory-semantic SSDs can outperform existing file systems by up to 2.7x while cutting write traffic by up to 5.1x.

desk verdict A credible first file system for memory-semantic SSDs with solid measurements and a real prototype, but the crash-consistency story rests on an unverified battery-backed DRAM assumption. read the letter →

arxiv 2501.04993 v1 pith:BHXGQ4ZK submitted 2025-01-09 cs.OS

Shaobo Li , Yirui Eric Zhou , Hao Ren , Jian Huang This is my paper · ORCID
classification cs.OS
keywords filesystemmemory-semanticSSDbyte-addressablestorageCXLlog-structuredfirmwarecrashconsistencyI/Oamplificationdatacoalescing
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

ByteFS aims to show that a file system built for memory-semantic SSDs (flash SSDs that expose a byte-addressable memory interface alongside the normal block interface) can avoid the write amplification that plagues block-only file systems. The paper argues that core metadata structures should be written at byte granularity through the memory interface, while data and page cache should switch between byte and block granularity based on how much of a page is dirty. To make byte writes efficient, ByteFS reworks SSD firmware to keep a log-structured DRAM buffer that coalesces cacheline updates into full flash pages, and it uses that log as a transaction redo log for crash consistency. On the paper's prototype and emulator, this design beats four existing file systems by up to 2.7x and cuts host-to-SSD write traffic by up to 5.1x. The practical payoff is that commodity flash could act as cost-effective byte-addressable persistent memory without sacrificing file-system guarantees.

What carries the argument

The central object is the dual byte/block file system plus a firmware-side log-structured DRAM buffer. The M-SSD exposes a byte-addressable memory region via PCIe MMIO (or CXL), so ByteFS can persist 64B cacheline updates without writing a full 4KB block; it chooses block I/O when a dirty page's modified ratio is at least one eighth. The firmware organizes the SSD's DRAM as a circular log indexed by a three-layer skip list (a partition table, per-page entries, and per-page chunk lists), appends byte writes at the tail, and runs background log cleaning when the log is 85% full to merge updates and flush full pages to flash. The same log is reused as a transaction redo log: ByteFS assigns a transaction ID, persists metadata updates into the log, commits with a custom NVMe command that appends to a TxLog, and the firmware flushes committed entries in commit order. This mechanism is what lets ByteFS preserve crash consistency and data recovery while removing the double-write cost of journaling.

What would settle it

Cut power to a ByteFS prototype after a transaction commit but before log cleaning, then boot and check whether committed data survives; if the DRAM is not battery-backed, the data will be lost. A simpler check is to inspect the OpenSSD board's DRAM power supply for a battery or supercapacitor.

Watch

Extended reading notes

Core claim

ByteFS claims that the right way to manage a memory-semantic SSD is to treat byte and block interfaces as complementary: use byte-granular writes for frequent small metadata updates and hot cachelines, and block-granular I/O for bulk data and reads. It supports this with a hardware/software co-design: the file system chooses granularity per data structure at runtime, while the SSD firmware stores byte-granular writes in a log-structured DRAM and later coalesces them into full flash pages. The firmware-level log also serves as a redo log, giving transaction commit a fast path and making recovery possible from the battery-backed SSD DRAM. Evaluated against Ext4, F2FS, NOVA, and PMFS on Filebench, YCSB/RocksDB, and OLTP-like workloads, ByteFS reports throughput improvements up to 2.7x and reductions in write traffic to the SSD up to 5.1x, with recovery in about 4.2 seconds.

Load-bearing premise

The crash-consistency and recovery guarantees assume the M-SSD's DRAM is battery-backed (power-loss-protected) so the firmware write log and transaction log survive power failure; the paper does not confirm the OpenSSD prototype's DRAM has such protection.

Editorial extensions

If this is right

  • If ByteFS's results hold, file systems for CXL-attached SSDs can be built by extending existing kernel file systems (here, Ext4) rather than designing new ones from scratch.
  • Byte-granular persistence of metadata can eliminate most metadata write amplification, so workloads dominated by file creation, directory operations, and small synchronous writes see the largest gains.
  • Reusing the device-side write log as a transaction redo log removes the need for separate on-flash journal double-writes, so crash consistency no longer costs a 2x write penalty.
  • Battery-backed DRAM in the SSD becomes a first-class component of the persistence contract; without it, the recovery mechanism as designed would not work.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next step the paper does not explore is applying the same adaptive granularity to database and key-value storage engines that sit above the file system; many of them issue small random updates that would fit the byte-interface path.
  • The one-eighth modified-ratio threshold is a fixed heuristic; one could make it self-tuning per workload or per device, since faster flash or slower CXL links would shift the crossover point.
  • The recovery design assumes the firmware can scan the entire log after boot; as DRAM logs grow to tens of gigabytes, recovery time and index memory will need scalable structures, an issue the paper's 256MB log does not stress.
  • The paper's sensitivity results suggest that larger device DRAM directly improves performance, which gives memory-semantic SSD vendors a concrete reason to add DRAM capacity.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes ByteFS, a kernel-level file system for memory-semantic SSDs that expose both byte- and block-addressable interfaces (e.g., via PCIe MMIO or CXL). ByteFS uses byte-granular persistent writes for metadata and small data updates, block-granular accesses for larger transfers, and a firmware-level log-structured DRAM management layer with a skip-list index and background log cleaning to coalesce small writes into flash-page-sized I/Os. It also introduces a transaction mechanism with an in-DRAM write log and TxLog to provide crash consistency. The authors implement ByteFS on an OpenSSD FPGA prototype and a FEMU-based emulator, and report throughput improvements of up to 2.7x (with a 6.0x improvement on file creation) and write-traffic reductions of up to 5.1x compared to Ext4, F2FS, NOVA, and PMFS, along with sensitivity studies.

Significance. If the design holds up, this is a significant contribution: it is one of the first file systems explicitly designed for memory-semantic SSDs, combining host-side filesystem changes with SSD firmware modifications. The dual-interface design, the log-structured DRAM buffer, and the coordinated host/device caching are plausible and well-motivated by the I/O amplification study in Section 3. The real FPGA prototype and the FEMU-based emulator, together with the artifact and detailed traffic breakdowns, are notable strengths that go beyond a purely simulation-based paper. However, the crash-consistency and data-recovery claims, which are part of the headline contribution, are not yet adequately validated.

major comments (3)
  1. [§4.2/§4.7/§4.9/§5.5] The persistence and recovery mechanism is not fully specified and appears internally inconsistent. Section 2.1 states that battery-backed DRAM is used to assist data persistency by flushing DRAM contents to flash during a power loss, and Section 4.2 repeats this. Yet the RECOVER() procedure in Section 4.7 scans the log region and TxLog directly in SSD DRAM, with no step to reload these structures from flash after power is restored. If the battery-backed DRAM flushes to flash, the log and TxLog are no longer in DRAM upon reboot; if the DRAM instead remains powered, that must be stated and demonstrated. The prototype description in Section 4.9 does not confirm that the OpenSSD board's 1GB DRAM is battery-backed or power-loss-protected. The Section 5.5 recovery test reports only 'power off the system' and recovery time, without indicating whether this was a true power cut, whether DRAM contents survived, or whether the recovered file system state was verified for correctness. The paper must clarify the power-loss model, align the recovery procedure with it, confirm the prototype's hardware support, and validate recovery under an actual power failure.
  2. [§4.3/§4.7] The durability semantics of the COMMIT(TxID) operation are unspecified. The host issues a custom NVMe command to commit a transaction, and the firmware appends a 4B entry to the TxLog in SSD DRAM. The paper does not state whether the firmware performs a flush or fence to make the TxLog entry power-loss-durable before acknowledging completion to the host. The write-verify read described in Section 4.2 applies to byte writes, not to the COMMIT command. A crash between the host observing transaction success and the TxLog entry becoming persistent would lose committed updates, undermining the crash-consistency guarantee. The paper should specify the completion semantics of COMMIT and how it is made durable.
  3. [§5.5] The recovery experiment does not validate the crash-consistency claim. It reports an average recovery time of 4.2s, with a breakdown of 0.9s to load SSD DRAM content and 2.7s to scan the log region and TxLog, but it does not describe how the system was powered off, whether the test was run on the FPGA prototype or the emulator, or whether the recovered file system was checked for correctness (e.g., by verifying that committed transactions are present and uncommitted ones are absent). A timing measurement alone is insufficient to establish that ByteFS preserves crash consistency and data recovery. The authors should add a correctness validation under a real power-cut scenario, including a comparison of the recovered state against the expected state.
minor comments (4)
  1. [Abstract/§5.2] The abstract's headline 'up to 2.7x' is inconsistent with the reported 6.0x improvement on file creation over Ext4 in Section 5.2 and Figure 6. Please clarify whether 2.7x is the maximum speedup over a specific baseline or an aggregate, and reconcile the numbers so the central performance claim is unambiguous.
  2. [§5.5] Please state explicitly whether the recovery test was performed on the real FPGA prototype or the emulator, and what exactly 'power off the system' means (e.g., removing AC power versus a normal shutdown/reboot).
  3. [§6/Fig. 12/App. A.6] There are several typos: 'proposs' in the related-work discussion of FlatFlash, 'perforamce' in the caption of Figure 12, and 'capcity' in the artifact appendix. These should be corrected.
  4. [§4.3/§5.1] The paper reports that the log index occupies 21MB of SSD DRAM on average for a 256MB log region. Please clarify whether this 21MB is included in the SSD DRAM budget described in Section 5.1 (1GB total, with 512MB for the mapping table and 16MB for the write buffer) and how the index size scales with log region size.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: ByteFS's headline performance and traffic claims are measured against external baselines, and the sole self-citation (FlatFlash) is motivational rather than load-bearing.

full rationale

ByteFS's central claims—up to 2.7x throughput and up to 5.1x write-traffic reduction—are derived from benchmark experiments (Filebench, YCSB) on a real OpenSSD FPGA prototype and an FEMU-based emulator, compared against Ext4, F2FS, NOVA, and PMFS. No parameter is fitted to a subset of the reported results and then presented as a prediction; the 512B direct-I/O threshold and the R<1/8 page-writeback threshold are stated design heuristics, not calibrated to make the evaluation come out favorably. The only self-citation is FlatFlash [10], co-authored by one of the ByteFS authors, which is used to motivate byte-addressable SSDs; that premise is also supported by independent prior work (2B-SSD [12], Samsung CXL SSD [40]) and is not the source of the paper's measured improvements. No uniqueness theorem or ansatz is imported from the authors' prior work. The paper's crash-consistency and recovery argument does depend on an external hardware premise—battery-backed SSD DRAM retaining or flushing the write log and TxLog—but that is a correctness and validation risk (the Section 4.9 prototype description does not confirm power-loss protection, and Section 5.5 does not say whether power was truly cut), not a circular derivation, because the premise is not an output of the paper's own construction and no equation defines the claimed result in terms of that premise. Overall, the derivation chain is self-contained against external benchmarks, so the circularity score is minimal, reflecting only the presence of a non-load-bearing self-citation.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical entities, particles, forces, or dimensions. Its freedom lies in hand-picked system parameters (interface thresholds, log size, cleaning threshold) and domain assumptions about the M-SSD hardware (byte-interface latency, battery-backed DRAM, PCIe ordering). These assumptions are load-bearing for the persistence and crash-consistency claims.

free parameters (5)
  • Direct I/O interface threshold = 512 bytes
    Writes no larger than 512B use the byte interface; larger writes use the block interface. This threshold is chosen by hand and is not swept in sensitivity analysis.
  • Buffered writeback modified-ratio threshold = 1/8 (512B of a 4KB page)
    If fewer than 1/8 of cachelines in a dirty page are modified, ByteFS uses byte-granular writeback; otherwise it uses block writeback. The threshold is a hand-chosen design parameter.
  • Log cleaning threshold = 85%
    Background cleaning starts when write log utilization exceeds 85%. This is a default configuration, not derived from analysis.
  • Write log region size = 256 MB
    The firmware write log is configured as a 256MB circular buffer; Section 5.6 shows larger sizes improve performance in some workloads.
  • Cacheline size for write log entries = 64 B
    Writes to the log are aligned to 64B entries, matching the cacheline; this is a hardware alignment choice.
assumptions (4)
  • domain assumption M-SSDs provide byte-granular persistent writes via PCIe MMIO with a 0.6 microsecond write latency and 4.8 microsecond read latency (Table 1).
    The design is built around these device characteristics, measured on the authors' FPGA prototype, not on a shipping CXL SSD.
  • domain assumption Battery-backed (power-loss-protected) DRAM in the SSD retains the write log and transaction log across power failure.
    Crash consistency and recovery in Section 4.7 rely on this. The prototype description does not confirm the OpenSSD board has such protection.
  • domain assumption Byte-granular MMIO writes followed by clflush/clwb and a write-verify read are durable.
    The persistence mechanism in Section 4.2 assumes PCIe ordering makes the zero-byte read complete prior writes.
  • standard math Flash chips only support page-granular access, creating a granularity mismatch that the log buffer must bridge.
    This is a standard hardware property cited from prior work [10, 12, 21].

how reviews work

0 comments
Cite this review

Pith. "Pith review of ByteFS: System Support for (CXL-based) Memory-Semantic Solid-State Drives." pith.science (2026). https://pith.science/paper/BHXGQ4ZK

@misc{pith2026250104993,
  author       = {Pith},
  title        = {Pith review of: ByteFS: System Support for (CXL-based) Memory-Semantic Solid-State Drives},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BHXGQ4ZK}},
  note         = {Machine review of arXiv:2501.04993}
}
abstract

Unlike non-volatile memory that resides on the processor memory bus, memory-semantic solid-state drives (SSDs) support both byte and block access granularity via PCIe or CXL interconnects. They provide scalable memory capacity using NAND flash at a much lower cost. In addition, they have different performance characteristics for their dual byte/block interface respectively, while offering essential memory semantics for upper-level software. Such a byte-accessible storage device provides new implications on the software system design. In this paper, we develop a new file system, named ByteFS, by rethinking the design primitives of file systems and SSD firmware to exploit the advantages of both byte and block-granular data accesses. ByteFS supports byte-granular data persistence to retain the persistence nature of SSDs. It extends the core data structure of file systems by enabling dual byte/block-granular data accesses. To facilitate the support for byte-granular writes, \pname{} manages the internal DRAM of SSD firmware in a log-structured manner and enables data coalescing to reduce the unnecessary I/O traffic to flash chips. ByteFS also enables coordinated data caching between the host page cache and SSD cache for best utilizing the precious memory resource. We implement ByteFS on both a real programmable SSD and an emulated memory-semantic SSD for sensitivity study. Compared to state-of-the-art file systems for non-volatile memory and conventional SSDs, ByteFS outperforms them by up to 2.7$\times$, while preserving the essential properties of a file system. ByteFS also reduces the write traffic to SSDs by up to 5.1$\times$ by alleviating unnecessary writes caused by both metadata and data updates in file systems.

Figures

Figures reproduced from arXiv: 2501.04993 by the authors.

Figure 1
Figure 1. Host-SSD I/O traffic breakdown of Ext4 and F2FS. 3.2 File Metadata Structures Superblock. Superblock maintains the key properties of a file system. As shown in [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. System overview of ByteFS. unclear how the file system should support both byte/block interfaces. ByteFS should provide the flexibility to exploit the benefits from both interfaces. (3) ByteFS should enforce data consistency with minimum overhead. (4) ByteFS should preserve the essential filesystem properties. 4.1 System Overview We present ByteFS, an efficient file system for M-SSDs with a co-design of software (ho… view at source ↗
Figure 3
Figure 3. Structure of the write log in the M-SSD firmware. the PCIe root complex. TheM-SSD controlleris responsible for handling memory requests. ByteFS leverages the BAR register to map the entire SSD as a memory region to the host. The host can concurrently access any SSD address with MMIO (byte in￾terface). ByteFS do not require cache-coherency between the SSD DRAM and the host CPU cache because the host always contains t… view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: Transaction support with the firmware-level log. We show the transaction mechanism of ByteFS in [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: The workflow of ByteFS operations. 4.7 Preserve Essential File System Properties ByteFS preserves the essential properties of most file systems, including crash consistency and data recovery. Crash Consistency. As discussed in §4.3, to ensure con￾sistency, ByteFS lever…
Figure 6
Figure 6. Figure 6: Overall throughput improvement (normalized to Ext4) [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Latency of YCSB workloads (normalized to Ext4). YCSB-C does not have write latency as it is read-only. to persist large amounts of data to the disk with high paral￾lelism, while reducing the critical metadata writes caused by frequent appending with byte interfaces. As…
Figure 8
Figure 8. Figure 8: Host-SSD I/O traffic breakdown with Filebench Micro-benchmarks (normalized to NOVA). 0 1 2 3 4 5 Traffic E F N P B E F N P B E F N P B E F N P B E F N P B Varmail Fileserver Webserver Webproxy OLTP 7.5 GB 17.1 GB 11.1 GB 2.7 GB 5.2 GB data_read data_write metadata_read…
Figure 9
Figure 9. Figure 9: Host-SSD I/O traffic breakdown with Filebench Macro-benchmarks (normalized to Ext4). 5.3 I/O Traffic Breakdown I/O Traffic Between Host and SSD [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 12
Figure 12. Figure 12: ByteFS perforamce breakdown. ByteFS-Dual: ByteFS with only dual interface. ByteFS-Log: ByteFS-Dual with log-structured memory. ByteFS: the full ByteFS design. 25/200 40/60 3/80 3/80* 25/200 40/60 3/80 3/80* 25/200 40/60 3/80 3/80* 25/200 40/60 3/80 3/80* 25/200 40/60 …
Figure 11
Figure 11. Figure 11: SSD flash traffic breakdown with Filebench Macro-benchmarks (normalized to Ext4). host, Ext4 needs toload the entire block, even though only part of the block needs to be updated. ByteFS can directly update the requested data at byte granularity, reducing read traffic…
Figure 14
Figure 14. Figure 14: Performance impact of the log region size (normalized to 64MB). 5.6 Sensitivity Analysis Vary M-SSD Access Latency. We vary the emulator config￾uration with various NAND flash read/write latencies from low-end to high-end SSDs [2, 16, 49]. As shown in [PITH_FULL_IMAG…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 54 canonical work pages

  1. [1]

    https://samsungmsl.com/ms-ssd/

    Memory semantic ssd. https://samsungmsl.com/ms-ssd/

    work page

  2. [2]

    https://www.tomshardware.com/reviews/intel-optane-ssd- 905p,5600-2.html, 2021

    intel Optane SSD 905P 1TB Performance Testing. https://www.tomshardware.com/reviews/intel-optane-ssd- 905p,5600-2.html, 2021

    work page 2021

  3. [3]

    https://www.intel.com/content/www/us/en/products/docs/memory- storage/optane-persistent-memory/optane-persistent-memory-200- series-brief.html, 2021

    Intel ® Optane™ Persistent Memory 200 Series Brief. https://www.intel.com/content/www/us/en/products/docs/memory- storage/optane-persistent-memory/optane-persistent-memory-200- series-brief.html, 2021

    work page 2021

  4. [4]

    https://www.memorybenchmark.net/ram.php?ram=SK+Hynix+ HMA82GS7CJR8N-VK+16GB&id=12578, 2021

    Passmark - SK Hynix HMA82GS7CJR8N-VK 16GB - Price Performance Comparison. https://www.memorybenchmark.net/ram.php?ram=SK+Hynix+ HMA82GS7CJR8N-VK+16GB&id=12578, 2021

    work page 2021

  5. [5]

    https://github.com/facebook/rocksdb, 2021

    RocksDB. https://github.com/facebook/rocksdb, 2021

    work page 2021

  6. [6]

    https://www.samsung.com/semiconductor/minisite/ssd/product/ consumer/970pro/, 2021

    Samsung SSD 970 Pro. https://www.samsung.com/semiconductor/minisite/ssd/product/ consumer/970pro/, 2021. ASPLOS ’25, March 30–April 3, 2025, Rotterdam, Netherlands Shaobo Li, Yirui Eric Zhou, Hao Ren, and Jian Huang

    work page 2021

  7. [7]

    https://www.theregister.com/2022/07/29/intel_optane_memory_ dead/, 2022

    Why Intel killed its Optane memory business. https://www.theregister.com/2022/07/29/intel_optane_memory_ dead/, 2022

    work page 2022

  8. [8]

    https://www.intel.com/content/www/us/en/support/articles/ 000005779/processors.html, 2024

    Intel ® Instruction Set Extensions Technology. https://www.intel.com/content/www/us/en/support/articles/ 000005779/processors.html, 2024

    work page 2024

Show all 55 references
  1. [9]

    https://www.purestorage.com/knowledge/what-is-storage-class- memory.html, 2024

    What is storage class memory. https://www.purestorage.com/knowledge/what-is-storage-class- memory.html, 2024

    2024

  2. [10]

    Flatflash: Exploiting the byte-accessibility of ssds within a unified memory-storage hierarchy

    Ahmed Abulila, Vikram Sharma Mailthody, Zaid Qureshi, Jian Huang, Nam Sung Kim, Jinjun Xiong, and Wen-mei Hwu. Flatflash: Exploiting the byte-accessibility of ssds within a unified memory-storage hierarchy. In Proceedings of the Twenty-Fourth International Conference on Archit...

    2019

  3. [11]

    Akinaga and H

    H. Akinaga and H. Shima. Resistive random access memory (reram) based on metal oxides. Proceedings of the IEEE, 98(12):2237–2251, Dec 2010

    2010

  4. [12]

    2b-ssd: The case for dual, byte- and block-addressable solid-state drives

    Duck-Ho Bae, Insoon Jo, Youra Adel Choi, Joo-Young Hwang, Sangyeun Cho, Dong-Gi Lee, and Jaeheon Jeong. 2b-ssd: The case for dual, byte- and block-addressable solid-state drives. In 2018 ACM/IEEE 45th Annual International Symposium on Computer Architecture (ISCA), pages 425–438, 2018

    2018

  5. [13]

    Non-volatile memory tech- nologies: emerging concepts and new materials.Materials Science in Semiconductor Processing, 7(4-6):349–355, 2004

    Roberto Bez and Agostino Pirovano. Non-volatile memory tech- nologies: emerging concepts and new materials.Materials Science in Semiconductor Processing, 7(4-6):349–355, 2004

    2004

  6. [14]

    PCI express system architecture

    Ravi Budruk, Don Anderson, and Tom Shanley. PCI express system architecture. Addison-Wesley Professional, 2004

    2004

  7. [15]

    A review of emerging non-volatile memory (nvm) technologies and applications

    An Chen. A review of emerging non-volatile memory (nvm) technologies and applications. Solid-State Electronics, 125:25–38, 2016

    2016

  8. [16]

    A flash memory controller for 15𝜇s ultra-low-latency ssd using high-speed 3d nand flash with 3𝜇s read time

    Wooseong Cheong, Chanho Yoon, Seonghoon Woo, Kyuwook Han, Dae- hyun Kim, Chulseung Lee, Youra Choi, Shine Kim, Dongku Kang, Geun- yeong Yu, et al. A flash memory controller for 15𝜇s ultra-low-latency ssd using high-speed 3d nand flash with 3𝜇s read time. In2018 IEEE Interna- t...

    2018

  9. [17]

    Nightingale, Christopher Frost, Engin Ipek, Benjamin Lee, Doug Burger, and Derrick Coetzee

    Jeremy Condit, Edmund B. Nightingale, Christopher Frost, Engin Ipek, Benjamin Lee, Doug Burger, and Derrick Coetzee. Better I/O Through Byte-addressable, Persistent Memory. In Proceedings of the ACM SIGOPS 22Nd Symposium on Operating Systems Principles, SOSP ’09, pages 133–146...

    2009

  10. [18]

    Oltp-bench: An extensible testbed for benchmarking relational databases

    Djellel Eddine Difallah, Andrew Pavlo, Carlo Curino, and Philippe Cudré-Mauroux. Oltp-bench: An extensible testbed for benchmarking relational databases. PVLDB, 7(4):277–288, 2013

    2013

  11. [19]

    Dulloor, Sanjay Kumar, Anil Keshavamurthy, Philip Lantz, Dheeraj Reddy, Rajesh Sankaran, and Jeff Jackson

    Subramanya R. Dulloor, Sanjay Kumar, Anil Keshavamurthy, Philip Lantz, Dheeraj Reddy, Rajesh Sankaran, and Jeff Jackson. System Software for Persistent Memory. In Proceedings of the 9th European Conference on Computer Systems , EuroSys ’14, pages 15:1–15:15, Amsterdam, The Net...

    2014

  12. [20]

    https://en.wikipedia.org/wiki/Ferroelectric_RAM

    Ferroelectric RAM. https://en.wikipedia.org/wiki/Ferroelectric_RAM

  13. [21]

    Gonugondla, Mingu Kang, Yongjune Kim, Mark Helm, Sean Eilert, and Naresh Shanbhag

    Sujan K. Gonugondla, Mingu Kang, Yongjune Kim, Mark Helm, Sean Eilert, and Naresh Shanbhag. Energy-efficient deep in-memory architecture for nand flash memories. In 2018 IEEE International Symposium on Circuits and Systems (ISCAS), pages 1–5, 2018

    2018

  14. [22]

    Arpaci-Dusseau, and Remzi H

    Jun He, Sudarsun Kannan, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. Compute express link (cxl), 2017

    2017

  15. [23]

    3D XPoint: A Breakthrough in Non-Volatile Memory Technology

    Intel. 3D XPoint: A Breakthrough in Non-Volatile Memory Technology. https://www.intel.com/content/www/us/en/architecture-and- technology/intel-micron-3d-xpoint-webcast.html , 2018

    2018

  16. [24]

    Intel ® optane™ persistent memory

    Intel. Intel ® optane™ persistent memory. http://www.intel.com/ optanedcpersistentmemory/, 2021

    2021

  17. [25]

    Basic performance measurements of the intel optane dc persistent memory module

    Joseph Izraelevitz, Jian Yang, Lu Zhang, Juno Kim, Xiao Liu, Amirsaman Memaripour, Yun Joon Soh, Zixuan Wang, Yi Xu, Subramanya R Dulloor, et al. Basic performance measurements of the intel optane dc persistent memory module. arXiv preprint arXiv:1903.05714, 2019

    1903 arXiv

  18. [26]

    Hello bytes, bye blocks: Pcie storage meets compute express link for memory expansion (cxl-ssd)

    Myoungsoo Jung. Hello bytes, bye blocks: Pcie storage meets compute express link for memory expansion (cxl-ssd). InProceedings of the 14th ACM Workshop on Hot Topics in Storage and File Systems, HotStorage ’22, page 45–51, New York, NY, USA, 2022. Association for Computing Machinery

    2022

  19. [27]

    Splitfs: Reducing software overhead in file systems for persistent memory

    Rohan Kadekodi, Se Kwon Lee, Sanidhya Kashyap, Taesoo Kim, Aasheesh Kolli, and Vijay Chidambaram. Splitfs: Reducing software overhead in file systems for persistent memory. SOSP ’19, page 494–508, New York, NY, USA, 2019. Association for Computing Machinery

    2019

  20. [28]

    Journal (jbd2) - The Linux Kernel documentation

    The kernel development community. Journal (jbd2) - The Linux Kernel documentation. https://www.kernel.org/doc/html/latest/filesystems/ext4/journal. html, 2024

    2024

  21. [29]

    Strata: A Cross Media File System

    Youngjin Kwon, Henrique Fingler, Tyler Hunt, Simon Peter, Emmett Witchel, and Thomas Anderson. Strata: A Cross Media File System. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP ’17, pages 460–477, Shanghai, China, 2017

    2017

  22. [30]

    F2FS: A New File System for Flash Storage

    Changman Lee, Dongho Sim, Joo Young Hwang, and Sangyeun Cho. F2FS: A New File System for Flash Storage. InFAST, pages 273–286, 2015

    2015

  23. [31]

    Huaicheng Li, Mingzhe Hao, Michael Hao Tong, Swaminathan Sundararaman, Matias Bjørling, and Haryadi S. Gunawi. The CASE of FEMU: Cheap, accurate, scalable and extensible flash emulator. In16th USENIX Conference on File and Storage Technologies (FAST 18), pages 83–90, Oakland, ...

    2018

  24. [32]

    Linux Page Cache

    Linux. Linux Page Cache. https://tldp.org/LDP/lki/lki-4.html

  25. [33]

    The new ext4 filesystem: current status and future plans

    Avantika Mathur, Mingming Cao, Suparna Bhattacharya, Andreas Dilger, Alex Tomas, and Laurent Vivier. The new ext4 filesystem: current status and future plans. InProceedings of the Linux symposium, volume 2, pages 21–33. Citeseer, 2007

    2007

  26. [34]

    Analyzing IO amplification in linux file systems.CoRR, abs/1707.08514, 2017

    Jayashree Mohan, Rohan Kadekodi, and Vijay Chidambaram. Analyzing IO amplification in linux file systems.CoRR, abs/1707.08514, 2017

    2017 arXiv

  27. [35]

    Arpaci-Dusseau, and Remzi H

    Thanumalayan Sankaranarayana Pillai, Vijay Chidambaram, Ram- natthan Alagappan, Samer Al-Kiswany, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau. All file systems are not created equal: On the complexity of crafting Crash-Consistent applications. In11th USENIX Symposium...

    2014

  28. [36]

    Sheng Qiu and A. L. Narasimha Reddy. Nvmfs: A hybrid file system for improving random write in nand-flash ssd. In2013 IEEE 29th Symposium on Mass Storage Systems and Technologies (MSST), pages 1–5, 2013

    2013

  29. [37]

    Qureshi, Vijayalakshmi Srinivasan, and Jude A

    Moinuddin K. Qureshi, Vijayalakshmi Srinivasan, and Jude A. Rivers. Scalable high performance main memory system using phase-change memory technology. In 36th International Symposium on Computer Architecture (ISCA 2009), June 20-24, 2009, Austin, TX, USA, pages 24–33, 2009

    2009

  30. [38]

    Raoux, G

    S. Raoux, G. W. Burr, M. J. Breitwisch, C. T. Rettner, Y. C. Chen, R. M. Shelby, M. Salinga, D. Krebs, S. H. Chen, H. L. Lung, and C. H. Lam. Phase-change random access memory: A scalable technology. IBM Journal of Research and Development, 52(4.5):465–479, July 2008

    2008

  31. [39]

    Overview of the Linux Virtual File System - The Linux Kernel documentation

    Pekka Enberg Richard Gooch. Overview of the Linux Virtual File System - The Linux Kernel documentation. https://www.kernel.org/doc/html/latest/filesystems/vfs.html, 2024

    2024

  32. [40]

    Cmm-h (cxl memory module - hybrid): Samsung’s cxl-based ssd for the memory-centric computing era

    Samsung Semiconductor. Cmm-h (cxl memory module - hybrid): Samsung’s cxl-based ssd for the memory-centric computing era. https://semiconductor.samsung.com/us/news-events/tech- blog/webinar-memory-semantic-ssd/ , 2023

    2023

  33. [41]

    Compute express link ®: An open industry- standard interconnect enabling heterogeneous data-centric computing

    Debendra Das Sharma. Compute express link ®: An open industry- standard interconnect enabling heterogeneous data-centric computing. In 2022 IEEE Symposium on High-Performance Interconnects (HOTI) , pages 5–12, 2022

    2022

  34. [42]

    Chia-Che Tsai, Yang Zhan, Jayashree Reddy, Yizheng Jiao, Tao Zhang, and Donald E Porter. How to get more value from your file system ByteFS: System Support for (CXL-based) Memory-Semantic Solid-State Drives ASPLOS ’25, March 30–April 3, 2025, Rotterdam, Netherlands directory c...

    2025

  35. [43]

    Filebench: A flexible framework for file system benchmarking

    Vasily Tarasov,et al. Filebench: A flexible framework for file system benchmarking. The USENIX Magazine, 41(1), 2016

    2016

  36. [44]

    Characterizing and modeling non-volatile memory systems

    Zixuan Wang, Xiao Liu, Jian Yang, Theodore Michailidis, Steven Swanson, and Jishen Zhao. Characterizing and modeling non-volatile memory systems. In Proceedings of 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO’20), 2020

    2020

  37. [45]

    XArray - The Linux Kernel documentation

    Matthew Wilcox. XArray - The Linux Kernel documentation. https://www.kernel.org/doc/html/latest/core-api/xarray.html, 2024

    2024

  38. [46]

    Noh, and Beomseok Nam

    Hobin Woo, Daegyu Han, Seungjoon Ha, Sam H. Noh, and Beomseok Nam. On stacking a persistent memory file system on legacy file systems. In 21st USENIX Conference on File and Storage Technologies (FAST 23), pages 281–296, Santa Clara, CA, February 2023. USENIX Association

    2023

  39. [47]

    Treesls: A whole-system persistent microkernel with tree-structured state checkpoint on nvm

    Fangnuo Wu, Mingkai Dong, Gequan Mo, and Haibo Chen. Treesls: A whole-system persistent microkernel with tree-structured state checkpoint on nvm. In Proceedings of the 29th Symposium on Operating Systems Principles (SOSP’23), Koblenz, Germany, 2023

    2023

  40. [48]

    NOVA: A log-structured file system for hybrid Volatile/Non-volatile main memories

    Jian Xu and Steven Swanson. NOVA: A log-structured file system for hybrid Volatile/Non-volatile main memories. In 14th USENIX Conference on File and Storage Technologies (FAST 16), pages 323–338, Santa Clara, CA, February 2016. USENIX Association

    2016

  41. [49]

    Shao-Peng Yang, Minjae Kim, Sanghyun Nam, Juhyung Park, Jin yong Choi, Eyee Hyun Nam, Eunji Lee, Sungjin Lee, and Bryan S. Kim. Overcoming the memory wall with CXL-Enabled SSDs. In2023 USENIX Annual Technical Conference (USENIX ATC 23), pages 601–617, Boston, MA, July 2023. US...

    2023

  42. [50]

    Ziggurat: A tiered file system for Non-Volatile main memories and disks

    Shengan Zheng, Morteza Hoseinzadeh, and Steven Swanson. Ziggurat: A tiered file system for Non-Volatile main memories and disks. In17th USENIX Conference on File and Storage Technologies (FAST 19), pages 207–219, Boston, MA, February 2019. USENIX Association

    2019

  43. [51]

    GRUB_CMDLINE_LINUX=

    Diyu Zhou, Vojtech Aschenbrenner, Tao Lyu, Jian Zhang, Sudarsun Kannan, and Sanidhya Kashyap. Enabling high-performance and secure userspace nvm file systems with the trio architecture. In Proceedings of the 29th Symposium on Operating Systems Principles (SOSP’23), Koblenz, Ge...

    2023

  44. [52]

    /utils/filebench_workloads

    Changing workload settings. Users can customize their own workload by modifying the provided configurations under "./utils/filebench_workloads" or "./utils/ycsb_workloads" and evaluate them

  45. [53]

    /linux/ssd/ftl.h

    Changing emulated SSD capacity.Users can change the emulated SSD capcity by modifying the kernel command line parameters reserving more DRAM space to perform the experiments. The user should also align the param- eter in "./linux/ssd/ftl.h", changing the physical address range...

  46. [54]

    /linux/ssd/timing_model.h

    Changing SSD timing model. The user can change the SSD timing model in "./linux/ssd/timing_model.h". Changes will be applied after re-compiling the kernel

  47. [55]

    /linux/ssd/ftl.h

    Changing SSD log size. The user can change the SSD log size in "./linux/ssd/ftl.h". Changes will be applied after re-compiling the kernel. More details on how to customize the experiments can be found in the README file in github repository. A.7 Methodology Submission, reviewi...

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.