Master Linux Storage with LVM on AWS

Partition disks, build an LVM stack, and configure persistent mounts on AL2023.

Introduction

30 Second Summary

Every server you use stores files on a disk, but the operating system does not simply dump data onto raw hardware. Linux has an entire stack of layers between the physical disk and your files. Understanding how to manage those layers is what separates a system administrator from someone who just uses the terminal.

In this project, you will create a dedicated practice volume on AWS, partition it using GPT, build a complete LVM stack on top of those partitions, and configure persistent mounts that survive reboots.

What You'll Build

A production-style LVM storage configuration on an EC2 instance, covering the full hierarchy from raw NVMe block devices through to mounted filesystems with persistent /etc/fstab entries.

By the end of this project, you'll have:

A GPT-partitioned EBS volume with multiple partitions managed by gdisk.
A volume group spanning physical volumes with two logical volumes formatted as XFS and ext4.
Persistent /etc/fstab entries using UUIDs that survive instance reboots.
Secret Mission: Extend a logical volume and its filesystem non-destructively, then add LVM-backed swap to the system.

Are there any prerequisites?

You need a running Amazon Linux 2023 EC2 instance with SSH access, an AWS account with permissions to create and attach EBS volumes, and basic Linux command-line proficiency (ls, cd, grep, chmod).

Explore Block Devices, NVMe & Inodes

Your practice volume is attached and ready. Before you start partitioning it, you need to understand how Linux sees storage at every layer.

In this step, you will trace the path from raw hardware all the way up to the filesystem layer. You will inspect NVMe device naming, examine how the kernel registers block devices, and explore how inodes connect filenames to data on disk.

In this step, get ready to:

Map the Linux storage hierarchy using block device inspection commands.
Understand inodes and filesystem internals through hands-on exploration.
Inspect NVMe-specific attributes and understand why UUID-based identification matters.

Map the Linux storage hierarchy

Linux represents every storage device as a block device in /dev. On Nitro-based EC2 instances, all EBS volumes appear as NVMe devices regardless of the device name you specified during attachment.

List all block devices with filesystem details by running:

lsblk -f

What does this output show?

The -f flag adds filesystem type, UUID, and mount point columns. You should see /dev/nvme0n1 (your root volume with partitions) and /dev/nvme1n1 (your new practice volume with no filesystem yet).

Confirm which NVMe device is your practice volume by running:

sudo /sbin/ebsnvme-id /dev/nvme1n1

What is ebsnvme-id?

The ebsnvme-id tool maps an NVMe device name back to the /dev/sdf attachment name you specified in the attach-volume command. This confirms you are working with the correct device.

Examine the raw block device to confirm it has no partition table yet by running:

sudo fdisk -l /dev/nvme1n1

You should see that the disk is 2 GiB with no partitions listed.

View the kernel's block device registry by running:

cat /proc/partitions

What is /proc/partitions?

This virtual file exposes every block device the kernel knows about, along with its major and minor device numbers. The major number identifies the device driver. The minor number identifies the specific device or partition within that driver.

Check the device major and minor numbers for your NVMe devices by running:

ls -la /dev/nvme*

What do major and minor numbers mean here?

NVMe block devices use major number 259. The minor number distinguishes individual devices and their partitions. These numbers are how the kernel routes I/O requests to the correct driver.

Not seeing /dev/nvme1n1?

If your practice volume does not appear, the attachment may still be in progress. Run lsblk again after waiting 10 seconds. If it still does not appear, verify the volume state in the AWS console.

Help me troubleshoot why my EBS volume is not appearing as an NVMe device.

Understand inodes and filesystem internals

Every file on a Linux filesystem has exactly one inode. The inode stores all metadata about the file: permissions, timestamps, ownership, and pointers to the actual data blocks on disk. Directory entries simply map filenames to inode numbers.

Check inode usage on your root filesystem by running:

df -i /

Why does inode usage matter?

