Filesystems¶

Overview¶

A filesystem (FS) controls how data is organized, stored, and retrieved on a storage device. It acts as an intermediary between applications and the raw storage hardware, mediating input-output (IO) between physical devices (USB, hard drives, SSDs, NVMe) and software.

Different filesystems offer different trade-offs. When selecting a filesystem, the main considerations are: required size, features, performance under specific workloads, and OS compatibility. Linux supports many types: ext4 (reliable general-purpose), XFS (high-performance, default on RHEL/CentOS), Btrfs (modern with snapshots and checksums), and FAT32 (cross-platform compatibility). Network filesystems like NFS and SMB/CIFS allow sharing files across machines.

How It Works¶

Local Filesystems¶

Local filesystems run on a local machine and are directly attached to the machine's storage. Most local filesystems are POSIX-compliant, meaning they support standard system calls like read(), write(), and seek().

ext4¶

Extended Journaling File System 4 (ext4) is the 4th generation of the ext family. It has backward compatibility with ext2 and ext3.

Key features:

• Maximum filesystem size up to 50 TiB
• Extent-based metadata — instead of storing every individual block, it stores the first and last block of each continuous range (extent), reducing fragmentation and speeding up large file operations
• Delayed allocation — postpones block allocation until data is flushed to disk, enabling larger, more contiguous allocations
• Journal checksumming — warns about invalid or out-of-order entries after a crash, preventing further filesystem damage
• Fast repair with fsck thanks to journaling

Thanks to its longevity, most Linux applications support ext4. It is commonly used for /home partitions.

XFS¶

Extents File System (XFS) is a high-performance, robust 64-bit journaling filesystem. It is the default filesystem on RHEL/CentOS. Originally developed by SGI in the early 1990s, XFS has a long history on large servers.

Key features:

• Maximum filesystem size up to 8 EiB
• Metadata journaling for crash recovery
• Proficient parallel IO — extreme scalability across multiple storage devices
• B-tree indexing for scalable free space management
• Can only be expanded, not shrunk

XFS excels with multi-threaded, parallel IO workloads but performs less well with single-threaded or metadata-intensive operations.

Btrfs¶

B-Tree Filesystem (Btrfs) is a modern copy-on-write (CoW) filesystem for Linux. It uses a generalized binary tree structure instead of block-based allocation.

Key features:

• Copy-on-write (CoW) — if data is copied but not modified, the copy exists as a reference to the original. Only when new data is written does an actual copy occur.
• Checksums — data integrity verification across all files. Scheduled checksum runs can detect and fix bit-flip errors caused by magnetic issues, solar flares, or copy errors.
• Snapshots — the tree structure makes snapshots trivial by simply pointing to a different tree root
• Multi-device spanning and pooling

FAT32¶

File Allocation Table 32 (FAT32) is a legacy filesystem supported by every major OS (Windows, Linux, macOS). Its main advantage is cross-platform compatibility.

Limitations:

• Maximum file size: 4 GiB
• Maximum partition size: 2 TiB
• Limited metadata features, no journaling
• No file permissions (not POSIX-compliant)

FAT32 is used primarily for USB drives and other removable media where cross-platform compatibility is needed.

Partitions¶

A partition organizes a storage device into smaller segments, allowing different parts of a disk to serve different purposes.

There are three partition types under the MBR scheme:

• Primary partition — a conventional partition. A disk can have at most 4 primary partitions (MBR limitation). Only primary partitions can be bootable.
• Extended partition — a container that holds multiple logical partitions, working around the 4-partition limit.
• Logical partition — a partition inside an extended partition. Used the same way as a primary partition.

The workflow for setting up a new disk:

1. Identify block devices with lsblk and blkid
2. Partition the disk with fdisk /dev/sdX
3. Format partitions with mkfs.<type> (e.g., mkfs.ext4 -L "label" /dev/sdX1)
4. Create mount points with mkdir -p /mnt/myfs
5. Mount with mount /dev/sdX1 /mnt/myfs (temporary) or add to /etc/fstab (persistent)
6. Test with mount -a and systemctl daemon-reload

The /etc/fstab File¶

