An HDD-native distributed filesystem, designed from the block layer up.
Leil treats SMR drives as first-class citizens, not as an afterthought to flash-optimized storage systems.
Three layers, each with a single job.
POSIX VFS interface
Leil mounts like any Linux filesystem. Directories, inodes, file permissions, rename atomicity, and fsync semantics all work exactly as expected. Your training code does not need modification.
Coordination layer
Data is distributed across nodes using consistent hashing. Metadata is replicated on 3 nodes for durability. The coordination layer handles node membership, failure detection, and rebalancing transparently.
SMR write scheduler
The write scheduler converts the random write pattern of a general-purpose filesystem into the sequential band-ordered writes that SMR drives require. It maintains per-band write pointers and a coalescing buffer that aggregates concurrent writes before issuing them as a single sequential stream.
The engineering problem at the core of SMR adoption.
SMR drives use shingled magnetic recording: each track is written so it overlaps the outer edge of the track below it. This increases track density by 25 to 30 percent compared to conventional magnetic recording, which is where the 2.5x capacity advantage originates.
The catch: each track belongs to a write band, and writes within that band must be sequential. If your filesystem issues a random small write anywhere in a band, the drive must read the entire band into a cache buffer, modify it, and rewrite the whole band sequentially. This is called the "read-modify-write" penalty, and it reduces effective throughput by 60 to 80 percent compared to the drive's rated sequential write speed.
Generic filesystems (ext4, XFS, Btrfs) were designed for random-write capable drives. They issue writes wherever their allocation maps point, constantly triggering band-level read-modify-write cycles on SMR drives. The drives run at a fraction of their rated speed, making SMR look slower than conventional drives.
Erasure coding over replication for maximum capacity.
Leil uses Reed-Solomon erasure coding (configurable 4+2 or 8+2) rather than replication to maximize usable capacity per drive. A 4+2 configuration means 6 drives hold what was originally 4 drives worth of data, with any 2 drives able to fail simultaneously without data loss. This yields 66% storage efficiency vs 33% for triple replication.
Stripe width is tuned to SMR band size to maximize both write efficiency and rebuild throughput after a drive failure. Metadata is separately replicated on 3 nodes for durability, keeping metadata operations fast even when data nodes are being rebuilt.
Failure domains are drive-bay-level by default, meaning a bay backplane failure or power supply failure counts as one failure event, not multiple simultaneous drive failures.
Full POSIX semantics. Your tools work unchanged.
Directories and inodes
Full hierarchical namespace. Symlinks, hardlinks, extended attributes, directory permissions all work.
Rename atomicity
Atomic rename across the cluster. Safe for checkpoint write patterns that use temp file + rename.
fsync semantics
fsync() guarantees data durability to the cluster. Required for safe checkpoint commits.
Lock-free sequential reads
Sequential read paths are lock-free. Large read-ahead buffers saturate SMR sequential read bandwidth for training data access.
Framework compatibility
PyTorch DataLoader, HuggingFace Datasets, TensorFlow tf.data, and standard UNIX checkpoint paths work without code changes.
Standard VFS path
The mount point appears as a standard Linux VFS path. Mounts automatically on node restart, survives kernel upgrades.
Numbers from an actual pilot cluster.
12-node pilot, 8 drives per node, 16TB SMR per drive. Internal benchmark, March 2026.
Source: internal benchmark on 12-node pilot configuration, 8x 16TB SMR drives per node, March 2026. Sequential read throughput is network-limited at high node counts. Checkpoint latency measured with torch.save() on a 100GB model state dict.
Ready to benchmark your workload?
We run pilot clusters with early-access partners to validate performance on your specific dataset and checkpoint sizes.