What problem it solves

Applications need shared storage that can be mounted like a local POSIX file system while keeping bulk data in object storage and metadata in a separate database. This enables existing applications, Hadoop workloads, Kubernetes deployments, and S3 clients to use the same storage without changing application code.

Key features

• POSIX-compatible file system interface — The client exposes a POSIX file system that can be mounted locally and used by existing applications. It also supports atomic metadata operations, close-to-open consistency, memory mapping, extended attributes, and file locking.

  Source: README

• Hadoop, Kubernetes, and S3 integration — The client provides interfaces for Hadoop, Kubernetes, and S3-compatible access. This allows the shared storage to be integrated with those environments while retaining the POSIX interface for general applications.

  Source: README

• Shared storage with strong consistency — Multiple clients can read and write the same mounted file system, and confirmed modifications become visible to other mounted clients immediately.

  Source: README

• Flexible data and metadata backends — File data can be stored in supported object storage services or other storage media, while metadata can be stored in Redis, MySQL, SQLite, TiKV, and other supported engines. The implementation divides files into chunks, slices, and blocks before storing them.

  Source: README

• Encryption, locking, and compression — The file system supports encryption in transit and at rest, shared file locks, and compression with LZ4 or Zstandard.

  Source: README

Quick start

Copied verbatim from the project's README.

juicefs mount --no-usage-report

Who it may suit

This may suit teams operating cloud-native applications that need shared POSIX storage across compute environments, including Kubernetes, Hadoop, and containerized workloads.

Topics to discuss

• Which metadata engine trade-offs matter most for a particular deployment?

• How should object storage, caching, and writeback behavior be configured for existing workloads?

• Which community integrations or operational tools would be most useful to improve next?

Written by ReadmeX AI from the project's README, source and public GitHub data; it may contain mistakes.

Read the original README https://github.com/juicedata/juicefs#readme

ReadmeX opened this community for a trending project; it is not run by the project. Maintainers can claim it from the community page.