/etc/fstab describes filesystems that the system automatically mounts at boot. Each line has 6 fields:

Example:

UUID=a1b2c3d4-... /lab8/fs-ext4  ext4  defaults  0 0
UUID=e5f6g7h8-... /lab8/fs-xfs   xfs   defaults  0 0

Network Filesystems¶

NFS (Network File System)¶

NFS is a distributed file system protocol that allows accessing files over a network as if they were local storage. Originally developed by Sun Microsystems in 1984, NFS is the easiest way to set up filesystem sharing in Unix environments.

Key files:

• /etc/exports — defines which directories are shared and with what permissions
• /etc/fstab — can include NFS mounts for persistent mounting

Ports: NFS requires ports 111 (rpcbind) and 2049 (nfs) to be open.

Basic workflow:

1. Install nfs-utils and start nfs-server
2. Create the directory to export (e.g., /shares/nfs)
3. Add an entry to /etc/exports with access permissions
4. Run exportfs -a to publish changes
5. Mount with mount -t nfs server:/shares/nfs /mnt/nfs

SMB/CIFS (Samba)¶

SMB (Server Message Block) is a network file-sharing protocol originally from IBM, later adopted and extended by Microsoft. Samba is the open-source implementation that allows Linux systems to share files with Windows clients (and other Linux systems).

Key differences from NFS:

• SMB uses username/password authentication (managed with smbpasswd)
• Configuration is in /etc/samba/smb.conf
• Ports: 139 and 445 (TCP)
• Better interoperability with Windows systems
• Requires SELinux context (samba_share_t) on shared directories

Object Storage¶

Object storage manages data as discrete objects rather than files in a hierarchy. Each object contains the data, metadata, and a unique identifier. It is designed for massive scale and is the foundation of cloud storage services like Amazon S3.

Key differences from traditional filesystems:

• No directory hierarchy (flat namespace with buckets)
• Accessed via HTTP/HTTPS APIs (RESTful)
• Scales horizontally to petabytes
• Uses load balancing like web services (unlike NFS/Samba)
• Objects are typically immutable (replace, not edit)

Object storage is ideal for unstructured data: images, videos, backups, and log archives.

Key Terminology¶

Block Device

A storage device that reads and writes data in fixed-size blocks. Represented as files in /dev/ (e.g., /dev/sda, /dev/sdb).

Journaling

A filesystem feature that logs changes before applying them. On crash, the journal is replayed to recover a consistent state without a full filesystem check.

Mount Point

A directory where a filesystem is attached to the directory tree. Accessing the mount point accesses the mounted filesystem.

UUID

Universally Unique Identifier assigned when a filesystem is formatted. Used in /etc/fstab to reference partitions reliably (device names like /dev/sdb can change).

Bucket

A logical container in object storage, analogous to a top-level directory.

Common Ports and Protocols¶

Why It Matters¶

As a system administrator, you will:

• Choose appropriate filesystems based on workload requirements (performance, size, features)
• Partition and format new disks when storage is added
• Configure persistent mounts via /etc/fstab
• Set up NFS and Samba shares for file sharing across machines
• Manage object storage for cloud-native applications and backups
• Troubleshoot mount failures and disk space issues

Common Pitfalls¶

1. Formatting the wrong disk — always verify with lsblk and df before running mkfs. Formatting the OS disk destroys your system.
2. Errors in /etc/fstab — a typo can prevent boot. Always test with mount -a first.
3. Forgetting systemctl daemon-reload — after editing fstab, systemd needs to be notified of the changes.
4. Not opening firewall ports for NFS/Samba — network filesystems need their ports accessible.
5. Using device names instead of UUIDs — device names (/dev/sdb) can change between reboots. UUIDs are stable.
6. Ignoring SELinux contexts — Samba shares need samba_share_t context or access will be denied despite correct permissions.
7. Automating filesystem creation with Ansible — filesystem modifications (partitioning, formatting) are destructive and generally should not be automated. Mounting, however, is safe to automate.

Further Reading¶

• Red Hat: Managing File Systems
• Arch Wiki: File Systems
• NFS Documentation
• Samba Documentation

Related Documentation¶

• SOPs: Filesystem Management
• Concepts: Users and Permissions