Inodes are fixed at filesystem creation time (during mkfs). A filesystem can run out of inodes even when disk space remains. This happens when many tiny files consume all available inodes. It is a real failure mode you must recognize for the RHCSA exam.

Inspect a specific file's inode to see its metadata by running:

stat /etc/os-release

You should see the inode number, allocated blocks, link count, permissions, and timestamps for this file.

Create a hard link and observe the link count change by running:

ln /etc/hostname /tmp/hardlink-test && stat /etc/hostname

What just happened?

The ln command created a new directory entry (/tmp/hardlink-test) pointing to the same inode as /etc/hostname. The stat output now shows a link count of 2. Both names reference the same underlying data. Deleting one name does not remove the data until the link count reaches zero.

A symbolic (soft) link is different. It creates a new inode that stores a path string pointing to the target. If the target is deleted, the soft link becomes a dangling reference.

Verify the hard link exists by running:

ls -li /etc/hostname /tmp/hardlink-test

You should see both files share the same inode number in the first column.

Permission denied when creating the hard link?

If you see a permission error, try running the command with sudo: sudo ln /etc/hostname /tmp/hardlink-test. Some systems restrict hard link creation to the file owner or root.

Help me fix the permission denied error when creating a hard link to /etc/hostname.

Inspect NVMe-specific attributes

NVMe device names can change between reboots. The kernel is free to assign a different /dev/nvme number each time the instance starts. This is the core reason /etc/fstab uses UUIDs instead of device paths.

View the NVMe device model information by running:

cat /sys/block/nvme1n1/device/model

You should see the EBS volume model identifier. This confirms the kernel exposes NVMe device attributes through the /sys virtual filesystem.

Why UUIDs instead of device paths?

AWS documentation recommends using UUIDs in /etc/fstab because device names can change but the UUID persists throughout the life of the partition. If you hardcode /dev/nvme1n1 in fstab and the kernel assigns a different NVMe number on reboot, your mount fails and the instance becomes unreachable via SSH.

You will use UUID-based mounts when you configure /etc/fstab in a later step.

No such file or directory for /sys/block/nvme1n1?

Your practice volume may have been assigned a different NVMe number. Run lsblk to find the correct device name, then replace nvme1n1 with the device name that has no partitions and shows 2G in size.

Help me find the correct NVMe device name for my practice EBS volume.

You now have a clear picture of how Linux organizes storage from hardware through to userspace. Your practice volume is sitting at the bottom of this hierarchy as a raw, unpartitioned NVMe device. Next up, you will carve it into GPT partitions.

GPT Partition the Practice Volume

In the last step, you explored the Linux storage hierarchy from raw NVMe devices down to inodes. You discovered that your practice volume (/dev/nvme1n1) currently has no partition table at all.

Before LVM can use the disk, you need to carve it into partitions with specific type codes. In this step, you will use gdisk to create a GPT partition table and define three partitions that will serve as the foundation for your LVM stack.

In this step, get ready to:

Create a GPT partition table with three partitions using gdisk.
Verify the partition layout with partprobe, lsblk, and blkid.
Understand why GPT is the modern standard for disk partitioning.

Create a GPT partition table and partitions using gdisk

The gdisk tool is an interactive, text-mode GPT partition editor. You will launch it against your practice volume and walk through a series of single-key prompts to create the new table and three partitions.

Launch gdisk on your practice volume by running this command:

sudo gdisk /dev/nvme1n1

You will see a Command (? for help): prompt. All edits stay in memory until you explicitly write them, so you can quit with q at any point without making changes.

Create a new empty GPT partition table by typing o and pressing Enter.
When prompted to confirm (Proceed?), type Y and press Enter.

Now create the three partitions, one at a time.

Start creating Partition 1 by typing n and pressing Enter.
For Partition number, type 1 and press Enter.
For First sector, press Enter to accept the default.
For Last sector, type +1G and press Enter to create a 1 GiB partition.
For the Hex code or GUID, type 8e00 and press Enter to set the type to Linux LVM.

