DEV Community: Josh Klein

How to Setup NFS Sharing on Debian 13 and Mount on macOS, Linux, and Windows (with Performance Tuning)

Josh Klein — Sun, 02 Aug 2026 04:37:51 +0000

Network File System (NFS) allows you to share directories between systems over a local network. This guide covers setting up an NFS server on Debian 13, mounting it across macOS, Linux, and Windows, and optimizing read/write speeds.

Part 1: NFS Server Setup (Debian 13)

Install NFS Kernel Server Update package lists and install the NFS server package:

 sudo apt update
 sudo apt install nfs-kernel-server

Configure Directory Permissions Assume your target share directory is /mnt/hd1/sage_nfs. Adjust permissions so client requests map cleanly without permission issues:

sudo chown -R 1000:1000 /mnt/hd1/sage_nfs
sudo chmod -R 775 /mnt/hd1/sage_nfs

Edit NFS Exports File Open the exports configuration file:

sudo nano /etc/exports

Add the following export rule (replace 192.168.8.0/24 with your local network subnet):

/mnt/hd1/sage_nfs 192.168.8.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000,insecure)

insecure: Required for macOS clients, allowing them to connect using non-privileged ports.
all_squash + anonuid/anongid: Maps all client requests to UID/GID 1000 to prevent permission conflicts.

Apply Changes and Start Service Export the shared directories and start the server:

sudo exportfs -arv
sudo systemctl restart nfs-kernel-server
sudo systemctl enable nfs-kernel-server

Part 2: Client Mounting Guide

macOS Client macOS handles NFS natively via Finder or terminal.

Create local mount point:

 sudo mkdir -p /Volumes/Sage_nfs

Mount via Terminal (Optimized):

  sudo mount -t nfs -o vers=3,tcp,rsize=1048576,wsize=1048576,noresvport 192.168.8.108:/mnt/hd1/sage_nfs /Volumes/Sage_nfs

GUI connection: Press Command + K in Finder and enter nfs://192.168.8.108/mnt/hd1/sage_nfs.

Linux Client (Ubuntu/Debian)

Install NFS client packages:

  sudo apt install nfs-common

Create mount point and mount:

  sudo mkdir -p /mnt/sage_nfs
sudo mount -t nfs -o vers=3,tcp,rsize=1048576,wsize=1048576 192.168.8.108:/mnt/hd1/sage_nfs /mnt/sage_nfs

Windows Client (Windows 11/10 Pro)
Windows requires the "Services for NFS" feature enabled.
1. Open Turn Windows features on or off, check Services for Client for NFS, and click OK. Restart if prompted.
2. Open PowerShell or Command Prompt and mount the share to a drive letter:

  mount -o nolock,sec=sys 192.168.8.108:/mnt/hd1/sage_nfs Z:

Part 3: Performance Tuning & Optimization
To maximize network throughput and file transfer speeds over a Gigabit local network, apply the following tweaks.

Increase Buffer Sizes (rsize & wsize) Default NFS block sizes are often small (32KB or 64KB). Bumping them up to 1MB (1048576) significantly reduces network packet overhead during large file transfers:

Add rsize=1048576,wsize=1048576 to your client mount command options.

Force TCP Protocol
Ensure TCP is explicitly specified (tcp) rather than UDP. TCP provides better throughput and stability for large data streams.
Filesystem Mount Options on Debian (/etc/fstab)
If /mnt/hd1 is a dedicated data partition on your Debian server, optimize its internal mount options by adding noatime:

   /dev/sdX1  /mnt/hd1  ext4  defaults,noatime,nodiratime  0  2

noatime: Prevents the OS from writing access timestamps every time a file is read, reducing unnecessary disk I/O.

How to achieve zero-copy streaming from hyper and h3-quinn into a Wasmtime Wasm component via wasi:http?

Josh Klein — Mon, 27 Jul 2026 09:07:08 +0000

Hello everyone,

I am currently building a high-performance API gateway that integrates business logic components—implemented via WASI and running within Wasmtime—as HTTP/TCP/QUIC handlers. I am exploring the best design approach to achieve a zero-copy data path from the upstream network layer—specifically hyper for HTTP/1.x and HTTP/2, and h3-quinn (based on Quinn) for HTTP/3—to the wasi:http guest environment.

Given that:

hyper and h3-quinn each manage their own internal buffer pools (e.g., bytes::Bytes), asynchronous read/write streams, and frame decoders.

Wasmtime's wasmtime-wasi-http implements the wasi:http (WASIp2) specification, which relies on resource types such as InputStream and OutputStream.

I aim to minimize memory copying and CPU overhead when passing large request bodies or streaming responses across the sandbox boundary.

For those experienced with bridging I/O between the host and guest in Wasmtime, I have a few architectural questions:

Buffer ownership and memory mapping: How can host-side bytes::Bytes (from hyper or h3-quinn) be mapped or bridged into Wasm linear memory (and vice versa) without requiring a CPU-based memcpy? Does Wasmtime's resource streaming support direct memory views, or are we essentially limited to copying data chunks via guest memory pointers?
Adapting stream abstractions: hyper uses http_body_util::combinators / http_body::Body, h3 uses its own stream primitives, while wasi:http uses wasi:io/streams. What is the idiomatic way to efficiently adapt these asynchronous streams on the host side (i.e., within the wasmtime-wasi-http handler implementation) without blocking the tokio runtime?
Backpressure propagation: How can backpressure signals be correctly propagated from the Wasm guest (e.g., when the guest's InputStream is consuming data slowly) all the way back to the Quinn congestion controller or Hyper connection pool, thereby avoiding unbounded buffering on the host side?

If anyone has built similar high-performance gateway, proxy, or service mesh architectures using Wasmtime and wasi:http, I would greatly appreciate it if you could share architectural patterns, code references, or insights regarding current limitations.

Many thanks!

How to Design an Industrial-Grade Edge Gateway (And Avoid the Rust Deadlock Trap)

Josh Klein — Fri, 10 Jul 2026 16:53:19 +0000

🎯 Core Architectural Philosophy

"Keep data moving through memory, delegate persistence to the center; the edge does the heavy lifting, the center does the thinking."

The fundamental rule of this architecture is the absolute segregation of the Data Plane and the Control Plane. The edge gateway pursues an absolute $O(1)$ in-memory computing model with zero local disk I/O. All complex states, business logic syncing, and heavy data persistence are delegated to the central management engine asynchronously or via on-demand up-streaming.

🏗️ Architectural Overview

                      [ Client HTTPS Request ]
                                 │
                                 ▼ (with SNI Domain)
┌─────────────────────────────────────────────────────────────┐
│ 1. TLS Termination Layer (In-Memory O(1) Cert Lookup)       │
│    ➔ Misses are synced via global network stream;           │
│      NEVER read from a local disk.                          │
└─────────────────────────────────────────────────────────────┘
                                 │
                                 ▼ (Decrypted Cleartext HTTP Request)
┌─────────────────────────────────────────────────────────────┐
│ 2. Risk & Billing Gatekeeper (DashMap Segmented Locks)       │
│    ➔ Local atomic accumulation (fetch_add),                 │
│      zero blocking remote RPCs.                             │
└─────────────────────────────────────────────────────────────┘
                                 │
                                 ▼ (Security Interception Passed)
┌─────────────────────────────────────────────────────────────┐
│ 3. Sandbox Execution Layer (Wasmtime Engine)                │
│    ➔ Deserializes central AOT pre-compiled machine-code     │
│      snapshots with zero cold-start latency.                │
└─────────────────────────────────────────────────────────────┘
                                 │
          ┌──────────────────────┴──────────────────────┐
          ▼ (Asynchronous Data Stream)                  ▼ (Synchronous Response)
┌───────────────────────────────────┐         ┌───────────────────────────────────┐
│ 4. Bypass Logging Layer           │         │ 5. Response Output Layer          │
│    (Lock-Free Ring Buffer)        │         │                                   │
│    ➔ Flushed directly to Kafka    │         │    ➔ Blazing fast turnaround      │
│      via network streams.         │         │      back to the client.          │
└───────────────────────────────────┘         └───────────────────────────────────┘

🛠️ Deep Dive: The 4 Core Solutions

Atomic Billing Accumulation: Why we aren't afraid of data loss

The Core Logic: Metrics and billing data are flushed to the central infrastructure in batches every 10 seconds via network streams. If an edge node experiences a catastrophic hardware crash, the theoretical worst-case scenario is losing just a few cents worth of transaction metrics for a handful of tenants within that 10-second window. We trade a highly acceptable, microscopic precision loss for 99.999% gateway throughput and rock-bottom P99 latency.
Advanced Resilience (mmap / Shared Memory): The memory counters are instantiated within the operating system's shared memory (shm/mmap). If the gateway process panics or crashes, a system daemon spins up a new instance in milliseconds. The new process instantly re-attaches to the existing shared memory space, resulting in zero data loss (only a total bare-metal power failure would wipe it).

TLS Certificates: Fitting millions of certs into edge nodes

Lazy Loading in Memory: When the edge gateway boots up, it loads zero SSL/TLS certificates into its configuration. Upon receiving a client's TLS handshake containing the SNI, it performs an $O(1)$ memory lookup. On a cache miss, it asynchronously fetches the cert from a high-speed, distributed data-center KV store and caches it in memory for subsequent requests.
Keyless SSL: For enterprise clients where private keys cannot leave on-premise infrastructure, the edge nodes store only the public certificates. During the TLS handshake, cryptographic signatures are calculated by sending brief, secure RPC queries to the client’s private key server, finalizing the handshake securely.

Sandbox Isolation: Executing custom tenant code in < 1ms

AOT Pre-compiled Snapshots: Runtime calls to functions like compile_wasm() are strictly prohibited on the data plane. When a user uploads custom edge code, the control plane immediately pre-compiles it via AOT (Ahead-of-Time) into machine code optimized for target architectures (AMD64/ARM64). The edge gateway simply streams and deserializes this snapshot (deserialize()), eliminating compilation overhead entirely.
Two-Tier Caching (L1 Memory + L2 Local Area KV): The gateway utilizes concurrent structures (like Rust’s DashMap) to manage hot code modules. It leverages an LRU cache pool to recycle sanitized sandbox instances, compressing cold-start latencies down to microseconds.

High-Throughput Logging: Writing logs at hundreds of thousands of RPS

Lock-Free Memory Queues + Network Streams (Logpush): The gateway’s execution context pushes raw logs into a lock-free ring buffer and terminates the client request immediately. Dedicated background threads periodically flush these buffers over UDP or gRPC to remote telemetry pipelines like Kafka or ClickHouse. The gateway process never touches local persistent disk storage.
Cloud-Native stdout Redirection: By using asynchronous, non-blocking configurations in tracing frameworks, logs are written straight to standard output (stdout), where they are immediately drained away by external daemon utilities like FluentBit, Vector, or Logstash.

⚠️ High-Risk Architectural Boundaries (Bug Mitigation)

🚨 Risk 1: Cold Domain Flood Attacks leading to Out-Of-Memory (OOM)

The Scenario: Malicious actors forge millions of non-existent domain requests targeting the edge gateway. These domain misses bypass the internal cache, overwhelm the central KV lookup clusters, and clutter the edge node's memory with useless lookup states.
Mitigation A (Negative Caching): For domains unrecognized by the central directory, the gateway records a temporary (Domain, NotFound) placeholder in its cache, proactively rejecting duplicate lookups for a sliding 5-second interval.
Mitigation B (Pre-Distributed Bloom Filters): The control plane periodically generates a highly compressed Bloom Filter representing all legitimate customer domains and broadcasts it to all edge nodes. Incoming requests are filtered against this lightweight, in-memory array. Non-existent domains are dropped immediately at the edge.

🚨 Risk 2: The Infamous Rust DashMap Deadlock Trap

The Scenario: Within the exact same execution scope/thread, a read lock guard (Ref) on a DashMap remains active while the code simultaneously attempts a write or modification operation (insert/remove) on the very same map shard.
Mitigation: Enforce strict lexical block scoping {} to precisely control the lifecycle of map.get() return handles, or explicitly trigger an immediate drop(read_guard) before calling mutating operations.

📝 Architectural Takeaways

"Data consistency isn't a game of 'the stronger the better'. It's a game of 'the weaker the better', as long as it satisfies business constraints."

"Never force an edge gateway to act like a storage engine. Its destiny is to forward traffic at maximum velocity, and to produce telemetry at the lowest possible cost."

This architectural blueprint mirrors the low-level philosophies utilized by modern Content Delivery Networks and Edge Compute infrastructures like Cloudflare and Fastly. What are your thoughts on building completely diskless data planes? Let's discuss in the comments below! 🦀⚡