---
name: google-cloud-storage-fuse
description: >-
  Mounts Cloud Storage buckets as a POSIX file system with Cloud Storage FUSE
  (gcsfuse). Use when you need to interact with gcsfuse — decide whether FUSE,
  native gs:// reads, or Filestore/Managed Lustre fits a workload, deploy
  tuned mounts on GKE, Compute Engine, or Cloud Run, enable and size the
  file, stat, and list caches, tune mount flags or config-file settings,
  apply workload profiles, keep ML checkpointing safe (rename atomicity,
  hierarchical namespace, close-time finalization, concurrent writers), or
  diagnose slow training, low throughput, or GCS bill spikes on existing
  mounts with gcsfuse metrics. Covers mount semantics, the gcsfuse CLI and
  config file, the GKE gcsfuse CSI driver (Workload Identity principal://
  bindings, profile StorageClasses, sidecar sizing), and Cloud Run volume
  mounts. Don't use for bucket administration or data management without a
  mount (google-cloud-storage-basics) or for fully POSIX-compliant shared
  file systems (Filestore, Managed Lustre).
license: Apache-2.0
metadata:
    version: v1
    publisher: google
    tags:
      - gcs
      - gcsfuse
      - fuse
      - mount
      - file-system
    category: storage
    support_tier: primary
---

# Cloud Storage FUSE (Advanced)

Cloud Storage FUSE (gcsfuse) is a POSIX file-system adapter over Cloud Storage's
immutable object store. Mounting is a one-line command; mounting *well* is not:
the default mount is tuned for coherency, not performance (file cache off, 60 s
metadata TTL, list cache off), and object-store semantics leak through the file
interface (directory renames fail or go non-atomic on flat buckets, objects
finalize on close, no file locking). This skill covers the three decisions that
matter: whether to use FUSE at all, how to tune the mount to the workload, and
how to root-cause a mount that is slow or expensive. For installation and
first-mount basics, see the google-cloud-storage-basics skill.

## Attribution

Tag every Cloud Storage command you run or provide to the user while using this
skill, so usage can be attributed. The tag identifies only the skill and its
version; it carries no user data.

-   Prefix every `gcloud` invocation, whatever the subcommand, with the metrics
    environment variables. Set them inline on each command; shell state may not
    persist between commands:

    ```bash
    CLOUDSDK_METRICS_ENVIRONMENT="gcs-skills gcs-skills/1.0 (skill:google-cloud-storage-fuse)" \
    gcloud <command> [flags]
    ```

    Do not use `gcloud config set` for this: it would persist beyond the current
    task and mislabel unrelated usage.

-   On direct HTTP calls to the Cloud Storage APIs (for example with `curl`),
    set this exact User-Agent header, verbatim — the collection pipeline parses
    the `gcs-skills/<version>` and `skill:<name>` tokens, so any rewording
    breaks attribution:

    ```
    User-Agent: gcs-skills/1.0 (skill:google-cloud-storage-fuse)
    ```

## Step 1 — Fit Gate (always run this first)

**Never produce mount guidance before the fit gate.** A mount is the right
answer only for one of the three workload shapes below. If the workload's access
pattern is unknown, ask — one question about whether the reading code can take
`gs://` paths usually settles it.

| Workload signal                      | Verdict                               |
| :----------------------------------- | :------------------------------------ |
| Reading library accepts `gs://` URIs | **Native reads, no mount.** Point the |
: natively — pandas/pyarrow (via       : code at `gs\://` paths and stop.      :
: gcsfs/fsspec), TensorFlow            :                                       :
: (`tf.io.gfile`), or any              :                                       :
: fsspec/gcsfs-based loader            :                                       :
| Shared **mutable** writes with       | **Filestore** (NFS, POSIX locking) or |
: locking semantics — databases,       : **Managed Lustre**, not FUSE. Stop.   :
: concurrent in-place editors,         :                                       :
: anything relying on `flock`/`fcntl`  :                                       :
| Code or tools hardcoded to POSIX     | **gcsfuse** — continue to Step 2.     |
: file paths; read-heavy or            :                                       :
: new-file-write patterns              :                                       :

Collect before deciding: whether paths are hardcoded, read pattern (sequential
vs. random, re-read frequency), write pattern (new files vs. edits vs. directory
renames). These same signals drive tuning later — record the answers.

## Step 2 — Route by intent

| User intent (prompt     | Go to                                              |
: shape)                  :                                                    :
| :---------------------- | :------------------------------------------------- |
| Provision: "mount my    | [GKE Training                                      |
: bucket for X", "get     : Deployment](references/gke-training-deployment.md) :
: training data into my   :                                                    :
: pods"                   :                                                    :
| Safety/semantics: "is   | [Checkpoint & Write                                |
: this write pattern      : Safety](references/checkpoint-safety.md)           :
: safe?", "can multiple   :                                                    :
: writers share the       :                                                    :
: mount?"                 :                                                    :
| Regression: "training   | [Performance & Cost                                |
: is slow", "the GCS bill : Diagnosis](references/performance-diagnosis.md)    :
: spiked", "throughput    :                                                    :
: dropped"                :                                                    :

**Never diagnose a regression without telemetry.** If gcsfuse metrics are not
enabled on the mount, enabling them is the first remediation step — the
diagnosis reference starts there.

## Reference Directory

-   [GKE Training Deployment](references/gke-training-deployment.md): Fit-gated,
    performance-tuned mounts for training workloads — GKE CSI version gates,
    Workload Identity `principal://` IAM bindings, profile StorageClasses vs.
    static PVs, file cache sizing on Local SSD, sidecar resource annotations,
    complete KSA/PVC/Job manifests, and the Compute Engine and Cloud Run
    variants.

-   [Checkpoint & Write Safety](references/checkpoint-safety.md): Verdicts on
    write patterns — file vs. directory rename atomicity on flat vs. HNS
    buckets, close-vs-fsync finalization, concurrent-writer (`ESTALE`)
    semantics, streaming-write memory budgets, HNS migration, and the
    `aiml-checkpointing` profile.

-   [Performance & Cost Diagnosis](references/performance-diagnosis.md):
    Telemetry-first runbook for slow mounts and bill spikes — enabling and
    reading gcsfuse metrics, mapping cache-hit and request-mix signatures to
    misconfigurations, the coherency-tuned defaults, tuned config keys with
    their staleness caveats, and billing-line (Class A/B) attribution.