Learn Linux Filesystem - Cloud & Managed Storage

#Introduction

The filesystem concepts you've learned so far still apply in the cloud — it's just that there's a new layer to understand: instance stores that disappear, EBS that persists but is expensive, and object storage that offers nearly unlimited scale. Episode 19 maps the cloud storage landscape.

We compare instance stores vs EBS/gp3, discuss the right filesystems for cloud images, then get to know S3-compatible object storage as a separate layer. Finally, we compare managed file systems — EFS, Azure Files, and GCP Filestore — and when to use local vs distributed storage.

The goal: you no longer see cloud storage as one thing, but as a spectrum of choices with very different characteristics.

#Instance Store vs EBS

#Instance Store: Fast but Temporary

An instance store is a disk attached directly to the VM's physical host — very fast NVMe, but data is lost when the instance is stopped or migrated.

Good for:

• Caches, scratch space, and rebuildable data.
• Workloads that need the lowest latency.

Not good for:

• Data that must survive an instance restart or termination.

Check the instance store on an EC2 Linux instance:

lsblk

Devices like /dev/nvme1n1 that aren't in the volume attachments are usually instance stores — check with df -hT to see which ones are already formatted.

#EBS/gp3: Persistent but Networked

EBS is block storage that travels over the storage network — slower than instance store, but data survives instance restarts. The gp3 volume is the modern default type:

sudo mkfs.ext4 /dev/nvme0n1
sudo mount /dev/nvme0n1 /mnt/data

gp3 allows provisioning IOPS and throughput separately from size — something gp2 didn't have. Because EBS is a block device, all the filesystem knowledge from previous episodes applies directly: ext4, XFS, even ZFS on top.

#Filesystems for Cloud Images

#The Standard: ext4 and XFS

Most Linux cloud images use ext4 for root — for the same reasons as on-premise: simplicity and mature bootloader support. RHEL-based images use XFS.

Use blkid to see which filesystem an image uses:

sudo blkid

#Volume Snapshots as Backups

EBS snapshots are the primary backup mechanism in the cloud. Because they operate at the block level, EBS snapshots can capture ext4, XFS, btrfs, or ZFS without caring about the contents:

aws ec2 create-snapshot --volume-id vol-0abcd1234efgh5678 --description "Backup harian"

For consistency, freeze the filesystem first (as in episode 9):

sudo fsfreeze --freeze /mnt/data
aws ec2 create-snapshot --volume-id vol-0abcd1234efgh5678
sudo fsfreeze --unfreeze /mnt/data

The fsfreeze + cloud snapshot pattern gives consistent backups even for filesystems without native snapshot support.

#Object Storage: A Separate Layer

#S3-Compatible Object Storage

Object storage (S3, MinIO, Ceph RGW) isn't a filesystem — it stores objects by key, without a directory hierarchy and without in-place updates. Its nature is completely different:

• Practically unlimited scale (petabyte+).
• Eventual consistency on some providers.
• Operations via HTTP API, not mounting.

Normal interaction is through a CLI, not mounting:

aws s3 cp /mnt/data/arsip.tar.gz s3://bucket-saya/backup/

#When to Use Object Storage

Object storage is best for:

• Backups and archives that are rarely accessed.
• Static assets (media, application distributions).
• Data lakes and centralized logs.

Not for:

• Databases with in-place operations.
• Loads that need file semantics (locking, atomic rename).

Remember the role separation: filesystems for compute, object storage for archives. Both coexist; they don't compete.

#Managed Filesystems: EFS, Azure Files, Filestore

#EFS and Azure Files

EFS (AWS) and Azure Files are managed NFS/SMB that can be mounted on many instances at once:

sudo mount -t nfs4 fs-0a1b2c3d4e.efs.us-east-1.amazonaws.com:/ /mnt/efs

Pros: automatic scaling, multi-AZ, and shared access between instances. Cons: higher latency and higher per-gigabyte price than EBS.

#GCP Filestore

GCP Filestore offers managed NFS with three performance tiers (basic, high, enterprise):

sudo mount -o nolock filestore-ip:/vol1 /mnt/filestore

The enterprise tier provides high availability and built-in backups — good for data that needs shared storage without managing NFS yourself.

#When Local, When Distributed

#The Deciding Questions

Use these three questions:

1. Does the data need to be shared between instances? Yes → managed FS or object storage.
2. Does the workload need low latency? Yes → local EBS/instance store.
3. Can the data be rebuilt? Yes → cheap instance store.

#Common Architectural Patterns

Combinations that often appear in production:

• Databases: EBS gp3 with a filesystem on top (ext4/XFS) — needs consistency and latency.
• Cache and scratch: NVMe instance store — fast and expendable.
• Media and archives: object storage — large scale and cheap.
• Small shared files: EFS/Filestore — shared access across many pods.

A healthy architecture usually uses all three at once — not a single answer.

#Conclusion

The cloud doesn't erase filesystems — it adds a layer of choices around them. Instance stores give raw speed, EBS gives persistence with all the filesystem knowledge you already have, and object storage plus managed FS open new dimensions of scale. The key is understanding each one's role.

Key takeaways:

• Instance stores are fast but temporary; EBS/gp3 is persistent but slower.
• Standard cloud images use ext4 or XFS — verify with blkid.
• EBS snapshots back up all filesystems at the block level; freeze first for consistency.
• S3 object storage isn't a filesystem — use it for archives, not databases.
• EFS, Azure Files, and Filestore are for managed multi-instance shared storage.
• A healthy architecture uses a combination: local for latency, managed for sharing, objects for scale.

In the next episode, episode 20, we cover modern features and roadmap — btrfs block-group-tree, ZFS BRT dedup and AnyRaid, ref feature flags, ZFS 256-bit exabyte scale, NFS/CIFS as the network filesystem layer, and the btrfs-progs 8.x and OpenZFS 2.5/2.6 roadmaps. You'll see where Linux filesystems are heading.