Start creating Partition 2 by typing n and pressing Enter.
For Partition number, type 2 and press Enter.
For First sector, press Enter to accept the default.
For Last sector, type +512M and press Enter to create a 512 MiB partition.
For the Hex code or GUID, type 8e00 and press Enter to set the type to Linux LVM.

Start creating Partition 3 by typing n and pressing Enter.
For Partition number, type 3 and press Enter.
For First sector, press Enter to accept the default.
For Last sector, press Enter to use all remaining space.
For the Hex code or GUID, type 8200 and press Enter to set the type to Linux swap.

Write the partition table to disk and exit by typing w and pressing Enter.
When prompted to confirm (Do you want to proceed?), type Y and press Enter.

You should see a message saying the operation has completed successfully, and gdisk exits back to your shell.

What did each partition do?

Partition 1 (1 GiB, type 8e00) and Partition 2 (512 MiB, type 8e00) are both flagged as Linux LVM. In the next step, you will initialize these as Physical Volumes and pool them into a Volume Group.

Partition 3 (remaining ~512 MiB, type 8200) is reserved for Linux swap. You will use this in the Secret Mission to create LVM-backed swap space.

gdisk showing an error about existing data?

If gdisk complains about existing partition data when you press o, confirm with Y. This is safe because your practice volume has no data on it yet.

If you made a mistake during the session, type q and press Enter to quit without saving. Then relaunch gdisk and start over.

Help me troubleshoot my gdisk session on /dev/nvme1n1. I'm trying to create a GPT table with three partitions (1 GiB LVM, 512 MiB LVM, remaining swap) and something went wrong.

Verify the partition table

After writing the GPT, you need to inform the kernel about the new partition layout and confirm everything looks correct.

Tell the kernel to re-read the partition table by running this command:

sudo partprobe /dev/nvme1n1

Verify the three partitions are visible by running:

lsblk /dev/nvme1n1

You should see nvme1n1p1, nvme1n1p2, and nvme1n1p3 listed under nvme1n1.

Confirm the GPT details and partition sizes by running:

sudo gdisk -l /dev/nvme1n1

Check the partition type GUIDs by running:

sudo blkid /dev/nvme1n1p*

What should I see?

The lsblk output shows three child devices under nvme1n1 with sizes of approximately 1G, 512M, and 512M.

The gdisk -l output confirms the GPT table and shows each partition with its type code (8E00 for LVM, 8200 for swap).

The blkid output shows each partition's GUID. No filesystem UUID appears yet because you have not formatted the partitions.

Partitions not showing up in lsblk?

If lsblk does not show the three partitions, run sudo partprobe /dev/nvme1n1 again. The kernel sometimes needs a second nudge to pick up the new table.

If you still see no partitions, re-run sudo gdisk -l /dev/nvme1n1 to confirm the table was written. If it shows no partitions, gdisk may not have saved properly. Re-run the gdisk session from the previous substep.

My partitions aren't showing up after running partprobe on /dev/nvme1n1. I created them with gdisk (1 GiB + 512 MiB + remaining, types 8e00/8e00/8200). What should I check?

Understand GPT vs MBR

Why GPT instead of MBR?

GPT supports up to 128 partitions, while MBR is limited to 4 primary partitions. GPT also uses GUIDs for partition identification, which remain stable even when device names change between reboots.

GPT stores a backup partition table at the end of the disk for redundancy. If the primary table becomes corrupted, the backup can restore it.

The RHCSA EX200 exam specifically tests GPT partitioning. The exam objective states: "List, create, and delete partitions on GPT disks."

Why gdisk instead of fdisk?

While fdisk can handle GPT, gdisk is purpose-built for GPT tables. Its prompts, type codes, and verification tools are designed specifically for the GPT workflow.

Your practice volume is now carved into three well-defined partitions. Next up, you will build the LVM stack on top of the two LVM partitions, turning raw partitions into flexible, resizable storage.

Build the LVM Stack

