Pith. sign in

REVIEW 2 major objections 4 minor 38 references

Kernel/User-level Collaborative Persistent Memory File System with Efficiency and Protection

T0 review · 2 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 1908.10740 v1 pith:53MGGDQE submitted 2019-08-28 cs.OS

classification cs.OS
keywords persistentmemoryfilesystemkernel-usercollaborationwriteprotectioncopy-on-writelock-freereadrangelockindexoffloadingOptaneDC
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 4 minor

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.

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 (2)
  1. [Section 4.4 (Figure 5)] 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.
  2. [Section 4.3 (Figure 4)] 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.
minor comments (4)
  1. [Introduction vs. Section 2.1] 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.
  2. [Section 6.1/6.2] 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.
  3. [Figures 6-10] 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.
  4. [Throughout] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: KucoFS is an empirical systems paper whose design claims are supported by external benchmarks and clean ablations, not by fitted predictions or load-bearing self-citation.

full rationale

KucoFS is an empirical systems paper, not a derivation-based paper. The central claims are architectural: user-level direct access plus kernel-enforced write protection, scalability through index offloading and batching, and lock-free fast read. None of these claims is obtained by fitting a parameter to data and then predicting the same data; the evaluation uses external benchmarks (FxMark, Filebench, Redis) and compares against independent baseline file systems. The optimization breakdown in Section 6.5 is a proper ablation: the paper disables batching and index offloading and re-measures, which is the standard way to attribute performance, not a circular prediction. The few self-citations ([10] HINFS and [22] Ou et al.) appear only as background examples of NVM-aware file systems and do not supply the load-bearing premise of any KucoFS mechanism. The lock-free fast-read protocol in Section 4.4 is asserted with three valid patterns rather than formally proven; the concern that a torn 96-bit mapping item could mimic a valid pattern is a correctness/atomicity risk, not a circularity, because KucoFS's claimed consistency does not reduce by construction to an input of the paper. No equation or claim is shown to be equivalent to its own assumption, and no fitted quantity is renamed as a prediction. Therefore the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

This is a systems paper; the central claim does not rest on fitted parameters. It rests on hardware and trust assumptions about page-table toggling, user-space address validation, and benchmark representativeness. No new physical entities are introduced.

assumptions (3)
  • domain assumption The hardware platform (Intel Optane DC PM) and OS provide mechanisms for the kernel to modify page table permissions and flush TLBs at the granularity needed by the write protocol.
    Section 4.3 relies on toggling permission bits and TLB flushes for each write operation; if these operations are not sufficiently cheap or if they require IPIs that scale poorly, the performance claim weakens.
  • domain assumption User-level applications link Ulib and use its interfaces; the master trusts Ulib for the correctness of pre-located metadata addresses and checksums.
    The design protects against buggy programs, not malicious ones. Section 4.2 (Index Offloading) passes user-computed addresses to the kernel master, which must validate them safely; the paper does not detail the validation mechanism.
  • domain assumption The benchmarks (FxMark, Filebench, Redis) are representative of real NVM file system workloads.
    The evaluation in Section 6 uses these benchmarks to support the scalability and performance claims; if these workloads do not reflect real usage, the claims are overstated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Kernel/User-level Collaborative Persistent Memory File System with Efficiency and Protection." pith.science (2026). https://pith.science/paper/53MGGDQE

@misc{pith2026190810740,
  author       = {Pith},
  title        = {Pith review of: Kernel/User-level Collaborative Persistent Memory File System with Efficiency and Protection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/53MGGDQE}},
  note         = {Machine review of arXiv:1908.10740}
}
read the original abstract

Emerging high performance non-volatile memories recall the importance of efficient file system design. To avoid the virtual file system (VFS) and syscall overhead as in these kernel-based file systems, recent works deploy file systems directly in user level. Unfortunately, a userlevel file system can easily be corrupted by a buggy program with misused pointers, and is hard to scale on multi-core platforms which incorporates a centralized coordination service. In this paper, we propose KucoFS, a Kernel and user-level collaborative file system. It consists of two parts: a user-level library with direct-access interfaces, and a kernel thread, which performs metadata updates and enforces write protection by toggling the permission bits in the page table. Hence, KucoFS achieves both direct-access of user-level designs and fine-grained write protection of kernel-level ones. We further explore its scalability to multicores: For metadata scalability, KucoFS rebalances the pathname resolution overhead between the kernel and userspace, by adopting the index offloading technique. For data access efficiency, it coordinates the data allocation between kernel and userspace, and uses range-lock write and lock-free read to improve concurrency. Experiments on Optane DC persistent memory show that KucoFS significantly outperforms existing file systems and shows better scalability.

