{"id":"617406d0-67c7-4fc4-bfe9-cd9131ed309c","arxiv_id":"2501.04993","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"ByteFS is a file system for memory-semantic SSDs that adaptively mixes byte and block I/O and uses an SSD-side write log, improving throughput by up to 2.7x and cutting write traffic by up to 5.1x in the authors' tests.","lead":"This paper presents ByteFS, a new file system for memory-semantic solid-state drives that supports both byte- and block-level access. ByteFS combines byte-granular writes, a log-structured SSD cache, and coordinated host/device caching, reporting up to 2.7x speedups and up to 5.1x reductions in write traffic.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The crash-consistency and recovery claims depend on an unverified battery-backed DRAM assumption, and the recovery test may not actually cut power.","rationale":"The reader's weakest_assumption correctly identifies that the crash-consistency and recovery guarantees rely on battery-backed DRAM that the prototype does not confirm. I agree that this is the most load-bearing concern because the abstract's claim of preserving \"essential properties of a file system\" includes crash consistency and data recovery, and the entire transaction and recovery mechanism in Sections 4.3 and 4.7 is built on the write log and TxLog being resident in SSD DRAM at the moment of power loss. My partial disagreement is that even with battery-backed DRAM, the mechanism is not fully specified: the paper alternates between \"flushed to the flash media during a power loss\" (Section 2.1) and retaining content in the battery-backed DRAM (Section 4.7), and the recovery procedure scans DRAM structures without describing how those structures are restored after a flush-to-flash event. The Section 5.5 experiment is also ambiguous about whether it cut power to the SSD or simply rebooted the host, so it does not settle the question. A true hard-power-cycle experiment plus a check of the board's power-loss protection would settle the issue: if committed data survives a real power cut and the battery-backed DRAM behavior matches the recovery procedure, the claim is validated; if not, the condition should be explicitly scoped out of the prototype evaluation. Since this concern is addressable with a concrete hardware test and does not invalidate the performance and traffic-reduction results, the reader's CONDITIONAL verdict is the right one; no verdict change is needed.","tokens_in":24463,"tokens_out":4536,"duration_ms":45254,"concrete_test":"Perform a true power-loss test on the OpenSSD prototype: during a YCSB workload, cut power to the entire board (including the SSD), wait long enough for the DRAM to lose charge, restore power, reboot, and run the Section 4.7 RECOVER() procedure, then check whether all committed transactions survive. Independently inspect the board schematics or measure whether the 1GB DRAM is battery/capacitor-backed, and determine whether the firmware reloads the write log and TxLog from flash after a battery-assisted flush. If recovery fails or the DRAM is not battery-backed, the crash-consistency and data-recovery claims are unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that ByteFS \"preserves crash consistency and data recovery\" (abstract; Section 4.7) rests on the write log and TxLog surviving a power failure. The paper assumes battery-backed DRAM, but Section 4.2 only states that an M-SSD \"can leverage\" it, and the Section 4.9 prototype description (OpenSSD FPGA board, 1GB DRAM) never confirms that this DRAM is power-loss-protected. The persistence model is also underspecified: if the battery-backed DRAM is the common type that flushes its contents to flash during power loss (as Section 2.1 implies), the log region and TxLog are no longer in DRAM after power is restored, yet the RECOVER() procedure in Section 4.7 scans the DRAM log region and TxLog and has no described reload-from-flash step. If the DRAM instead stays powered during a power outage, that must be stated and demonstrated on the prototype. The Section 5.5 recovery test reports \"power off the system\" and a 4.2s recovery, but the paper does not say whether this was a true power cut (removing all power) or merely a reboot; a reboot leaves DRAM powered and does not exercise the failure model. Consequently, the crash-consistency and data-recovery portion of the headline claim is unverified on both the real prototype and the emulator.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":24712,"tokens_out":8433,"duration_ms":76874,"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":[{"comment":"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.","section":"§4.2/§4.7/§4.9/§5.5"},{"comment":"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.","section":"§4.3/§4.7"},{"comment":"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.","section":"§5.5"}],"minor_comments":[{"comment":"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.","section":"Abstract/§5.2"},{"comment":"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).","section":"§5.5"},{"comment":"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.","section":"§6/Fig. 12/App. A.6"},{"comment":"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.","section":"§4.3/§5.1"}],"recommendation":"major_revision","confidential_remarks":"The paper is a solid systems contribution with a real prototype and a thorough evaluation, but the crash-consistency and data-recovery claim, which is part of the headline, rests on an unverified battery-backed DRAM assumption and a recovery test that does not demonstrate correctness under a true power loss. This is fixable within a revision if the authors either confirm the hardware support, adapt the recovery procedure to the actual power-loss behavior, and add a correctness validation, or explicitly narrow the claim. I recommend major revision rather than reject."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"ByteFS is a real systems contribution: the first file system explicitly designed for memory-semantic SSDs that expose both byte and block interfaces. The group built it on an OpenSSD FPGA board and a FEMU-based emulator, shipped an artifact with a DOI, and measured a wide set of workloads. The core ideas—byte-granular persistence for small metadata updates, CoW-based dirty tracking to choose write granularity, a log-structured DRAM region in the SSD firmware with skip-list indexing, and coordinated host/device caching—are each individually known, but combining them into one working file system for this device class, with firmware changes, is new and useful. The evaluation is extensive, and the write-traffic reduction numbers (up to 5.1x to flash) are credible given the traffic breakdowns.\n\nThe soft spots are real but mostly addressable. The most serious is the crash-consistency and recovery story. The paper assumes battery-backed DRAM in the M-SSD, citing it in Section 4.2 and 4.7, but the prototype description in Section 4.9 never confirms that the OpenSSD board's 1GB DRAM is power-loss-protected. The recovery test in Section 5.5 says 'power off the system' but doesn't say whether that was a true power cut or just a reboot; a reboot doesn't exercise the failure model. And there's an underspecified step: Section 2.1 says battery-backed DRAM flushes its contents to flash on power loss, yet RECOVER() in Section 4.7 scans the DRAM log region and TxLog with no mention of reloading them from flash. If the DRAM is the flush-to-flash type, the log and TxLog aren't in DRAM when power returns. This needs to be clarified and, ideally, demonstrated.\n\nThe other issues are minor. The abstract's headline 'up to 2.7x' contradicts the 6.0x file-creation speedup in Figure 6; either the abstract should say 6.0x or the 2.7x needs a qualifier. Comparing NOVA and PMFS on an M-SSD is a bit unfair—they target true NVM—but the paper does explain why they are poor fits, and the comparison actually strengthens the argument for a device-specific file system.\n\nOverall, the performance work is solid and the artifact is a plus. The crash-consistency claims need to be pinned down, but they are not load-bearing for the throughput and write-traffic results. This deserves serious peer review; I'd send it out with a request for a revised recovery section and a corrected abstract. I'd cite it in my own work on M-SSDs.","headline":"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.","tokens_in":25285,"tokens_out":2278,"would_cite":true,"duration_ms":20833,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["file system","memory-semantic SSD","byte-addressable storage","CXL","log-structured SSD firmware","crash consistency","I/O amplification","data coalescing"],"falsifier":"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.","tokens_in":24225,"feed_emoji":"💾","tokens_out":7152,"duration_ms":65065,"temperature":0.7,"pith_summary":"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.","feed_headline":"ByteFS: 2.7x faster memory-semantic SSDs, 5.1x less write traffic","feed_subtitle":"A file system that mixes byte- and block-granular writes to cut I/O amplification while keeping crash consistency.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines dual byte/block-addressable SSDs, the device model ByteFS is built around.","marker":"[12]"},{"why":"Shows how an SSD's byte accessibility can be exposed via memory mapping; grounds the MMIO byte interface.","marker":"[10]"},{"why":"NVM file system baseline whose byte-interface design ByteFS extends and compares against.","marker":"[19]"},{"why":"Log-structured NVM file system baseline; central comparison for metadata traffic and write granularity.","marker":"[48]"},{"why":"Flash-friendly block file system baseline whose I/O amplification motivates ByteFS's dual-interface design.","marker":"[30]"},{"why":"Provides the FTL core logic used to build the M-SSD emulator for the evaluation.","marker":"[31]"},{"why":"Supplies the Filebench workloads used to measure throughput and I/O traffic.","marker":"[43]"},{"why":"RocksDB is the application used with YCSB workloads to evaluate end-to-end latency and throughput.","marker":"[5]"}],"fun_headline_variants":["ByteFS: 2.7x faster with byte+block access on memory-semantic SSDs","ByteFS: hybrid byte/block file system reduces write traffic 5.1x","ByteFS: co-designed file system and SSD firmware for 2.7x performance","ByteFS: log-structured DRAM enables byte-granular writes on SSDs","ByteFS: dual-granularity file system for memory-semantic SSDs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["ByteFS: 2.7x faster with byte+block access on memory-semantic SSDs","ByteFS: hybrid byte/block file system reduces write traffic 5.1x","ByteFS: co-designed file system and SSD firmware for 2.7x performance","ByteFS: log-structured DRAM enables byte-granular writes on SSDs","ByteFS: dual-granularity file system for memory-semantic SSDs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000717,"raw_usage":{"total_tokens":3289,"prompt_tokens":1082,"completion_tokens":2207,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":698,"completion_tokens_details":{"reasoning_tokens":2095}},"tokens_in":698,"tokens_out":2207,"duration_ms":17111,"temperature":1.0,"reasoning_tokens":2095,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:20:35.894337+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"2b-ssd: The case for dual, byte- and block-addressable solid-state drives","cited_arxiv_id":null,"evidence_quote":"Defines dual byte/block-addressable SSDs, the device model ByteFS is built around."},{"cited_title":"Flatflash: Exploiting the byte-accessibility of ssds within a unified memory-storage hierarchy","cited_arxiv_id":null,"evidence_quote":"Shows how an SSD's byte accessibility can be exposed via memory mapping; grounds the MMIO byte interface."},{"cited_title":"Dulloor, Sanjay Kumar, Anil Keshavamurthy, Philip Lantz, Dheeraj Reddy, Rajesh Sankaran, and Jeff Jackson","cited_arxiv_id":null,"evidence_quote":"NVM file system baseline whose byte-interface design ByteFS extends and compares against."},{"cited_title":"NOVA: A log-structured file system for hybrid Volatile/Non-volatile main memories","cited_arxiv_id":null,"evidence_quote":"Log-structured NVM file system baseline; central comparison for metadata traffic and write granularity."},{"cited_title":"F2FS: A New File System for Flash Storage","cited_arxiv_id":null,"evidence_quote":"Flash-friendly block file system baseline whose I/O amplification motivates ByteFS's dual-interface design."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the FTL core logic used to build the M-SSD emulator for the evaluation."},{"cited_title":"Filebench: A flexible framework for file system benchmarking","cited_arxiv_id":null,"evidence_quote":"Supplies the Filebench workloads used to measure throughput and I/O traffic."},{"cited_title":"https://github.com/facebook/rocksdb, 2021","cited_arxiv_id":null,"evidence_quote":"RocksDB is the application used with YCSB workloads to evaluate end-to-end latency and throughput."}],"review_version":1}