Your practice volume now has a clean GPT partition table with three partitions ready for use. The next challenge is turning those raw partitions into flexible, resizable storage.

LVM (Logical Volume Manager) sits between your physical partitions and your filesystems. It lets you pool multiple partitions together and carve out virtual volumes that can be resized, snapshotted, and migrated without downtime. In this step, you will build a complete LVM stack on top of your GPT partitions.

In this step, get ready to:

Create physical volumes and a volume group from the GPT partitions.
Create logical volumes and format them with XFS and ext4 filesystems.
Understand the LVM abstraction layers from physical volumes to logical volumes.

Create physical volumes and a volume group

Before LVM can use a partition, it must be initialized as a physical volume (PV). This writes LVM metadata headers onto the partition so the system recognizes it as part of the LVM subsystem.

Initialize both LVM-typed partitions as physical volumes by running:

sudo pvcreate /dev/nvme1n1p1 /dev/nvme1n1p2

Verify the physical volumes were created by running:

sudo pvs

You should see both /dev/nvme1n1p1 and /dev/nvme1n1p2 listed with their respective sizes (1 GiB and 512 MiB).

What is a physical volume?

A physical volume is the lowest layer in the LVM stack. It marks a partition (or an entire disk) as available for LVM to manage.

The pvcreate command writes a small LVM header onto the partition. This header contains a UUID and information about Physical Extents (PEs), which are the fixed-size blocks LVM uses to allocate space.

For a detailed view of a single PV, run:

sudo pvdisplay /dev/nvme1n1p1

Note the PE Size (default 4 MiB) and Total PE count in the output. These values determine how finely you can allocate storage later.

Now pool both physical volumes into a single volume group called practice_vg by running:

sudo vgcreate practice_vg /dev/nvme1n1p1 /dev/nvme1n1p2

Verify the volume group by running:

sudo vgs

You should see practice_vg listed with 2 PVs, approximately 1.49 GiB of total space, and the same amount of free space.

Get the full details of the volume group by running:

sudo vgdisplay practice_vg

Look for Total PE and PE Size in the output. The PE Size is 4 MiB by default, and the Total PE shows how many 4 MiB chunks are available for creating logical volumes.

What is a volume group?

A volume group (VG) is a storage pool that aggregates one or more physical volumes into a single namespace. Think of it as combining multiple hard drives into one big pool of available space.

Once you create a VG, you carve logical volumes out of it. The VG abstracts away the physical boundaries between partitions, so a single logical volume can span multiple disks.

Seeing "Device excluded by a filter"?

This error means LVM does not recognize the partition as eligible. Confirm the partition type code is 8e00 (Linux LVM) by running sudo gdisk -l /dev/nvme1n1.

If the type is wrong, re-enter gdisk and change the partition type with the t command.

Still stuck? Help me fix the "Device excluded by a filter" error from pvcreate

Create logical volumes with different filesystems

With the volume group ready, you can now carve logical volumes out of it. You will create two logical volumes: one formatted with XFS for data and one with ext4 for logs.

Create an 800 MiB logical volume named lv_data by running:

sudo lvcreate -L 800M -n lv_data practice_vg

Create a 500 MiB logical volume named lv_logs by running:

sudo lvcreate -L 500M -n lv_logs practice_vg

Verify both logical volumes exist by running:

sudo lvs

You should see lv_data (800 MiB) and lv_logs (500 MiB) both listed under practice_vg.

What does lvcreate do?

The -L 800M flag sets the logical volume size to 800 MiB. The -n lv_data flag names the logical volume. The last argument practice_vg tells LVM which volume group to carve the space from.

Together, the two LVs consume 1300 MiB of the approximately 1.49 GiB available in the VG, leaving some free extents for future expansion.

Get a detailed view of the data LV by running:

sudo lvdisplay /dev/practice_vg/lv_data

Examine the device mapper paths that LVM creates by running:

ls -la /dev/mapper/practice_vg-*

Also check the volume group symlinks by running:

