In this article
  1. The tyranny of the physical boundary
  2. Enter the Grid Mesh
  3. Erasure Coding beyond the drive bay
  4. When a Datacenter goes dark
  5. Cloud NAS and the magic of "Ghost Sync"
  6. Why build this in user-space?

The Tyranny of the Physical Boundary

For decades, enterprise storage has relied on RAID (Redundant Array of Independent Disks) to protect data from hardware failure. It works brilliantly, but it comes with a massive, implicit constraint: the hard drives must be plugged into the same physical machine. The PCIe lanes and SAS controllers require physical proximity.

This means if your server's motherboard fries, or the rack loses power, or the datacenter loses its internet uplink, your data goes offline. To solve this, the industry invented replication—copying the entire RAID array to a second datacenter. If you have 100TB of data, you buy 200TB of hard drives, plus the RAID parity overhead, pushing your physical footprint closer to 250TB.

Traditional RAID + Replication

Confined & Duplicated

A file is broken into parity chunks across 6 drives in Server A. To protect against Server A failing, the entire assembled file is copied over the internet to Server B. You pay for the data twice.

Husk Grid Mesh EC

Distributed & Shattered

A file is broken into 6 mathematical chunks. Chunk 1 and 2 go to New York. Chunk 3 and 4 go to London. Chunks 5 and 6 go to Tokyo. You only pay for 1.5x the storage, and any location can burn down without data loss.

To break the tyranny of the server chassis, we had to move the parity math out of the kernel's RAID controllers and into a user-space application that understands networking. That application is the Husk Enterprise Sidecar.

Enter the Grid Mesh

The Husk Sidecar is an event-driven companion process written in Rust that attaches to the core Husk daemon via a Unix Domain Socket (UDS). When the core engine needs to read or write, it hands the request to the sidecar. If you hold an Enterprise license, the sidecar activates the Grid Mesh.

The Grid Mesh is a peer-to-peer TCP network layer that tunnels read and write requests directly between different Husk servers, completely bypassing the need for heavy VPNs, NFS mounts, or third-party transfer tools like Aspera.

4
Application open()
A user in Los Angeles double clicks a file in their Finder/Explorer.
user space
3
Husk Core (fanotify)
Intercepts the read. Realizes the data blocks aren't local. Asks the Sidecar for help.
kernel/core
2
Sidecar Grid Mesh
Looks up the target node. Opens a raw TCP socket to 0.0.0.0:9000 in Chicago.
sidecar
1
Remote Storage Node
Chicago sidecar receives the REQUEST_READ header and streams the binary tape data straight back to LA.
network

Because the connection is negotiated locally via the sidecar, the application in Los Angeles just thinks it's reading a slightly slow local hard drive. It has no idea the bytes are streaming over a TCP tunnel from a tape autoloader in Illinois.

Erasure Coding Beyond the Drive Bay

Routing remote reads is cool, but Grid Mesh becomes practically magical when combined with software-defined Erasure Coding (EC). By default, the Husk Sidecar uses a 4+2 Reed-Solomon Erasure Coding matrix utilizing Galois Field (2^8) math. This means every 4 Megabytes of data is chopped up and mathematically encoded into 6 Megabytes (4 data shards, 2 parity shards).

In a standard setup, those 6 shards are written to 6 different hard drives in a single server (like /dev/sda through /dev/sdf). But because the sidecar controls both the EC math and the Grid Mesh networking, we can change the destination paths from local block devices to Grid URIs.

// Inside the Husk Sidecar: The EC Cell definition pub struct Cell { pub cell_id: u32, pub virtual_uuid: String, // Instead of local drives, we define mesh targets pub drives: Vec<String>, } // A Multi-Site EC Cell configuration let cell = Cell { cell_id: 1, virtual_uuid: "GLOBAL_POOL_1".to_string(), drives: vec![ "husk-grid://ny-server-01".into(), "husk-grid://ny-server-02".into(), "husk-grid://ldn-server-01".into(), "husk-grid://ldn-server-02".into(), "husk-grid://tyo-server-01".into(), "husk-grid://tyo-server-02".into(), ], is_spinning: true, };

When you save a file, the sidecar encodes it in RAM, then spins up asynchronous threads to write the resulting shards concurrently over the Grid Mesh to the target servers. Because it uses tokio::io::copy_bidirectional, the throughput is limited only by your internet pipe, not disk I/O.

When a Datacenter Goes Dark

The true power of 4+2 Erasure Coding is that you only need any 4 of the 6 shards to reconstruct the original data perfectly. This is where the physical geometry of the datacenter ceases to matter.

Let's say a fiber line gets cut and your entire London datacenter drops offline. London held shards #3 and #4. What happens when a user in New York tries to open the file?

01
Grid Tunnel Timeouts
The sidecar attempts to pull all 6 shards. The connections to ldn-server-01 and 02 fail.
02
Degraded Read Fallback
The sidecar successfully retrieves shards 1 and 2 (from New York) and shards 5 and 6 (from Tokyo). It has 4 pieces.
03
Reed-Solomon Math to the Rescue
The sidecar feeds the 4 surviving shards into the EC Engine in RAM. The math reconstructs the missing London data perfectly on the fly.
04
Application Proceeds
The file opens. The user never knows London fell off the map. When London comes back online, a HEAL_CHUNK mesh command automatically resyncs the missing data.

Cloud NAS and the Magic of "Ghost Sync"

For Multi-Site EC to feel like a true global filesystem, users in every location need to actually see the files in their local operating systems. You can't ask a video editor in Tokyo to memorize command line paths for files that were saved in New York.

This brings us to Ghost Sync. When the core Husk database updates (a new file is archived), the sidecar intercepts the CATALOG_UPDATE event. It immediately queries SQLite for the file's metadata and broadcasts a JSON payload across the Grid Mesh to every other node in the cluster.

// The JSON payload broadcasted across the Grid Mesh { "mesh_action": "SYNC_DB_ROW", "file_path": "/archive/projects/2026/film_v1.mov", "version": 1, "tape_uuid": "GLOBAL_POOL_1", "payload_size": 15400000000 }

When the Tokyo node receives this payload, it doesn't download the 15GB file. Instead, it utilizes an obscure but brilliant POSIX system call to materialize a "Ghost File" (Sparse Stub) locally.

// How HuskSidecar creates a Ghost File in Rust if let Ok(file) = std::fs::OpenOptions::new().write(true).create(true).open(&header.target) { let fd = std::os::unix::io::AsRawFd::as_raw_fd(&file); let size = header.payload_size.unwrap_or(0); // MAGIC: Set the logical EOF marker without writing actual blocks to disk unsafe { libc::ftruncate(fd, size as libc::off_t); } // Mark it so the local Fanotify daemon knows to intercept it xattr::set(&header.target, "trusted.husk.status", b"stubbed").unwrap(); }

The libc::ftruncate function creates a file that reports to the operating system as being exactly 15GB large, but it consumes 0 bytes of physical disk space. Within milliseconds of a file being saved in New York, a 15GB Ghost File materializes in the Tokyo user's Finder window.

To the Tokyo user, the file is right there on their desktop. When they double-click it, the local Husk core intercepts the read, hands it to the sidecar, and the Grid Mesh securely tunnels the missing data chunks over TCP. A truly serverless, geometry-agnostic Cloud NAS.

Why Build This in User-Space?

Could you do this with a distributed block device like DRBD, or a cluster filesystem like Ceph? Yes. But those operate entirely in kernel space. If a kernel module encounters a networking timeout or a malformed packet during a cluster sync, the entire kernel panics and your server crashes.

01 — Resilience
Crash-proof Networking
Because the Grid Mesh runs in an asynchronous Rust user-space runtime (Tokio), a dropped connection just returns an Err(). The daemon logs it, falls back to Reed-Solomon reconstruction, and keeps running. No kernel panics.
02 — Security
Zero Custom Mounts
Since Husk relies on standard POSIX commands like ftruncate and Extended Attributes, there are no proprietary kernel mounts. Your data resides on standard XFS or Ext4 filesystems, fully accessible even if Husk is turned off.
03 — Speed
Zero-Copy Tunneling
By passing a Unix Domain Socket from the core directly into a TCP Stream, the sidecar achieves near-line rate speeds. Data flows from the remote disk, over the wire, straight to the application buffer.
04 — Flexibility
Hardware Agnostic
A Grid target doesn't care what's behind it. New York could be writing to NVMe arrays, while London is writing to LTO-9 Tape Autoloaders. The mesh treats them all as generic byte-sinks.

By decoupling the physical location of the storage media from the logical presentation of the filesystem, the Grid Mesh turns scattered servers across the globe into a single, cohesive, self-healing organism. Your data isn't just protected against a drive failure anymore—it's protected against geography itself.