5.3 OCI File Storage Service (FSS)

5.3 OCI File Storage Service (FSS)

[!NOTE] Foundations Blueprint Focus: The OCI Foundations Associate (1Z0-1085-26) exam tests your understanding of shared file storage principles, the Network File System (NFSv3) protocol, POSIX compliance, Mount Target placement, Export Sets and Export Options, snapshots, and the definitive architectural criteria governing when to choose Block Volume, Object Storage, or File Storage.

While block volumes attach directly to individual servers and object storage provides REST-accessible buckets for unstructured blobs, enterprise applications frequently require a shared, hierarchical file system accessible simultaneously across hundreds of compute instances. In Oracle Cloud Infrastructure, this capability is delivered by the OCI File Storage Service (FSS).

---

File Storage Service Fundamentals & Elasticity

OCI File Storage Service (FSS) is a fully managed, enterprise-grade Network Attached Storage (NAS) service. It allows multiple virtual machines, bare metal instances, and container clusters to mount the same shared file system over standard networking protocols.

Core Architectural Attributes

• Standard Protocols (NFSv3): FSS supports the industry-standard Network File System version 3 (NFSv3) protocol, paired with the Network Lock Manager (NLM) protocol for advisory file-locking capabilities. Any operating system that supports NFSv3 (including Oracle Linux, Red Hat Enterprise Linux, Ubuntu, and Windows Server) can mount an FSS file system.
• POSIX Compliance: Delivers full Portable Operating System Interface (POSIX) semantics. Applications can interact with directories, subdirectories, file permissions (rwx), user and group ownerships (chown, chmod), hard links, symbolic links, and byte-range locks exactly as they would on a local disk drive.
• Unbounded Elasticity: Unlike traditional storage arrays that require administrators to forecast storage requirements and pre-allocate fixed capacity, FSS is completely elastic. A newly created file system starts at zero bytes, automatically expands as files and directories are written, and automatically contracts as files are deleted. A single file system can scale up to 8 Exabytes (EB)—essentially infinite capacity for enterprise workloads.
• Pay-as-You-Go Billing: Customers pay exclusively for the exact gigabytes of capacity consumed. There is no charge for unallocated space, and no requirement to purchase provisioned IOPS.
• High Availability and Durability: Data written to FSS is synchronously replicated across multiple physical storage servers and fault domains within the Availability Domain, delivering enterprise durability and high availability.
• Built-in Security & Encryption: All data and metadata stored in FSS is encrypted at rest by default using AES-256. Furthermore, FSS supports in-transit encryption between client compute instances and mount targets using Transport Layer Security (TLS v1.2) with NFS kerberized authentication or stunnel packaging.

---

Key Architectural Components of FSS

Connecting compute instances to an FSS file system involves four core architectural constructs:

+-------------------------------------------------------------------------+
|                   OCI File Storage Service Architecture                 |
|                                                                         |
|  +-------------------------------------------------------------------+  |
|  | Virtual Cloud Network (VCN) / Subnet                              |  |
|  |                                                                   |  |
|  |   [Compute VM 1]          [Compute VM 2]          [OKE Pods]      |  |
|  |         │                       │                      │          |  |
|  |         └───────────────────────┼──────────────────────┘          |  |
|  |                                 v (NFSv3: Mount 10.0.2.50:/app)   |  |
|  |                   +---------------------------+                   |  |
|  |                   | Mount Target (VNIC)       |                   |  |
|  |                   | Private IP: 10.0.2.50     |                   |  |
|  |                   +-------------+-------------+                   |  |
|  +---------------------------------┼---------------------------------+  |
|                                    v                                    |
|                   +----------------+-------------+                      |
|                   | Export Set & Export Path     |                      |
|                   | (Path: /app, Options: rw)    |                      |
|                   +----------------+-------------+                      |
|                                    v                                    |
|                   +----------------+-------------+                      |
|                   | Managed File System          |                      |
|                   | (Elastic up to 8 Exabytes)   |                      |
|                   +------------------------------+                      |
+-------------------------------------------------------------------------+

1. File System

• The primary storage resource that contains hierarchical directories and files.
• Can scale up to 8 Exabytes and store billions of files.
• Exists independently of compute instances and mount targets.

2. Mount Target

• A specialized Virtual Network Interface Card (VNIC) that resides inside a customer-specified VCN subnet.
• Receives a private IP address (and optional DNS hostname) from the subnet's CIDR range.
• Acts as the NFS server endpoint that client compute instances communicate with to mount the file system (mount -t nfs <Mount_Target_IP>:<Export_Path> /mnt/local).
• Network Security Requirements: To permit NFS client traffic, the subnet's Security List or Network Security Group (NSG) must permit ingress traffic on TCP/UDP ports 2048 through 2050 (NFS, NLM, and mountd) and TCP/UDP port 111 (rpcbind portmapper).