ls -la /dev/practice_vg/

Why are there two paths to the same volume?

Linux's device mapper subsystem creates the actual block devices at /dev/mapper/practice_vg-lv_data. LVM also creates convenience symlinks at /dev/practice_vg/lv_data that point to the same device.

Both paths work interchangeably for mounting and formatting. You will see both forms in documentation and exam questions.

Format lv_data with the XFS filesystem by running:

sudo mkfs.xfs /dev/practice_vg/lv_data

Format lv_logs with the ext4 filesystem by running:

sudo mkfs.ext4 /dev/practice_vg/lv_logs

Both commands print detailed output showing the filesystem parameters. For XFS, look for a line showing the data block size and log configuration. For ext4, look for the inode count, block count, and journal size.

XFS vs ext4

XFS is a high-performance journaling filesystem optimized for large files and parallel I/O. It cannot be shrunk after creation, only grown.

ext4 is the default Linux filesystem with mature tooling and support for both growing and shrinking. The RHCSA exam tests both, so practicing with each is essential.

Seeing "Insufficient free space"?

This means the volume group does not have enough Physical Extents to satisfy the requested size. Run sudo vgs and check the VFree column.

If VFree is less than the size you requested, reduce the -L value in your lvcreate command. Alternatively, confirm that both PVs are assigned to the VG with sudo pvs.

Need more help? Help me troubleshoot the Insufficient free space error from lvcreate

Understand the LVM abstraction layers

How do the LVM layers connect?

The LVM stack has three layers, each building on the one below:

Physical Volumes (PVs) are raw partitions or disks marked for LVM use.
Volume Groups (VGs) pool one or more PVs into a single storage namespace.
Logical Volumes (LVs) are the virtual partitions carved from VGs that you format and mount.

The key advantage is flexibility. LVs can be resized, snapshotted, and migrated without unmounting. This is the core reason LVM exists and a frequent exam topic.

Your LVM stack is fully built and both filesystems are ready. Next up, you will mount these volumes and configure /etc/fstab so they persist across reboots.

Mount Persistently with /etc/fstab

Your logical volumes are formatted and ready, but they exist in limbo. Without mounting them to directories, no application can read or write to them.

In this step, you will mount both logical volumes, write test data, and configure /etc/fstab so that the mounts survive a reboot. This is the step where your storage setup becomes production-ready.

In this step, get ready to:

Create mount points and verify both filesystems are accessible.
Configure persistent UUID-based mounts in /etc/fstab.
Validate the full storage hierarchy from NVMe device to mounted filesystem.

Create mount points and test mounts

A mount point is just an empty directory that acts as the gateway to a filesystem. Linux needs these directories to exist before it can attach a filesystem to them.

Create the two mount point directories by running this command:

sudo mkdir -p /mnt/data /mnt/logs

Mount your XFS logical volume to /mnt/data by running:

sudo mount /dev/practice_vg/lv_data /mnt/data

Mount your ext4 logical volume to /mnt/logs by running:

sudo mount /dev/practice_vg/lv_logs /mnt/logs

Verify both mounts are active by running:

df -hT /mnt/data /mnt/logs

You should see two lines showing xfs for /mnt/data and ext4 for /mnt/logs, with sizes approximately 800M and 500M respectively.

Write a test file to confirm you can store data on the XFS volume:

echo "LVM works" | sudo tee /mnt/data/test.txt

What does this verify?

Writing a test file proves the entire stack is functional. Data travels from your shell through the LVM device mapper, into the XFS filesystem, and lands on the physical EBS volume. You will check this file again after configuring persistent mounts to confirm nothing was lost.

Mount command says wrong fs type?

If you see an error mentioning a wrong filesystem type or bad superblock, double-check that you formatted lv_data with XFS and lv_logs with ext4 in the previous step. You can re-format if needed with sudo mkfs.xfs -f /dev/practice_vg/lv_data or sudo mkfs.ext4 /dev/practice_vg/lv_logs.

