Filestore for Managed NFS

Filestore is Google Cloud's fully managed Network File System (NFS) service. It provides shared file storage that can be mounted by multiple Compute Engine VM instances and Google Kubernetes Engine (GKE) pods simultaneously, using the standard NFS protocol (NFSv3). The primary reason Filestore exists is to support legacy applications that require POSIX-compliant shared file systems—applications that cannot be easily refactored to use object storage (Cloud Storage) or block storage (Persistent Disk). Common use cases include:

Filestore is not an object store; it is a file server with a directory hierarchy, symbolic links, and file-level locks (though NFSv3 locking is advisory). It is accessed via NFS mounts, typically using the mount command with options like hard,intr,vers=3,noatime.

Filestore instances are provisioned in a Google-managed tenant project. Each instance has a private IP address (RFC 1918) within a VPC network of your choice. The instance runs an NFS server daemon (likely a custom implementation based on Linux NFS) that exports one or more file shares (called 'volumes'). When a client mounts the share, it uses the NFS protocol to perform remote procedure calls (RPCs) for file operations. The NFS protocol is stateless—the server does not track which clients have which files open; instead, each RPC contains the file handle and offset. This statelessness simplifies crash recovery but means that file locking (if used) requires a separate lock manager (NLM) service. Filestore supports NFSv3 with NLM for advisory locking, but it does not support mandatory locking.

Data is stored on Google's persistent storage backend (likely using Colossus, the same distributed file system that underlies Persistent Disk). Each Filestore instance is replicated synchronously within a single zone (zonal) or across two zones (regional, for higher availability). The performance tier determines the underlying hardware: HDD for capacity-optimized, SSD for performance-optimized, and high-scale SSD for large-throughput workloads. The instance's capacity and throughput are provisioned together—you choose a tier and a capacity (in GiB), and the baseline IOPS and throughput are determined by that capacity. For example, a 1 TiB Basic HDD instance provides 100 MB/s read throughput and 50 MB/s write throughput, while a 1 TiB High Scale SSD instance provides 1.2 GB/s read and 600 MB/s write.

sudo mount -o hard,intr,vers=3,noatime <FILESTORE_IP>:/<SHARE_NAME> /mnt/filestore

To create a Filestore instance using gcloud:

gcloud filestore instances create <INSTANCE_NAME> \
    --zone=<ZONE> \
    --tier=BASIC_SSD \
    --file-share=name=<SHARE_NAME>,capacity=<SIZE>TiB \
    --network=name=<VPC_NAME>,reserved-ip-range=<CIDR>

To mount on a Linux VM:

sudo mkdir -p /mnt/filestore
sudo mount -o hard,intr,vers=3,noatime <FILESTORE_IP>:/<SHARE_NAME> /mnt/filestore

To verify mount:

df -h | grep filestore
# or
mount | grep filestore

To check NFS server exports:

showmount -e <FILESTORE_IP>

To list active NFS mounts on client:

nfsstat -m

apiVersion: v1
kind: PersistentVolume
metadata:
  name: filestore-pv
spec:
  capacity:
    storage: 1Ti
  accessModes:

- ReadWriteMany
  nfs:
    path: /<SHARE_NAME>
    server: <FILESTORE_IP>

Filestore instances have a maximum throughput and IOPS that scale with capacity. However, there is also a per-instance ceiling: for Basic SSD, maximum read throughput is 1.2 GB/s (at 3 TiB), and for High Scale SSD, maximum is 10 GB/s (at 10 TiB). Beyond that, you need to create additional instances and distribute data. Write throughput is typically half of read throughput. Latency for Basic SSD is around 1-2 ms; for Basic HDD, 5-10 ms. For HPC workloads, High Scale SSD provides sub-millisecond latency.

By default, Filestore uses IP-based access control: you specify a list of allowed CIDR blocks. There is no authentication; any client within the allowed IP range can mount the share. For stronger security, you can enable Kerberos authentication, which requires a managed Microsoft AD domain. Additionally, you can use VPC firewall rules to restrict traffic to port 2049 from specific source ranges. Encryption at rest is always enabled (AES-256). Encryption in transit is not supported by NFSv3; data is unencrypted over the network. For encrypted transport, use a VPN tunnel or SSHFS as a workaround.

Filestore does not have built-in snapshots (as of the latest API). However, you can back up data using rsync to Cloud Storage or another Filestore instance. For regional instances, data is replicated across two zones; if one zone fails, the instance continues serving from the other zone. For zonal instances, a zone failure means the instance is unavailable. There is no cross-region replication built-in; you must implement your own using rsync or a third-party tool.

A video production company runs a render farm on Compute Engine. Each render node needs access to shared project files (models, textures, and output sequences). They use Filestore Basic SSD with 10 TiB capacity, providing 4 GB/s read and 2 GB/s write throughput. The render nodes mount the same share via NFS. The challenge is that hundreds of nodes read and write simultaneously, causing NFS lock contention. The solution is to use application-level locking (e.g., a job scheduler that assigns unique output filenames) and to avoid editing the same file concurrently. They also use noatime mount option to reduce metadata writes. In production, they monitor Cloud Monitoring for throughput spikes and increase capacity when the render queue grows. Misconfiguration: If they use soft mounts, a temporary network glitch causes render failures (error 5: Input/output error). They learned to use hard mounts with intr to allow interruption.

A SaaS company with 500 developers uses Filestore to provide home directories across multiple Compute Engine instances. They use Basic HDD (cost-effective for infrequent access) with 5 TiB capacity. Each developer's home directory is a subdirectory under the share. They use IP-based access control, restricting to the VPC subnet. They also use Kerberos for authentication to prevent unauthorized mounts. The main issue is performance: when many developers compile code simultaneously, the HDD throughput becomes a bottleneck. They upgrade to Basic SSD. Another issue: accidental deletion of files by users. They implement periodic rsync backups to Cloud Storage every hour. The exam may test that Filestore does not have built-in snapshots, so external backup is required.

A research institute runs large-scale genomics analysis using GKE. The pipeline requires reading large reference genomes (100s of GB) and writing intermediate results. They use Filestore High Scale SSD with 10 TiB capacity, providing 12 GB/s read throughput. They mount the share on GKE nodes using a PersistentVolume with ReadWriteMany access mode. The challenge is achieving low latency for small random reads. High Scale SSD delivers sub-millisecond latency. They also need to share data with on-premises servers via Dedicated Interconnect. The NFS mount over Interconnect works but adds 2-3 ms latency. They optimize by using local SSDs for scratch data and Filestore only for persistent shared data. Misconfiguration: They initially used a zonal instance, causing downtime when the zone failed. They switched to a regional instance for high availability. The exam may test that regional instances provide multi-zone redundancy but are more expensive.