3. Export Set & Export Path

• Export Set: A configuration directory on the Mount Target that manages how file systems are exposed to the network. Each Mount Target has exactly one Export Set.
• Export Path: A unique virtual path (e.g., /finance-data or /shared-app) assigned to a file system when linking it to a Mount Target. A single Mount Target can export multiple independent file systems, each distinguished by a unique export path.

4. Export Options (NFS Security Rules)

Export options define granular client-level access controls for each export path:

• Client Source Network: Restricts access to specific client IP addresses or CIDR blocks (e.g., allow only 10.0.1.0/24).
• Access Mode: Configured as Read/Write (rw) or Read-Only (ro).
• Root Squashing (Identity Squashing):
  • By default, NFS maps root users (UID=0, GID=0) on client machines to an unprivileged user (commonly nobody with UID=65534). This security feature prevents users who have root privileges on a client virtual machine from escalating their privileges to overwrite critical root-owned files on the shared file system.
  • Administrators can selectively disable root squashing (no_root_squash) if an application specifically requires remote root access.

Snapshots & Self-Service File Recovery

To safeguard file systems against accidental deletion, file corruption, or administrative error, FSS provides native Snapshots:

• Point-in-Time Read-Only Copy: A snapshot captures a consistent, point-in-time, read-only view of the entire file system.
• Copy-on-Write Technology: Creating a snapshot takes less than a second regardless of file system size. A newly created snapshot consumes zero additional storage capacity.
• Storage Consumption: A snapshot only consumes incremental storage as blocks in the active file system are modified or deleted after the snapshot is taken.
• The Hidden .snapshot Directory: Snapshots are exposed to users directly inside the root directory of the mounted file system within a hidden directory named .snapshot (for example, /mnt/shared/.snapshot/snapshot_2026_09_01/).
• Self-Service File Recovery: Because snapshots are exposed directly in the .snapshot directory, end users and application owners can browse prior versions and restore accidentally deleted files using standard file copy commands (cp, rsync) without opening IT support tickets or requiring cloud administrator intervention.

---

Primary FSS Use Cases

1. Shared Application Storage: Web server farms (e.g., WordPress, Drupal, Magento) where multiple load-balanced web servers share a single media repository and configuration directory.
2. Enterprise Application Suites: Legacy enterprise software architectures—such as Oracle E-Business Suite, PeopleSoft, Siebel, and SAP—that require shared file systems across multiple application tiers.
3. Kubernetes Persistent Storage (OKE): Containerized microservices requiring shared storage. FSS supports the Kubernetes ReadWriteMany (RWX) access mode, allowing multiple pods running across different worker nodes to read and write to the same volume concurrently.
4. Big Data Analytics & AI Scratch Space: Shared data lakes, training dataset repositories, and analytical pipelines where multiple compute instances process shared CSV, Parquet, or image files simultaneously.
5. Lift-and-Shift Migrations: Migrating on-premises Linux/Unix servers that rely on traditional network attached storage (NAS) arrays without rewriting application storage logic.

---

The Definitive Three-Way Storage Comparison: Block Volume vs. Object Storage vs. File Storage

A critical requirement for passing the OCI Foundations Associate (1Z0-1085-26) exam is understanding precisely when to select each of the three primary OCI storage services:

+---------------------------------------------------------------------------------+
|                        OCI Storage Architecture Comparison                      |
|                                                                                 |
|  +-----------------------+  +-----------------------+  +---------------------+  |
|  |   OCI Block Volume    |  |  OCI Object Storage   |  |  OCI File Storage   |  |
|  +-----------------------+  +-----------------------+  +---------------------+  |
|  | - NVMe Block Protocol |  | - HTTPS REST / S3 API |  | - NFSv3 / POSIX     |  |
|  | - Raw unformatted disk|  | - Flat namespace/bkt  |  | - Hierarchical tree |  |
|  | - Dedicated to VM/BM  |  | - Global / Regional   |  | - Shared across VMs |  |
|  | - Microsecond latency |  | - Tens-of-ms latency  |  | - Single-digit ms   |  |
|  | - 50 GB to 32 TB/vol  |  | - Unlimited exabytes  |  | - Up to 8 Exabytes  |  |
|  +-----------------------+  +-----------------------+  +---------------------+  |
+---------------------------------------------------------------------------------+

Comprehensive Storage Services Decision Matrix