Help me troubleshoot a mount error on my LVM logical volume.

Configure persistent mounts using UUIDs

Manual mounts disappear on reboot. The file /etc/fstab tells Linux which filesystems to mount automatically at boot. Using UUIDs instead of device paths ensures the correct filesystem is always mounted, even if NVMe device names shift between reboots.

Why UUIDs instead of device paths?

On Nitro-based EC2 instances, NVMe device names like /dev/nvme1n1 can be reassigned in a different order between reboots. A UUID is a unique fingerprint baked into the filesystem at creation time. It never changes, making it the only reliable identifier for /etc/fstab entries on cloud instances.

Retrieve the UUIDs of both logical volumes by running:

sudo blkid /dev/practice_vg/lv_data /dev/practice_vg/lv_logs

You should see output containing a UUID="..." value for each device. Copy both UUIDs. You will need them in the next commands.

Back up the original /etc/fstab before making any changes:

sudo cp /etc/fstab /etc/fstab.bak

Why back up fstab?

A malformed /etc/fstab entry can prevent your instance from booting. Keeping a backup at /etc/fstab.bak gives you an instant recovery path if something goes wrong.

Append the XFS mount entry to /etc/fstab by running this command (replace the UUID with yours):

echo 'UUID=[[LV_DATA_UUID="your lv_data UUID from blkid output"]] /mnt/data xfs defaults,nofail 0 0' | sudo tee -a /etc/fstab

Append the ext4 mount entry to /etc/fstab by running this command (replace the UUID with yours):

echo 'UUID=[[LV_LOGS_UUID="your lv_logs UUID from blkid output"]] /mnt/logs ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

What do these fstab fields mean?

UUID=... identifies the filesystem without relying on device names.
/mnt/data or /mnt/logs is where the filesystem will appear in the directory tree.
defaults,nofail uses standard mount options. The nofail option prevents boot failure if the EBS volume is detached or unavailable.
The final two numbers control dump backup (0 = skip) and fsck pass order (0 = skip, 2 = check after root).

Now test that fstab works by unmounting both filesystems and re-mounting from the config:

sudo umount /mnt/data /mnt/logs && sudo mount -a

Confirm your test data survived the remount cycle:

cat /mnt/data/test.txt

You should see LVM works printed to the terminal. This proves the UUID-based fstab entry correctly identified and remounted the XFS filesystem.

mount -a shows an error?

If mount -a reports a mount error, the most common cause is a typo in the UUID. Run sudo blkid /dev/practice_vg/lv_data again and compare it character-by-character with what you pasted into fstab.

If you need to fix the entry, restore the backup with sudo cp /etc/fstab.bak /etc/fstab and try again.

Help me fix my /etc/fstab entry that is failing to mount.

Validate the full configuration

Your mounts work, but a production system administrator always validates the full stack. These commands give you a complete picture of every layer, from raw device to filesystem health.

Check your fstab for syntax errors by running:

sudo findmnt --verify

If everything is correct, you should see a success message confirming no errors or warnings were detected.

View the complete storage hierarchy by running:

lsblk -f

You should see /dev/nvme1n1 with its three partitions, the LVM2_member filesystem type on p1 and p2, and the two logical volumes showing their filesystems and mount points.

Inspect the XFS filesystem details by running:

sudo xfs_info /mnt/data

What does xfs_info show?

This command displays the internal geometry of your XFS filesystem. The data section shows block size and total blocks. The log section shows the journal size. These details become important when you extend the volume in the Secret Mission.

Check the ext4 filesystem block usage by running:

sudo tune2fs -l /dev/practice_vg/lv_logs | grep -i "block count\|free blocks"

You should see Block count and Free blocks values. The difference between them tells you how much space the filesystem overhead (inodes, journals, reserved blocks) consumes.

Why inspect filesystem internals?

The RHCSA exam expects you to verify filesystem health without a GUI. Knowing how to read xfs_info and tune2fs output helps you diagnose capacity issues, confirm successful extensions, and verify journal integrity on production systems.

Your LVM storage stack is now fully mounted and persistent. On the next reboot, Linux will read /etc/fstab and automatically mount both volumes using their UUIDs. Next up, you will push this setup further in the Secret Mission by extending a live filesystem and adding swap.

Secret mission

Extend LVM and Add Swap

In a production environment, storage needs grow. Can you extend a logical volume without unmounting it, add swap space backed by LVM, and write a script that reports the health of your entire storage stack?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The 2 GiB gp3 EBS volume costs approximately $0.16/month if left provisioned.

Cost warning

Your 2 GiB gp3 EBS volume is billed at $0.08/GiB-month regardless of whether it is attached or in use. If you are finished practicing, choose the Delete tab to remove it and avoid ongoing charges.

Resources you used:

2 GiB gp3 EBS volume (attached as /dev/nvme1n1).
LVM structures: practice_vg volume group, lv_data, lv_logs, and lv_swap logical volumes.
Modified /etc/fstab entries (UUID mounts and swap).
Mount point directories: /mnt/data and /mnt/logs.
Installed packages: lvm2 and gdisk.

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue practicing LVM commands on this volume.

Your EBS volume remains attached and all filesystems stay mounted.
The volume costs approximately $0.16/month (2 GiB at $0.08/GiB-month).
Your /etc/fstab entries will persist across reboots thanks to the nofail option.

Pause - I'll come back to this later

Unmount your filesystems and deactivate swap to free up resources. Restore your fstab to prevent boot issues if the volume is detached later. The volume itself remains provisioned and still costs ~$0.16/month.

Deactivate swap and unmount filesystems by running:

sudo swapoff /dev/practice_vg/lv_swap
sudo umount /mnt/data /mnt/logs

Restore your original fstab to prevent boot failures if you later detach the volume:

sudo cp /etc/fstab.bak /etc/fstab

Your LVM structures and data remain intact on the volume. When you are ready to resume, re-add the fstab entries and run sudo mount -a.

Delete - I don't want to use this again

Remove all project resources completely. After these steps your instance returns to its original state with no ongoing charges from this project.

Deactivate swap and unmount all filesystems by running:

sudo swapoff /dev/practice_vg/lv_swap
sudo umount /mnt/data /mnt/logs

Remove the volume group and all its logical volumes by running:

sudo vgremove practice_vg -f

Remove the physical volume labels from the partitions by running:

sudo pvremove /dev/nvme1n1p1 /dev/nvme1n1p2

Restore your original fstab by running:

sudo cp /etc/fstab.bak /etc/fstab

Detach and delete the EBS volume by running:

aws ec2 detach-volume --volume-id [[VOLUME_ID="your volume ID e.g. vol-0abc123"]]
aws ec2 delete-volume --volume-id [[VOLUME_ID="your volume ID e.g. vol-0abc123"]]

Remove the mount point directories by running:

sudo rm -rf /mnt/data /mnt/logs

Remove the hard link test file and storage report script by running:

rm -f /tmp/hardlink-test
rm -f storage_report.sh

Optionally remove the installed packages by running:

sudo dnf remove -y lvm2 gdisk

Nice Work!

You just built a production-style Linux storage stack from scratch on a live EC2 instance. From raw NVMe block devices all the way up to persistently mounted filesystems, you now have hands-on experience with the exact storage objectives tested on the RHCSA EX200 exam.

Here's what you accomplished:

Explored the Linux storage hierarchy from NVMe device naming and /proc/partitions through to inodes, then partitioned a disk using GPT with gdisk.
Built a complete LVM stack with physical volumes, a volume group, and logical volumes formatted with both XFS and ext4 filesystems.
Configured persistent mounts in /etc/fstab using UUIDs and the nofail option to ensure your instance always boots cleanly.
Secret Mission: Extended a logical volume and its XFS filesystem non-destructively, configured LVM-backed swap, and wrote a storage health reporting script.

Ready to quiz yourself?