Figures

Figures reproduced from arXiv: 1908.10740 by the authors.

Figure 1
Figure 1. Analysis of OS-part Overhead with NOVA. taining page cache in DRAM, but such caching mechanism is not always effective for NVMs since they have very close access latency. Therefore, a number of NVM-aware file sys￾tems choose to bypass them directly [10,12,13,22,31,33,37]. However, we find that the remaining software stack in VFS is still too heavyweight: Our experiments show that NOVA has to spend an average of 34% … view at source ↗
Figure 2
Figure 2. Architecture of KucoFS. the common case (several feasible approaches have been proposed in Section 4.4). 3) Some minor properties are not implemented in KucoFS (e.g., atime, etc.). 4 Design We designed KucoFS with the main goal of providing direct￾access while enforcing data protection, failure atomicity, consistency, as well as the scalability to multi-cores. 4.1 Overview of KucoFS [PITH_FULL_IMAGE:figures/full_fi… view at source ↗
Figure 3
Figure 3. Data layout in KucoFS and the steps to create a file. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Layout of Direct Access Range-Lock. is finished, KucoFS simply rollbacks to its original state. As such, the failure atomicity and consistency is guaranteed. We rely on the master to enforce write protection over each file page leveraging the permission bits in the pag…
Figure 5
Figure 5. Figure 5: Lock-Free Fast Read with Version Checking. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Read and write throughput with FxMark. ( [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: readdir performance with FxMark. (“Medium”: In the same folder) is larger than the raw bandwidth of Optane DC (which is 37 GB/s), because FxMark let each thread read one file page repeatedly, and the accessed data is cached in the CPU cache. With our emulated persisten…
Figure 9
Figure 9. Figure 9: Filebench Throughput with Different File Systems. [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 37 canonical work pages

  1. [1]

    http: //www.nfsv4bat.org/Documents/nasconf/2004/ filebench.pdf

    Filebench file system benchmark. "http: //www.nfsv4bat.org/Documents/nasconf/2004/ filebench.pdf", 2004

  2. [2]

    https://lwn.net/ Articles/588218

    Support ext4 on NV-DIMMs. " https://lwn.net/ Articles/588218", 2014

  3. [3]

    https://www.spec.org/sfs2014/

    Specsfs-2014. "https://www.spec.org/sfs2014/", 2017

  4. [4]

    https://www.intel.com/content/www/ us/en/architecture-and-technology/ optane-dc-persistent-memory.html

    Intel optane dc persistent memory. "https://www.intel.com/content/www/ us/en/architecture-and-technology/ optane-dc-persistent-memory.html" , 2019

  5. [5]

    Highly scalable nonvolatile resistive memory using simple binary oxide driven by asymmetric unipolar voltage pulses

    IG Baek, MS Lee, S Seo, MJ Lee, DH Seo, D-S Suh, JC Park, SO Park, HS Kim, IK Yoo, et al. Highly scalable nonvolatile resistive memory using simple binary oxide driven by asymmetric unipolar voltage pulses. In Electron Devices Meeting, 2004. IEDM Technical Digest. IEEE International, pages 587–590. IEEE, 2004

  6. [6]

    Dune: Safe user-level access to privileged cpu features

    Adam Belay, Andrea Bittau, Ali Mashtizadeh, David Terei, David Mazières, and Christos Kozyrakis. Dune: Safe user-level access to privileged cpu features. In Proceedings of the 10th USENIX Conference on Oper- ating Systems Design and Implementation , OSDI’12, pages 335–348, Berkeley, CA, USA, 2012. USENIX Association

  7. [7]

    Ix: A protected dataplane operating system for high throughput and low latency

    Adam Belay, George Prekas, Ana Klimovic, Samuel Grossman, Christos Kozyrakis, and Edouard Bugnion. Ix: A protected dataplane operating system for high throughput and low latency. In Proceedings of the 11th USENIX Conference on Operating Systems Design and Implementation, OSDI’14, pages 49–65, Berkeley, CA, USA, 2014. USENIX Association

  8. [8]

    Parallel data analysis directly on scientific file formats

    Spyros Blanas, Kesheng Wu, Surendra Byna, Bin Dong, and Arie Shoshani. Parallel data analysis directly on scientific file formats. In Proceedings of the 2014 ACM SIGMOD international conference on Management of data, pages 385–396. ACM, 2014

Show all 38 references
  1. [9]

    Design and implementation of the second extended filesystem

    Remy Card, Theodore Ts’o, and Stephen Tweedie. Design and implementation of the second extended filesystem. In Proceedings of the 1st Dutch International Symposium on Linux, pages 1–6, 1994

  2. [10]

    Hinfs: A persistent memory file system with both buffer- ing and direct-access

    Youmin Chen, Jiwu Shu, Jiaxin Ou, and Youyou Lu. Hinfs: A persistent memory file system with both buffer- ing and direct-access. ACM Trans. Storage, 14(1):4:1– 4:30, April 2018

  3. [11]

    Caulfield, Ameen Akel, Laura M

    Joel Coburn, Adrian M. Caulfield, Ameen Akel, Laura M. Grupp, Rajesh K. Gupta, Ranjit Jhala, and Steven Swanson. Nv-heaps: Making persistent objects fast and safe with next-generation, non-volatile mem- ories. In Proceedings of the Sixteenth International Conference on Architec...

  4. [12]

    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–14...

  5. [13]

    Dulloor, Sanjay Kumar, Anil Keshava- murthy, Philip Lantz, Dheeraj Reddy, Rajesh Sankaran, and Jeff Jackson

    Subramanya R. Dulloor, Sanjay Kumar, Anil Keshava- murthy, Philip Lantz, Dheeraj Reddy, Rajesh Sankaran, and Jeff Jackson. System software for persistent mem- ory. In Proceedings of the Ninth European Conference on Computer Systems, EuroSys ’14, pages 15:1–15:15, New York, NY ...

  6. [14]

    Practical lock-freedom

    Keir Fraser. Practical lock-freedom. Technical report, University of Cambridge, Computer Laboratory, 2004

  7. [15]

    Basic per- formance 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 per- formance measurements of the intel optane dc persistent memory module. arXiv preprint arXiv:1903.05714 , 2019

  8. [16]

    Designing a true direct-access file system with devfs

    Sudarsun Kannan, Andrea C Arpaci-Dusseau, Remzi H Arpaci-Dusseau, Yuangang Wang, Jun Xu, and Gopinath Palani. Designing a true direct-access file system with devfs. In 16th USENIX Conference on File and Storage Technologies, page 241, 2018

  9. [17]

    The machine: An architecture for memory-centric computing

    Kimberly Keeton. The machine: An architecture for memory-centric computing. In Workshop on Runtime and Operating Systems for Supercomputers (ROSS) , 2015

  10. [18]

    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, New York, NY , USA, 2017. ACM

  11. [19]

    Lee, Engin Ipek, Onur Mutlu, and Doug Burger

    Benjamin C. Lee, Engin Ipek, Onur Mutlu, and Doug Burger. Architecting phase change memory as a scalable dram alternative. In Proceedings of the 36th annual International Symposium on Computer Architecture (ISCA), pages 2–13, New York, NY , USA, 2009. ACM. 12

  12. [20]

    Socksdirect: Datacenter sockets can be fast and compatible

    Bojie Li, Tianyi Cui, Zibo Wang, Wei Bai, and Lintao Zhang. Socksdirect: Datacenter sockets can be fast and compatible. In Proceedings of the ACM Special Interest Group on Data Communication, SIGCOMM ’19, pages 90–103, New York, NY , USA, 2019. ACM

  13. [21]

    Understanding manycore scalability of file systems

    Changwoo Min, Sanidhya Kashyap, Steffen Maass, Woonhak Kang, and Taesoo Kim. Understanding manycore scalability of file systems. In Proceedings of the 2016 USENIX Conference on Usenix Annual Technical Conference, USENIX ATC ’16, pages 71–85, Berkeley, CA, USA, 2016. USENIX Association

  14. [22]

    A high perfor- mance file system for non-volatile main memory

    Jiaxin Ou, Jiwu Shu, and Youyou Lu. A high perfor- mance file system for non-volatile main memory. In Proceedings of the Eleventh European Conference on Computer Systems, EuroSys ’16, pages 12:1–12:16, New York, NY , USA, 2016. ACM

  15. [23]

    Simon Peter, Jialin Li, Irene Zhang, Dan R. K. Ports, Doug Woos, Arvind Krishnamurthy, Thomas Anderson, and Timothy Roscoe. Arrakis: The operating system is the control plane. In Proceedings of the 11th USENIX Conference on Operating Systems Design and Implementation, OSDI’14,...

  16. [24]

    Arpaci-Dusseau, and Remzi H

    Thanumalayan Sankaranarayana Pillai, Vijay Chi- dambaram, Ramnatthan 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. In Proceedings of the 1...

  17. [25]

    Skip lists: A probabilistic alternative to balanced trees

    William Pugh. Skip lists: A probabilistic alternative to balanced trees. Commun. ACM, 33(6):668–676, June 1990

  18. [26]

    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 technol- ogy. In Proceedings of the 36th annual International Symposium on Computer Architecture (ISCA) , pages 24–33, New York, NY , USA,...

  19. [27]

    Ffwd: Delegation is (much) faster than you think

    Sepideh Roghanchi, Jakob Eriksson, and Nilanjana Basu. Ffwd: Delegation is (much) faster than you think. In Proceedings of the 26th Symposium on Operating Systems Principles , SOSP ’17, pages 342–358, New York, NY , USA, 2017. ACM

  20. [28]

    Flexsc: Flexible system call scheduling with exception-less system calls

    Livio Soares and Michael Stumm. Flexsc: Flexible system call scheduling with exception-less system calls. In Proceedings of the 9th USENIX Conference on Op- erating Systems Design and Implementation, OSDI’10, pages 33–46, Berkeley, CA, USA, 2010. USENIX As- sociation

  21. [29]

    Scalability in the xfs file system

    Adam Sweeney, Doug Doucette, Wei Hu, Curtis An- derson, Mike Nishimoto, and Geoff Peck. Scalability in the xfs file system. In USENIX Annual Technical Conference, volume 15, 1996

  22. [30]

    Haris V olos, Sanketh Nalli, Sankarlingam Panneersel- vam, Venkatanathan Varadarajan, Prashant Saxena, and Michael M. Swift. Aerie: Flexible file-system interfaces to storage-class memory. InProceedings of the Ninth Eu- ropean Conference on Computer Systems, EuroSys ’14, pages ...

  23. [31]

    Caching or not: Rethinking virtual file system for non-volatile main memory

    Ying Wang, Dejun Jiang, and Jin Xiong. Caching or not: Rethinking virtual file system for non-volatile main memory. In 10th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage 18) . USENIX Association, 2018

  24. [32]

    Xiaojian Wu and A. L. Narasimha Reddy. Scmfs: A file system for storage class memory. In Proceedings of 2011 International Conference for High Performance Computing, Networking, Storage and Analysis, SC ’11, pages 39:1–39:11, New York, NY , USA, 2011. ACM

  25. [33]

    Nova: A log-structured file system for hybrid volatile/non-volatile main mem- ories

    Jian Xu and Steven Swanson. Nova: A log-structured file system for hybrid volatile/non-volatile main mem- ories. In Proceedings of the 14th Usenix Conference on File and Storage Technologies, FAST’16, pages 323– 338, Berkeley, CA, USA, 2016. USENIX Association

  26. [34]

    Nova-fortis: A fault-tolerant non-volatile main memory file system

    Jian Xu, Lu Zhang, Amirsaman Memaripour, Akshatha Gangadharaiah, Amit Borase, Tamires Brito Da Silva, Steven Swanson, and Andy Rudoff. Nova-fortis: A fault-tolerant non-volatile main memory file system. In Proceedings of the 26th Symposium on Operating Systems Principles , SOSP...

  27. [35]

    Application-level optimization of big data transfers through pipelining, parallelism and con- currency

    Esma Yildirim, Engin Arslan, Jangyoung Kim, and Tevfik Kosar. Application-level optimization of big data transfers through pipelining, parallelism and con- currency. IEEE Transactions on Cloud Computing , 4(1):63–75, 2016

  28. [36]

    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. In 17th USENIX Conference on File and Storage Technologies (FAST 19), pages 207– 219, 2019

  29. [37]

    A file system bypassing volatile main memory: Towards a 13 single-level persistent store

    Deng Zhou, Wen Pan, Tao Xie, and Wei Wang. A file system bypassing volatile main memory: Towards a 13 single-level persistent store. In Proceedings of the 15th ACM International Conference on Computing Frontiers, CF ’18, pages 97–104, New York, NY , USA, 2018. ACM

  30. [38]

    A durable and energy efficient main memory using phase change memory technology

    Ping Zhou, Bo Zhao, Jun Yang, and Youtao Zhang. A durable and energy efficient main memory using phase change memory technology. In Proceedings of the 36th annual International Symposium on Computer Architecture (ISCA), pages 14–23, New York, NY , USA,

Pith tools

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