{"id":"0dddc883-d88a-401d-b680-b3cbac6e5fbe","arxiv_id":"1908.10740","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"KucoFS splits persistent-memory file-system work between a user-level library and a kernel thread to get direct-read speed and kernel-enforced write protection, showing higher throughput and better scaling than prior systems on Optane DC PM.","lead":"KucoFS is a file system for persistent memory that combines a user-space library for direct reads with a kernel thread that controls metadata and write permissions, reporting big speedups over existing systems like NOVA and PMFS. It attacks the classic tradeoff between fast user-level access and safe kernel-level protection, though its evaluation has some missing baselines and no shipped code.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Lock-free fast read assumes atomic 96-bit mapping items; the paper never states this, so a torn item can mimic a valid pattern and return mixed old/new data.","rationale":"The reader identified the lock-free fast read protocol in Section 4.4 as the weakest assumption, and I agree. My review sharpens that concern: the paper does not state that the 96-bit mapping items are updated atomically, and the mfence comment only addresses ordering across cachelines, not atomicity within an item. On real x86-64 hardware, a 12-byte item cannot be atomically updated with ordinary stores, so without cmpxchg16b or a seqlock-style re-read, a torn item is possible. Such a torn item can present exactly the start/version/end layout that the protocol treats as valid, defeating the consistency guarantee. This is a concrete correctness risk in the central claim, not merely a stylistic omission. At the same time, the paper's overall architecture is plausible, the evaluation is extensive, and the claimed performance advantages are supported by the experiments modulo the missing artifacts and incomplete baselines. The reader's CONDITIONAL verdict is therefore appropriate: the lock-free read protocol should be either proven with explicit atomicity assumptions or accompanied by code that demonstrates those assumptions are met. Since my concern reinforces rather than redirects the reader's weakest assumption, the verdict remains unchanged.","tokens_in":18187,"tokens_out":7106,"duration_ms":78168,"concrete_test":"Build a TLA+ or Promela model of the block-mapping update exactly as specified in Section 4.4, modeling each 96-bit item as two separate non-atomic stores (pointer, then version/flags) and modeling the reader as checking only the start/version/end pattern. If the model reaches a state satisfying pattern (a) in which one pointer belongs to a newer version while the version field is old, the protocol is unsound as specified. Alternatively, obtain the KucoFS implementation and verify whether each mapping-item store uses a single 16-byte atomic store; if it does not, run a one-reader/one-writer stress test on a small file and checksum every read to detect mixed old/new data.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.4's lock-free fast read is load-bearing for the consistency half of the central claim, and it silently depends on an atomicity assumption that the paper never states. Each block-mapping item is 96 bits (start, version, end, pointer). On x86-64, 12-byte loads and stores are not atomic unless a 16-byte-aligned cmpxchg16b or similar is used; the paper only says that when items span multiple cachelines the master adds mfence, which orders updates but does not make a single item's fields update atomically. If the master updates the pointer and the version/flags with separate stores, a reader can load an old version with a new pointer. Concretely, while writer V1 updates pages 2 and 3 of a 4-page file, page 2's pointer store can become visible before its version/flags store. The reader can then observe item1=V0(start), item2=V0(no flags, new pointer), item3=V0(end), which exactly matches valid pattern (a) in Figure 5, so no reload is triggered. The reader returns page 2 from the in-progress V1 write together with old pages, a torn read. The three claimed valid patterns are therefore not sufficient unless item updates are atomic, and no formal proof or exhaustive state enumeration is provided to rule out this interleaving.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript presents KucoFS, a persistent-memory file system split between a user-space library (Ulib) and a kernel thread (master). Ulib maps the per-user file-system image read-only into application address space, performs direct reads and copy-on-write data updates, and coordinates concurrent writes with a user-space range lock. The master handles metadata updates, append-only logging, checkpointing, and page-table permission toggling to provide write protection. The paper claims that this architecture combines the direct-access performance of user-level file systems with the write protection of kernel-level ones, and presents scalability optimizations: index offloading, batching-based logging, range-lock writes, and lock-free reads. The evaluation on Optane DC persistent memory with FxMark, Filebench, and Redis reports large throughput advantages over NOVA, PMFS, Strata, XFS-DAX, and Ext4-DAX.","tokens_in":18394,"tokens_out":13241,"duration_ms":130815,"significance":"If the design is correct, KucoFS would be a valuable resolution of the user-level versus kernel-level tradeoff for NVM file systems: it demonstrates direct-access reads and writes with page-table-enforced protection, and the evaluation on real Optane DC hardware is a strength. The clean ablations in Section 6.5 (index offloading, batching, lock-free read) are useful and help isolate the contributions of each optimization. However, the correctness of the two main concurrency mechanisms is not fully established: the lock-free fast read in Section 4.4 depends on an unstated atomicity assumption for 96-bit mapping items, and the range-lock ring buffer in Section 4.3 does not specify how slot reuse is handled. These issues must be resolved before the consistency guarantees claimed in Section 3 can be accepted.","major_comments":[{"comment":"The lock-free fast read protocol is only correct if each 96-bit block mapping item is updated and observed atomically, but the paper never states or implements this. On x86-64, 12-byte loads and stores are not atomic; the mfence described for items spanning multiple cachelines orders stores but does not make the fields of one item become visible as a unit. If the master updates the pointer field and the version/flags fields with separate stores, a reader can observe item2 with a new pointer but old version/flags. For the example write to pages 2 and 3 of a four-page file, the reader can see item1=V0(start), item2=V0(no flags, new pointer), item3=V0(end), which exactly matches valid pattern (a); no reload is triggered, and the reader returns a page from the in-progress write mixed with old pages. This violates the consistency guarantee stated at the start of Section 4.4. The paper should either specify that each item is updated with an atomic 16-byte write (e.g., cmpxchg16b with padding to 128 bits), provide a proof or exhaustive state enumeration showing that the three patterns are sufficient under the actual update ordering, or change the metadata layout so items fit in one atomically accessible word.","section":"Section 4.4 (Figure 5)"},{"comment":"The range-lock ring buffer is described as having 8 slots, but lock acquisition selects a slot using version modulo ring size. With more than 8 concurrent writers, which the evaluation uses (e.g., 20 threads in Section 6.2), versions v and v+8 map to the same slot. If writer v has not yet released its slot, writer v+8 overwrites the lock item; the later release of that slot by writer v, or by the master on behalf of writer v, then applies to writer v+8's item, losing a lock or releasing it prematurely. The checksum and lease fields detect corruption but do not prevent this overwrite. Please specify how slot reuse is handled, for example by waiting until the destination slot is free before overwriting, by using tagged slots that are only reused after release, or by sizing the ring buffer according to the maximum number of concurrent writers.","section":"Section 4.3 (Figure 4)"}],"minor_comments":[{"comment":"The Introduction states that context-switch overhead occupies up to 34% of file-system accessing time, while Section 2.1 reports context-switch latency of up to 21% and VFS overhead of 34%; please reconcile these inconsistent numbers.","section":"Introduction vs. Section 2.1"},{"comment":"The Aerie comparison is performed on emulated persistent memory in DRAM and the results are described only in words rather than in figures or tables. Please include the numeric results and explicitly list this as a limitation when comparing with the Optane DC results.","section":"Section 6.1/6.2"},{"comment":"The throughput graphs show no error bars or other measures of variance; if results are stable across runs, stating this would improve confidence, and if not, error bars should be added.","section":"Figures 6-10"},{"comment":"There are several typos and minor wording issues, including 'metdata' (Section 4.3), 'doen't' (Section 4.4), and 'orders of magnitudes' (Section 6.5); a careful proofread is needed.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"This is an arXiv preprint with a strong empirical component, and the two concurrency concerns above are central but appear fixable within the scope of the manuscript. I would not reject on methodology grounds alone; the authors should be asked to either provide the missing atomicity/proof details or adjust the claims accordingly. The paper is within the scope of the journal."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know. First, the core idea is real: a user-level library plus a kernel master that toggles page-table permissions gives you direct-access reads and writes while keeping the file system image read-only to applications. That is a clean resolution of the user-level-versus-kernel tradeoff, and the evaluation on Optane DC is serious: credible speedups over NOVA, PMFS, and DAX file systems, with a clean ablation showing the benefit of index offloading, batching, and lock-free read. The index-offloading and range-lock pieces are also well motivated.\n\nSecond, the lock-free fast read has a load-bearing correctness gap. The stress test is right. Section 4.4's argument only checks three mapping patterns, but it never states that a 96-bit mapping item is updated atomically. If the master writes pointer and version with separate stores, a reader can see an item with an old version and a new pointer. The concrete interleaving—writer updating pages 2 and 3 while the reader sees all-V0 items with start on page 1 and end on page 4—matches valid pattern (a), so no reload triggers, and the reader returns a mix of old and new pages. On x86-64 a 12-byte item is not atomically readable or writable without cmpxchg16b or equivalent. The paper must either use atomic 16-byte updates for mapping items and say so, or give a formal argument that version checking still works under torn fields. As written, the consistency guarantee for concurrent read/write is not established.\n\nOther soft spots are smaller. No code or data artifacts are provided, so independent verification is limited. Aerie is compared on emulated DRAM rather than Optane, and Strata is single-threaded only—these weaken the comparison but do not undermine the main claim. There are no error bars on throughput figures, which is common in systems papers but still worth flagging.\n\nWhat the paper does well: the design is detailed, the failure-atomic write protocol is clearly specified, and the evaluation includes microbenchmarks and real workloads (Redis, Filebench). The ablation of individual optimizations is good practice.\n\nWho this is for: anyone working on persistent-memory file systems or kernel/user-level decomposition for NVMs. It deserves a serious referee; I would accept it conditionally and ask for the lock-free read argument to be fixed, plus artifacts if possible.","headline":"KucoFS is a genuinely new architecture with strong Optane results, but the lock-free read proof has a missing atomicity assumption that a stress test correctly exposes.","tokens_in":18972,"tokens_out":5087,"would_cite":true,"duration_ms":47552,"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":"KucoFS splits a persistent-memory file system between a user-level library and a kernel thread, claiming direct-access speed with kernel-grade write protection.","keywords":["persistent memory file system","kernel-user collaboration","write protection","copy-on-write","lock-free read","range lock","index offloading","Optane DC persistent memory"],"falsifier":"Construct a stress test with one writer repeatedly updating overlapping byte ranges of a single file while many readers scan the block mapping and verify that every returned version pattern corresponds to a consistent snapshot of completed writes. If any interleaving of two writers on adjacent or overlapping pages can produce a valid-looking pattern that mixes old and new data, the protocol fails. A cheaper check is an exhaustive state enumeration of small interleavings of two writers updating a three-page file, comparing each reader-observed mapping against the linearized order of writes.","tokens_in":17947,"feed_emoji":"💾","tokens_out":3228,"duration_ms":35218,"temperature":0.7,"pith_summary":"The paper argues that the usual tradeoff between kernel-level and user-level file systems for non-volatile memory is not inevitable. It presents KucoFS, where a user-space library handles direct reads and copy-on-write data updates while a kernel thread, the master, performs all metadata updates and protects the file-system image by toggling page-table permission bits. The goal is to give applications the low-latency direct access of user-level designs without exposing the file system to corruption by a buggy program. The paper further claims that with index offloading, batching, range locks, and lock-free reads, KucoFS outperforms existing NVM-aware file systems and scales better on multicore machines, based on experiments with Optane DC persistent memory.","feed_headline":"Split file system gives direct NVM access plus write protection","feed_subtitle":"A user library runs the fast path while a kernel thread toggles page permissions to guard metadata and data.","key_machinery":"The central mechanism is the split between the Ulib (user-space library) and the master (kernel thread), with the master enforcing write protection by toggling page-table permission bits. The load-bearing pieces are: the read-only mapping of the file-system image, copy-on-write data updates, a per-file DRAM ring-buffer range lock with version, offset, size, lease, and checksum fields, and 96-bit block-mapping items whose start, version, and end bits let readers detect in-progress writes and retry. Index offloading moves pathname resolution into user space, and batching merges multiple log entries so the master persists metadata with fewer cache flushes.","core_discovery":"The central claim is that direct access and fine-grained write protection can coexist if the file system is split by responsibility rather than by layer. KucoFS maps the user's file-system image read-only into the application's address space, so reads and pathname resolution happen directly in user space. When a write is needed, the master temporarily makes only the target data pages writable through page-table permission bits, and flips them back to read-only after the write is recorded. Writes use copy-on-write and are coordinated in user space with a versioned range lock, while reads use a lock-free protocol that validates 96-bit block-mapping items carrying start, version, end, and pointer fields. The stated result is that this design delivers higher throughput and better multicore scalability than kernel-level file systems such as PMFS, NOVA, XFS-DAX, and Ext4-DAX, and than user-level systems such as Strata and Aerie, in the reported benchmarks.","pith_inferences":["The version-checking read trick could be generalized to any copy-on-write block map, not just KucoFS, and the permission-toggling master could in principle be replaced by hardware page-table support that avoids explicit TLB shootdowns.","The per-user root-tree design, chosen for read protection, points toward a practical multi-tenant isolation model that avoids full POSIX ACLs while still isolating data between users.","A natural testable extension is to measure how often the lock-free read retry path is actually exercised under adversarial write interleavings; the paper reports aggregate throughput but not retry frequency or correctness-verification statistics."],"forward_implications":["If the claims hold, a file system can provide kernel-level write protection without requiring a syscall per read or write operation, closing the gap between direct-access speed and safety for persistent memory.","The design offers a template for other persistent-memory services that need both user-level performance and protection from buggy or misbehaving applications.","The master remains a central coordinator, but index offloading and batched logging push its throughput high enough to scale to tens of cores in the reported workloads.","The version-stamped block-mapping read protocol suggests that per-file read-write locks can be replaced by cheap validation of metadata versions, which is useful for highly concurrent read-heavy workloads."],"supporting_citations":[{"why":"Provides the comparison baseline NOVA, an NVM-aware kernel file system whose syscall and VFS overheads motivate the design.","marker":"[33]"},{"why":"Supplies the Aerie user-level file system comparison and the prior approach of exporting NVM to user space with a trusted service.","marker":"[30]"},{"why":"Supplies the Strata user-level cross-media file system comparison, including its log-based direct access and background digest mechanism.","marker":"[18]"},{"why":"Supplies the PMFS kernel-level NVM file system whose journaling and copy-on-write behavior are compared against KucoFS.","marker":"[13]"},{"why":"Supplies the skip-list data structure used to organize dentry lists for lock-free reads and atomic updates.","marker":"[25]"},{"why":"Supplies the epoch-based reclamation mechanism used to safely reclaim deleted metadata items.","marker":"[14]"},{"why":"Supplies the Ext2-style block mapping approach adapted for KucoFS's file-to-page mapping.","marker":"[9]"},{"why":"Supplies the FxMark micro-benchmark suite used to measure throughput and multicore scalability.","marker":"[21]"},{"why":"Supplies the Filebench macro-benchmark workloads used to evaluate Fileserver and Varmail performance.","marker":"[1]"}],"fun_headline_variants":["Kernel-user split file system: direct NVM access with write protection","KucoFS: collaborative kernel-user design for NVM file systems","Direct-access file system with fine-grained write protection via kernel thread","Split responsibility: user-level speed, kernel-level write protection for PM","KucoFS: blending user direct access and kernel security for persistent memory"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the lock-free read protocol can never be fooled by a torn or stale block mapping: whenever a reader sees one of the three valid version patterns, the data pages it points to really belong to one consistent completed write, even under any interleaving of concurrent writers.","fun_headline_variants_meta":{"raw":{"variants":["Kernel-user split file system: direct NVM access with write protection","KucoFS: collaborative kernel-user design for NVM file systems","Direct-access file system with fine-grained write protection via kernel thread","Split responsibility: user-level speed, kernel-level write protection for PM","KucoFS: blending user direct access and kernel security for persistent memory"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000169,"raw_usage":{"total_tokens":1278,"prompt_tokens":971,"completion_tokens":307,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":587,"completion_tokens_details":{"reasoning_tokens":215}},"tokens_in":587,"tokens_out":307,"duration_ms":3145,"temperature":1.0,"reasoning_tokens":215,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T10:35:42.919327+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Construct a stress test with one writer repeatedly updating overlapping byte ranges of a single file while many readers scan the block mapping and verify that every returned version pattern corresponds to a consistent snapshot of completed writes. If any interleaving of two writers on adjacent or overlapping pages can produce a valid-looking pattern that mixes old and new data, the protocol fails. A cheaper check is an exhaustive state enumeration of small interleavings of two writers updating a three-page file, comparing each reader-observed mapping against the linearized order of writes.","supporting_citations":[{"cited_title":"Nova: A log-structured file system for hybrid volatile/non-volatile main mem- ories","cited_arxiv_id":null,"evidence_quote":"Provides the comparison baseline NOVA, an NVM-aware kernel file system whose syscall and VFS overheads motivate the design."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the Aerie user-level file system comparison and the prior approach of exporting NVM to user space with a trusted service."},{"cited_title":"Strata: A cross media file system","cited_arxiv_id":null,"evidence_quote":"Supplies the Strata user-level cross-media file system comparison, including its log-based direct access and background digest mechanism."},{"cited_title":"Dulloor, Sanjay Kumar, Anil Keshava- murthy, Philip Lantz, Dheeraj Reddy, Rajesh Sankaran, and Jeff Jackson","cited_arxiv_id":null,"evidence_quote":"Supplies the PMFS kernel-level NVM file system whose journaling and copy-on-write behavior are compared against KucoFS."},{"cited_title":"Skip lists: A probabilistic alternative to balanced trees","cited_arxiv_id":null,"evidence_quote":"Supplies the skip-list data structure used to organize dentry lists for lock-free reads and atomic updates."},{"cited_title":"Practical lock-freedom","cited_arxiv_id":null,"evidence_quote":"Supplies the epoch-based reclamation mechanism used to safely reclaim deleted metadata items."},{"cited_title":"Design and implementation of the second extended filesystem","cited_arxiv_id":null,"evidence_quote":"Supplies the Ext2-style block mapping approach adapted for KucoFS's file-to-page mapping."},{"cited_title":"Understanding manycore scalability of file systems","cited_arxiv_id":null,"evidence_quote":"Supplies the FxMark micro-benchmark suite used to measure throughput and multicore scalability."},{"cited_title":"http: //www.nfsv4bat.org/Documents/nasconf/2004/ filebench.pdf","cited_arxiv_id":null,"evidence_quote":"Supplies the Filebench macro-benchmark workloads used to evaluate Fileserver and Varmail performance."}],"review_version":1}