cloudparts

TigrisFS

A FUSE file system that mounts a Tigris or other S3-compatible bucket as a local directory.

What it is
Object storage
Used for
File storage
Part of
Tool for Tigris
Type
Open source
Made by
Tigris Data
License
Apache 2.0
Facts checked
23 October 2026
Website Source code

What it is

TigrisFS mounts a bucket as a folder on Linux or macOS, so programs that only know files (rsync, ffmpeg, training scripts) can read and write objects. It is a Go program built on FUSE and a fork of GeeseFS, Yandex Cloud’s file system for S3, which is itself a fork of Goofys. Each file is stored as one ordinary object under its own path, with no separate metadata service, so the same data stays readable through the S3 API and any S3 tool. JuiceFS, by contrast, splits files into blocks with names only it understands.

Speed comes from caching and parallelism. Reads and writes go through an in-memory buffer (--memory-limit, 1 GB by default); writes land there first and are flushed to the bucket in the background by a pool of flusher threads (--max-flushers, 16 by default), and file attributes are cached for --stat-cache-ttl (60 seconds by default). It works against any S3-compatible store. Against Tigris it adds POSIX permissions, special files and symlinks, fetches the contents of small files in the same request that lists a directory, and can prefetch a directory’s data into the local Tigris region. Packages for Debian and RPM install a systemd unit, tigrisfs@<bucket>, that mounts a bucket per user or system-wide.

Why teams pick it

  • Files stay ordinary objects under their own names, so the same bucket can be used through the mount and through the S3 API
  • Write-back caching and parallel flushes; Tigris measured 1,630 to 2,802 MiB/s reads and 1,118 to 1,279 MiB/s writes with fio on a 24-core VM
  • Directory listings on Tigris bring small files along in one round trip, which helps workloads with many small files
  • Apache 2.0, with DEB and RPM packages, a systemd unit per bucket and builds for Linux and macOS

Watch out for

  • A file system over HTTP: files not yet cached are slower than a local disk, and FUSE makes one mount hard to share between several users
  • Writes are acknowledged from memory and uploaded later, so a crash or network failure before the flush can lose them; fsync waits for the upload
  • POSIX gaps inherited from GeeseFS: no hard links, no file locking, and no reading a file after it’s deleted while still open
  • Permissions, symlinks and special files are only kept on Tigris; on other S3 services they aren’t restored from listings

More of the Tigris family

What all object storage have in common →Compare side by side →
OCacheOpen sourceToolsA disk-backed cache for objects of any size, from Tigris, that runs as a server, a cluster or a Go library; TAG’s cache layer.TAG (Tigris Acceleration Gateway)Open sourceBuilt on itAn S3-compatible caching proxy you run next to your compute, keeping hot Tigris objects on local NVMe.

How it fits with other technologies

Mount a bucket with a bigger cache and more flushers · bash

# credentials come from ~/.aws, AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY or /etc/default/tigrisfs
mkdir -p ~/mnt/datasets
tigrisfs --memory-limit 4096 --max-flushers 64 --stat-cache-ttl 15m \
  acme-datasets ~/mnt/datasets

cp -r ./run-42 ~/mnt/datasets/checkpoints/      # written back in the background
aws s3 ls s3://acme-datasets/checkpoints/run-42/ # the same files, as objects

# or let systemd mount it, now and at every login
systemctl --user enable --now tigrisfs@acme-datasets

See it in a real stack

No architecture uses TigrisFS yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2015–2026

Goofys, started in 2015, mounted an S3 bucket as what its README calls a “filey system”: performance first and POSIX second, so random writes failed and per-file permissions were faked. In 2021 Yandex Cloud released GeeseFS, a fork aimed at the usual weak spots of S3 file systems, small files and metadata operations, using aggressive parallelism and asynchronous writes. Unlike Goofys it supports read-after-write, partial writes, truncation and fsync.

In December 2024 Tigris showed its buckets mounted in Kubernetes through Yandex’s csi-s3 driver, which runs GeeseFS underneath. On 1 July 2025 it announced TigrisFS, its own fork. The first releases replaced GeeseFS’s bundled AWS SDK, which had known vulnerabilities, upgraded other dependencies, fixed the race conditions the Go race detector found and turned on linting and more tests in CI. Tigris-specific features came on top. Tigris calls it the native file system interface for its storage, aimed at AI workloads whose datasets don’t fit on a local disk.

Why it’s built this way

Fork GeeseFS rather than write a new file system
GeeseFS already performed well with small files and kept one object per file. Tigris chose to fix its security and reliability problems and add features for its own storage.
Keep objects readable
Files stay plain objects under their own names, unlike JuiceFS’s blocks, so the S3 API and the file system can be used on the same data.
Use Tigris’s own API features when available
Standard S3 doesn’t return user metadata in listings, so GeeseFS restores permissions and symlinks only on Yandex’s own storage. TigrisFS supports them on Tigris, and preloads the contents of small files along with a directory listing.

Timeline

  1. 2015

    Goofys, a performance-first S3 file system in Go, first released

  2. 2021

    Yandex Cloud releases GeeseFS, a fork of Goofys

  3. 2024

    Tigris shows GeeseFS mounting buckets in Kubernetes via csi-s3

  4. 2025

    TigrisFS 1.1.0 in April; announced on 1 July

  5. 2026

    Version 1.2.4 released in September

Sources5 · facts checked 23 October 2026

Improve this page on GitHub