Skip to content

feat: add --no-push flag for local-only writes (overlay semantics)#90

Draft
XciD wants to merge 2 commits intomainfrom
feat/no-push-overlay
Draft

feat: add --no-push flag for local-only writes (overlay semantics)#90
XciD wants to merge 2 commits intomainfrom
feat/no-push-overlay

Conversation

@XciD
Copy link
Copy Markdown
Member

@XciD XciD commented Apr 1, 2026

Summary

  • Adds --no-push CLI flag that allows local writes without ever uploading to remote storage
  • Reads check local staging files first, then fall back to remote (overlay semantics)
  • Reuses the existing advanced_writes staging infrastructure instead of implementing a parallel write path

Context

Alternative to dacorvo/hf-mount#overlay-write-dir which implements full overlayfs semantics with a dedicated --upperdir. That approach adds ~200 lines touching many VFS methods. This approach achieves the same overlay behavior in ~30 lines by reusing the existing staging/dirty-tracking mechanism and simply not creating the FlushManager.

How it works

  1. --no-push forces advanced_writes = true and read_only = false
  2. The FlushManager is not created, so dirty files are never uploaded
  3. Writes go through the normal staging path (files on disk in --cache-dir)
  4. Reads of dirty inodes already check the staging file first (existing behavior)
  5. Locally created inodes are already in the inode table and appear in directory listings

Use case

Mounting a shared remote bucket (e.g. AWS Neuron compilation cache) and writing local artifacts on top without pushing back. See Slack thread for context.

Limitation

Local writes live in the staging directory under --cache-dir. For persistence across sessions, the user should pass a stable --cache-dir path. The staging dir uses inode numbers as filenames, so persistence across different mount sessions of the same source requires the same inode assignment order (which is deterministic for the same remote state).

Allow writes to be stored locally in the cache/staging directory without
ever uploading to remote storage. Reads check local files first, then
fall back to remote content (overlay semantics).

This is a simpler alternative to a full overlayfs-style upperdir
implementation: instead of adding a parallel write path, we reuse the
existing advanced_writes staging infrastructure and simply skip creating
the FlushManager, so dirty files stay local indefinitely.

Useful for caching expensive-to-produce artifacts (e.g. compilation
caches) on top of a shared read-only remote bucket.
@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 1, 2026

POSIX Compliance (pjdfstest)

============================================================
  pjdfstest POSIX Compliance Results
------------------------------------------------------------
  Files: 130/130 passed    Tests: 832 total (0 subtests failed)
  Result: PASS
------------------------------------------------------------
  Category               Passed    Total   Status
  -------------------- -------- -------- --------
  chflags                     5        5       OK
  chmod                       8        8       OK
  chown                       6        6       OK
  ftruncate                  13       13       OK
  granular                    5        5       OK
  mkdir                       9        9       OK
  open                       19       19       OK
  posix_fallocate             1        1       OK
  rename                     10       10       OK
  rmdir                      11       11       OK
  symlink                    10       10       OK
  truncate                   13       13       OK
  unlink                     11       11       OK
  utimensat                   9        9       OK
============================================================

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 1, 2026

Benchmark Results

============================================================
  Benchmark — 50MB
------------------------------------------------------------
  Metric                                 FUSE          NFS
  ------------------------------ ------------ ------------
  Sequential read                    208.5 MB/s     225.7 MB/s
  Sequential re-read                1563.0 MB/s    2238.3 MB/s
  Range read (1MB@25MB)               62.1 ms         0.2 ms
  Random reads (100x4KB avg)          43.2 ms         0.0 ms
  Sequential write (FUSE)           1335.4 MB/s
  Close latency (CAS+Hub)            0.104 s
  Write end-to-end                   352.6 MB/s
  Dedup write                       1592.5 MB/s
  Dedup close latency                0.485 s
  Dedup end-to-end                    96.8 MB/s
============================================================
============================================================
  Benchmark — 200MB
------------------------------------------------------------
  Metric                                 FUSE          NFS
  ------------------------------ ------------ ------------
  Sequential read                    453.7 MB/s     968.2 MB/s
  Sequential re-read                1746.8 MB/s    2303.3 MB/s
  Range read (1MB@25MB)               34.8 ms         0.2 ms
  Random reads (100x4KB avg)          45.6 ms         0.0 ms
  Sequential write (FUSE)           1006.0 MB/s
  Close latency (CAS+Hub)            0.122 s
  Write end-to-end                   624.1 MB/s
  Dedup write                        964.7 MB/s
  Dedup close latency                0.100 s
  Dedup end-to-end                   651.0 MB/s
============================================================
============================================================
  Benchmark — 500MB
------------------------------------------------------------
  Metric                                 FUSE          NFS
  ------------------------------ ------------ ------------
  Sequential read                   1147.8 MB/s    1440.9 MB/s
  Sequential re-read                1709.6 MB/s    2441.8 MB/s
  Range read (1MB@25MB)               40.9 ms         0.2 ms
  Random reads (100x4KB avg)          32.1 ms         0.0 ms
  Sequential write (FUSE)            995.3 MB/s
  Close latency (CAS+Hub)            0.128 s
  Write end-to-end                   792.8 MB/s
  Dedup write                        920.6 MB/s
  Dedup close latency                0.107 s
  Dedup end-to-end                   769.5 MB/s
============================================================
============================================================
  fio Benchmark Results
------------------------------------------------------------
  Job                        FUSE MB/s   NFS MB/s  FUSE IOPS   NFS IOPS
  ------------------------- ---------- ---------- ---------- ----------
  seq-read-100M                  502.5      353.4                      
  seq-reread-100M               2381.0        7.8                      
  rand-read-4k-100M                0.1        0.1         19         14
  seq-read-5x10M                 746.3      595.2                      
  rand-read-10x1M                  0.1        0.1         36         31
  Random Read Latency           FUSE avg      NFS avg
  ------------------------- ------------ ------------
  rand-read-4k-100M           52967.6 us   73703.3 us
  rand-read-10x1M             27864.4 us   32579.4 us
============================================================

@XciD XciD closed this Apr 1, 2026
@XciD XciD reopened this Apr 1, 2026
Print the exact staging directory path so the user knows where their
local writes are stored on disk.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant