[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-76086":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":23,"hasPages":23,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":37,"readmeContent":38,"aiSummary":39,"trendingCount":16,"starSnapshotCount":16,"syncStatus":14,"lastSyncTime":40,"discoverSource":41},76086,"openlake","openlake-project\u002Fopenlake","openlake-project","High performance storage system for LLM Inference and GPU Training. Feed your GPUs at blazing fast speeds","https:\u002F\u002Ftheopenlake.com",null,"Rust",1325,194,2,50,0,143,698,939,429,19.87,"Apache License 2.0",false,"main",[26,27,28,29,30,31,32,33,34,35,36],"blackwell","gpt","gpu","high-performance","llm","llm-training","model-serving","rdma","rust","storage","throughput","2026-06-12 02:03:39","\u003Cdiv align=\"center\">\n\n\u003Cpicture>\n  \u003Csource media=\"(prefers-color-scheme: dark)\"  srcset=\"https:\u002F\u002Ftheopenlake.com\u002Fassets\u002Fwordmark.png\">\n  \u003Cimg alt=\"OpenLake\" src=\"https:\u002F\u002Ftheopenlake.com\u002Fassets\u002Fwordmark-on-light.png\" width=\"340\">\n\u003C\u002Fpicture>\n\n### The shortest path from NVMe to GPU memory.\n\nS3 wire compatible distributed object storage, written in Rust on `io_uring`, for the workloads that move terabytes between storage and GPUs.\n\n[![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-Apache--2.0-blue.svg)](LICENSE)\n[![Rust](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Frust-1.91%2B-orange.svg)](rust-toolchain.toml)\n[![Status](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatus-early%20development-yellow.svg)](#project-status)\n[![Web](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fweb-theopenlake.com-1d4ed8.svg)](https:\u002F\u002Ftheopenlake.com)\n\n[Website](https:\u002F\u002Ftheopenlake.com) · [Comparison](https:\u002F\u002Ftheopenlake.com\u002Fcompare.html) · [Architecture](#architecture) · [Quickstart](#quickstart)\n\n\u003C\u002Fdiv>\n\n---\n\n## What is OpenLake?\n\nOpenLake is an object store for AI infrastructure. Training and inference clusters spend a large fraction of their wall clock time moving bytes from storage into GPU memory, and most object stores put the host CPU, the page cache, and several userspace copies directly in that path. OpenLake is a clean room, S3 wire compatible implementation that takes the opposite stance:\n\n- **`io_uring`, thread per core.** Built on the [`compio`](https:\u002F\u002Fgithub.com\u002Fcompio-rs\u002Fcompio) completion based runtime. One runtime per core, pinned, no work stealing. The HTTP frontend and the storage engine run on the *same* thread, so a request never crosses a core boundary on the hot path.\n- **No CPU detour on the data path.** The design goal: GPUDirect Storage and RDMA so bytes flow NVMe → NIC → peer NIC → GPU VRAM without staging through host memory or the page cache. Not built yet; see [Architecture](#architecture).\n- **MinIO compatible on disk.** Objects are laid out in the `xl.meta` format, so an existing MinIO or RustFS deployment's disk layout is intelligible to OpenLake, and vice versa.\n- **Erasure coded, distributed.** SIMD Reed Solomon, fixed size erasure sets, deterministic placement. The durability model operators already know, with a much smaller runtime underneath it.\n\nToday OpenLake runs as a standard S3 endpoint you can point any AWS SDK at.\n\n## Key features\n\n| | |\n|---|---|\n| **S3 wire compatible** | SigV4 authentication; bucket and object CRUD; batch delete; `ListObjects` v1 and v2; multipart upload; multi version objects. Works with the AWS CLI, `boto3`, the `aws-sdk-*` crates, `mc`, and other S3 clients. |\n| **`io_uring` runtime** | [`compio`](https:\u002F\u002Fgithub.com\u002Fcompio-rs\u002Fcompio) plus [`cyper`](https:\u002F\u002Fgithub.com\u002Fcompio-rs\u002Fcyper) \u002F `cyper-axum`: hyper's HTTP\u002F1.1 (and HTTP\u002F2 for the cluster plane) on a completion based runtime. One pinned runtime per CPU, `SO_REUSEPORT` listeners, no tokio runtime spun up. |\n| **SIMD erasure coding** | [`reed-solomon-simd`](https:\u002F\u002Fcrates.io\u002Fcrates\u002Freed-solomon-simd) (FFT algorithm; SSSE3 \u002F AVX2 \u002F NEON auto detected). Shards are streamed stripe by stripe, so peak RAM per in flight PUT is one stripe, not the whole object. |\n| **MinIO `xl.meta` layout** | v1.x metadata format. Objects up to 128 KiB are inlined directly into `xl.meta`; larger ones are written as Reed Solomon shards across the set. |\n| **Distributed by erasure sets** | A flat pool of disks is partitioned into fixed width sets at startup; every `(bucket, key)` hashes (SipHash) to exactly one set; write all, read any quorum within the set. Operators shape the failure profile by ordering nodes and choosing the set width and parity count. |\n| **mTLS HTTP\u002F2 cluster plane** | Every node is both a client and a server on the inter node RPC plane; HTTP\u002F2 negotiated over mutual TLS (required for any cluster of more than one node). |\n| **Distributed locking** | A `dsync` style lock service serializes multipart and metadata mutations across nodes. |\n| **One static binary** | `phenomenald` (the storage node) and `phenomenal` (a local diagnostic and benchmark CLI). No external coordinator, no JVM, no GC. |\n\n## Architecture\n\nA request today takes this path:\n\n```\nS3 client ──HTTP──▶ cyper-axum  (on compio \u002F io_uring)\n                       │  SigV4 verify\n                       ▼\n                     Engine  ──▶  erasure set  ─┬─▶  local disk   (phenomenal_io, io_uring)\n                       │     (SipHash route)     └─▶  peer node    (HTTP\u002F2 + mTLS RPC)\n                       ▼\n                    xl.meta  +  Reed Solomon shards   \u002F   inlined body\n```\n\nThe data path we are building toward, where the CPU is not in the loop:\n\n```\nNVMe ──io_uring──▶ NIC ──RDMA · RoCEv2──▶ NIC ──GPUDirect──▶ GPU memory ──decompress──▶ CUDA kernel\n```\n\n### Workspace\n\n```\ncrates\u002F\n├── phenomenal_io\u002F        local FS I\u002FO on io_uring · xl.meta encode\u002Fdecode · on disk layout · RPC backend client\n├── phenomenal_storage\u002F   the engine · erasure coding · cluster topology and set routing · dsync locking · put\u002Fget\u002Flist\u002Fmultipart\n├── phenomenal_server\u002F    S3 HTTP frontend (cyper-axum on compio) · SigV4 · inter node RPC server · lock server   →  `phenomenald`\n└── phenomenal_cli\u002F       local diagnostic and microbenchmark client (drives a LocalFsBackend directly)            →  `phenomenal`\n```\n\n> The crate namespace is still `phenomenal_*`: *OpenLake* is the project name, `phenomenal` was the working codename and remains the crate and binary prefix for now.\n\n## Quickstart\n\nRequires **Rust 1.91+** (pinned in `rust-toolchain.toml`). Linux gives you the `io_uring` driver; macOS builds and runs on the `kqueue` driver for development.\n\n```sh\ngit clone \u003Crepo-url> openlake && cd openlake\ncargo build --release --workspace\n```\n\nWrite a node config. The full schema, and a multi node example, are documented at the top of [`crates\u002Fphenomenal_server\u002Fsrc\u002Fconfig.rs`](crates\u002Fphenomenal_server\u002Fsrc\u002Fconfig.rs):\n\n```toml\n# node0.toml: single node dev instance\nself_id              = 0\ndata_dirs            = [\"\u002Fvar\u002Flib\u002Fopenlake\u002Fdisk0\", \"\u002Fvar\u002Flib\u002Fopenlake\u002Fdisk1\", \"\u002Fvar\u002Flib\u002Fopenlake\u002Fdisk2\"]\ns3_addr              = \"0.0.0.0:9000\"\nrpc_addr             = \"0.0.0.0:9100\"\nset_drive_count      = 3\ndefault_parity_count = 1            # EC[2+1] within the set: tolerates 1 disk loss\nregion               = \"us-east-1\"\n\n[[credentials]]\naccess_key = \"openlakeaccesskey\"\nsecret_key = \"openlakesecretkey\"\n\n[[nodes]]\nid         = 0\nrpc_addr   = \"127.0.0.1:9100\"\ndisk_count = 3\n```\n\nRun the node, then talk to it with any S3 client:\n\n```sh\ncargo run --release -p phenomenal_server -- --config node0.toml\n# or:  .\u002Ftarget\u002Frelease\u002Fphenomenald --config node0.toml\n\nexport AWS_ACCESS_KEY_ID=openlakeaccesskey\nexport AWS_SECRET_ACCESS_KEY=openlakesecretkey\n\naws --endpoint-url http:\u002F\u002Flocalhost:9000 s3 mb s3:\u002F\u002Fdemo\naws --endpoint-url http:\u002F\u002Flocalhost:9000 s3 cp .\u002Fcheckpoint.safetensors s3:\u002F\u002Fdemo\u002F\naws --endpoint-url http:\u002F\u002Flocalhost:9000 s3 ls s3:\u002F\u002Fdemo\u002F\n```\n\n`phenomenal` (the CLI crate) is a **local** tool: it drives a `LocalFsBackend` directly for diagnostics and microbenchmarks (`phenomenal bench --n 100000 --size 4096`), not an S3 client.\n\n## Contributing\n\nIssues and pull requests are welcome. Before sending a PR:\n\n```sh\ncargo build  --workspace\ncargo test   --workspace\ncargo clippy --workspace --all-targets\ncargo fmt    --all\n```\n\n`rustfmt` and `clippy` settings live in `.rustfmt.toml` and `rust-toolchain.toml`; the bar is a clean `clippy` and `fmt`.\n\n## License\n\n[Apache License 2.0](LICENSE).\n\n---\n\n\u003Cdiv align=\"center\">\n\u003Csub>\u003Ca href=\"https:\u002F\u002Ftheopenlake.com\">theopenlake.com\u003C\u002Fa>\u003C\u002Fsub>\n\u003C\u002Fdiv>\n","OpenLake 是一个专为GPU工作负载设计的高性能存储解决方案，能够以极快的速度将数据从存储传输到GPU内存。该项目采用Rust语言编写，并基于`io_uring`技术构建，确保了单个核心上运行的请求不会跨越核心边界，从而减少CPU开销并提高数据传输效率。此外，它支持GPUDirect Storage和RDMA技术（虽然还在开发中），旨在实现从NVMe直接到GPU显存的数据流动路径，避免通过主机内存或页面缓存进行中转。OpenLake兼容S3协议及MinIO磁盘布局格式，易于集成现有基础设施，同时具备分布式与纠删码特性，适用于大规模AI模型训练和推理场景中的高效数据访问需求。","2026-06-11 03:54:25","CREATED_QUERY"]