Local Storage: Partitions, Extending LVM, and Stratis

Intermediate35 min6 steps

What you'll learn

Create a partition with parted/fdisk and make the kernel see it with partprobe
Choose GPT vs MBR correctly, and know why the kernel must re-read the partition table
Extend an LVM logical volume AND its filesystem in one step with lvextend -r
Stand up Stratis storage: start stratisd, then create a pool and a filesystem
Apply the XFS rules the exam tests: grow online, never shrink

Why local storage is its own RHCSA skill
Frame the three jobs the exam grades: cut a partition, grow LVM, and manage Stratis.
You already know the LVM model from the prerequisite lesson — physical volumes feed a volume group, and logical volumes are carved out of it. This lesson is not about re-learning that. It's about the three specific storage tasks an RHCSA grader puts in front of you and the small, easy-to-forget steps that make each one actually take effect:
- Cut a new partition on a raw disk and get the kernel to notice it.
- Grow an existing logical volume so a full filesystem stops being full.
- Stand up Stratis, Red Hat's newer pooled-storage layer.
Each task has a single step that, if you skip it, makes everything look done while the system disagrees. Those skipped steps are exactly what the exam — and real on-call pages — catch.
Why it matters
Storage tasks fail quietly. A partition you 'created' that the kernel can't see, an lvextend that grew the volume but not the filesystem, a Stratis command that errors because a daemon isn't running — none of these throw an obvious red banner. Knowing the one extra verb each task needs is the whole difference between a passing answer and a confusing dead end.
Cut a partition: GPT vs MBR, then make the kernel re-read it
Create a partition with parted and explain why partprobe is mandatory.
A raw disk is just a long row of blocks. A partition table is the disk's table of contents: it records where each partition starts and ends. There are two formats:
- MBR (msdos): the old standard. Caps out at 2 TiB per disk and 4 primary partitions.
- GPT: the modern default. Handles huge disks and up to 128 partitions without the primary/extended juggling.
For anything new, choose GPT unless you have a specific legacy reason not to. With parted you set the table type with mklabel, then carve a partition with mkpart.
Example — not runnable on your lab box
```
$ sudo parted /dev/vdb mklabel gpt
```
```
Information: You may need to update /etc/fstab.
```
mklabel gpt
Write a fresh GPT partition table to the disk (use msdos for MBR). This ERASES the existing table.
This stamps an empty GPT table onto /dev/vdb. Nothing is partitioned yet — you've only declared which format the table of contents uses. mklabel wipes any prior table, so confirm you're on the right disk first.
Example — not runnable on your lab box
```
$ sudo parted /dev/vdb mkpart primary xfs 1MiB 2GiB
```
```
Information: You may need to update /etc/fstab.
```
mkpart
Create a partition.
primary
Partition name/type. On GPT this is just a label; the primary/extended distinction is an MBR concept.
xfs
Hint at the intended filesystem. parted does NOT format — this only sets a type flag.
1MiB 2GiB
Start and end of the partition. Starting at 1MiB keeps the partition aligned to the disk's physical boundaries for performance.
Now /dev/vdb has one partition spanning 1MiB to 2GiB. It will appear as /dev/vdb1. Note that parted never makes a filesystem — you still owe a mkfs.xfs /dev/vdb1 before you can mount it.
Deleting one partition, and setting a partition's type
A disk you inherit usually has partitions on it already. To remove one of them, delete it by number and leave the table alone: parted /dev/vdb print lists the numbers, then parted /dev/vdb rm 1 (in fdisk it's d, then w to write). Running mklabel instead throws away every partition, and mklabel msdos also turns a GPT disk into MBR.
Every GPT partition also carries a type, a GUID that tools show as a friendly name such as "Linux filesystem" or "Linux swap". The type is what the exam checks, not the name you give the partition. In parted, the file-system argument sets it: mkpart swap linux-swap 301MiB 557MiB makes a Linux swap partition, and xfs or ext4 give Linux filesystem. In fdisk, new partitions start as Linux filesystem; change one with t, the partition number, and the type number from the L list (19 is Linux swap on RHEL 9's fdisk). fdisk -l /dev/vdb shows each partition's type to check your work.
Here's the step everyone forgets. The kernel read the partition table once, at boot, into an in-memory copy. Your parted edits changed the table on disk, but the kernel's in-memory map is now stale — so /dev/vdb1 may not exist as a device node yet. partprobe tells the kernel: re-read the table and rebuild your map.
Example — not runnable on your lab box
```
$ sudo partprobe /dev/vdb
```
Silent success. The kernel re-reads /dev/vdb's partition table and creates the /dev/vdb1 device node. Only now can you mkfs and mount it. If a partition is in use (mounted), the kernel may refuse to re-read it and ask you to reboot — a reboot achieves the same thing because the table is read fresh at boot.
The #1 partition mistake: skipping partprobe
You run parted, then mkfs.xfs /dev/vdb1, and get 'No such file or directory'. The partition exists on disk but the kernel hasn't been told. The fix isn't to re-create the partition — it's sudo partprobe /dev/vdb (or reboot). Watch for this: the exam loves to see whether you make the new partition actually usable, not just defined.
Analogy: the partition table is like a building directory in the lobby. You renovated the third floor and updated the master blueprint, but the directory board by the elevator still shows the old layout. Visitors (the kernel) read the board, not your blueprint. partprobe is walking over and updating the board so people can actually find the new office.
Check yourself
You created /dev/vdb1 with parted, but mkfs.xfs /dev/vdb1 says the device doesn't exist. What command fixes this without re-creating the partition?
Grow an LVM volume: lvextend -r does it in one move
Extend a logical volume and resize its filesystem with a single -r flag.
A filesystem on a logical volume is filling up. Because it's LVM (not a raw partition), you can grow it online — no unmount, no downtime. But growing has two layers that beginners conflate:
1. Make the logical volume (the block device) bigger — lvextend.
2. Make the filesystem on top of it use the new space — resize2fs (ext4) or xfs_growfs (XFS).
Grow only the LV and the filesystem still reports the old, full size — the extra space is invisible to applications. This catches people constantly.
The two-step way looks like this — it works, but it's two commands and a chance to forget the second one:
Example — not runnable on your lab box
```
$ sudo lvextend -L +1G /dev/datavg/datalv
sudo xfs_growfs /datadir
```
```
  Size of logical volume datavg/datalv changed from 2.00 GiB (512 extents) to 3.00 GiB (768 extents).
  Logical volume datavg/datalv successfully resized.
meta-data=/dev/mapper/datavg-datalv ... data blocks changed from 524288 to 786432
```
-L +1G
Grow the LV by 1 GiB. A leading + means 'add'; without it, -L 3G means 'set to exactly 3 GiB'.
First command grew the block device; second command grew the XFS filesystem to fill it. Note xfs_growfs takes the mountpoint (/datadir), not the device. Two commands, two layers — correct, but verbose.
Now the convenient way. lvextend has a -r (--resizefs) flag that does both layers in one command — it grows the LV, then automatically calls the right filesystem-resize tool (resize2fs or xfs_growfs) for whatever filesystem it finds. This is the single most useful storage shortcut on the exam.
```
$ sudo lvextend -r -L +1G /dev/datavg/datalv
```
```
  Size of logical volume datavg/datalv changed from 3.00 GiB (768 extents) to 4.00 GiB (1024 extents).
  Logical volume datavg/datalv successfully resized.
meta-data=/dev/mapper/datavg-datalv ... data blocks changed from 786432 to 1048576
```
-r
--resizefs: after growing the LV, automatically resize the filesystem on it to match. One step instead of two.
-L +1G
Add 1 GiB to the logical volume's size.
-l +100%FREE
Alternative to -L: consume ALL remaining free space in the volume group. Handy when the task says 'use the rest of the VG'.
One command, and the output shows both layers changed: the LV grew (extents 768 → 1024) and the filesystem grew (data blocks 786432 → 1048576). df -h /datadir would immediately show the larger size. This is why -r is the answer to reach for first.
Grew the volume but not the filesystem
Run lvextend -L +1G without -r and forget the resize step, and df still shows the filesystem full while lvs shows the volume is bigger. The space is real but unused. Either always pass -r, or never forget the matching xfs_growfs/resize2fs. On the exam, verify with df -h, not lvs — df is what proves the filesystem actually grew.
Check yourself
Which single flag added to lvextend also resizes the filesystem so you don't need a separate xfs_growfs or resize2fs?
Stratis: start the daemon first, then build a pool
Create Stratis pooled storage and avoid the dead-daemon trap.
Stratis is Red Hat's newer storage system that layers easy pooled management over the proven device-mapper and XFS plumbing underneath. The model is simpler than LVM's: you give a pool one or more block devices, then create filesystems inside the pool that thin-provision and grow on demand — no manual lvextend needed.
But Stratis is driven by a background service, `stratisd`. The stratis command-line tool is just a client that talks to that daemon. If the daemon isn't running, every stratis command fails.
Why it matters
Unlike parted or lvm, which talk to the kernel directly, the stratis CLI is a thin client over a running stratisd service. That's the design — the daemon owns the pool state — but it means step zero of any Stratis task is making sure stratisd is up and enabled, just like configuring any other service.
```
$ sudo systemctl enable --now stratisd
```
enable
Set stratisd to start at boot — so your pools come back after a reboot.
--now
Also start it immediately, so you can use stratis right now.
Silent success. stratisd is now running and will return after a reboot. Skipping this is the classic Stratis mistake — see the callout below. (You may also need sudo dnf install -y stratisd stratis-cli first if the tools aren't present.)
Example — not runnable on your lab box
```
$ sudo stratis pool create datapool /dev/vdc
```
Creates a pool named datapool backed by the block device /dev/vdc. Stratis takes over the whole device — you don't pre-partition or pre-format it. Silent success; verify with sudo stratis pool list.
Example — not runnable on your lab box
```
$ sudo stratis filesystem create datapool data1
```
Creates a filesystem data1 inside datapool. It appears at /dev/stratis/datapool/data1 and is XFS underneath. You then mount that path — and for a persistent mount you add it to /etc/fstab with the x-systemd.requires=stratisd.service option so it mounts only after the daemon is up.
Example — not runnable on your lab box
```
$ sudo stratis filesystem list
```
```
Pool Name  Name   Used     Created            Device                     UUID
datapool   data1  546 MiB  Jun 23 2026 11:40  /dev/stratis/datapool/data1  a1b2c3d4...
```
Confirms the filesystem exists and shows its device path. The Used figure grows as you write data — Stratis filesystems are thin-provisioned, so they claim space from the pool only as needed rather than reserving it all up front.
stratisd not running
Run stratis pool create before starting the daemon and you get an error like 'Error: ... unable to connect to the daemon'. The fix is never to re-run the command harder — it's sudo systemctl enable --now stratisd first. Make this reflex: no `stratis` command works until `stratisd` is up.
Check yourself
What service must be running and enabled before any stratis pool create or stratis filesystem create command will work?
XFS rules: grow online, never shrink
Internalize the two XFS facts the exam reliably tests.
XFS is the default filesystem on RHEL, so its quirks show up everywhere in this material. Two facts matter more than any other:
- Growing XFS is online and safe. You can xfs_growfs (or lvextend -r) a mounted, in-use XFS filesystem with no downtime. That's why the LVM-grow step worked without unmounting.
- XFS cannot be shrunk. At all. There is no xfs_shrink. The tool simply does not exist. If a task needs a smaller filesystem, you must back up the data, recreate a smaller filesystem, and restore — there's no in-place path.
Don't try to shrink XFS
ext4 can shrink (resize2fs with a smaller size, while unmounted), so people assume XFS can too. It can't — and there's no flag, no workaround, no daemon to start. If you grew a volume too far, you can't claw it back by shrinking the XFS. Choose sizes deliberately when the filesystem is XFS.
```
$ findmnt -t xfs
```
```
TARGET   SOURCE                      FSTYPE OPTIONS
/        /dev/mapper/rhel-root       xfs    rw,relatime,attr2,inode64
/datadir /dev/mapper/datavg-datalv   xfs    rw,relatime,attr2,inode64
```
-t xfs
Filter to only XFS mounts, so you can see at a glance which filesystems follow the grow-only rule.
Every filesystem listed here is XFS, which means every one of them can be grown live but none can be shrunk. findmnt is the clean way to see mount source, type, and options together — better than raw mount output.
Check yourself
A task asks you to make a mounted XFS filesystem SMALLER. What's the correct response?
Try it in your live terminal
Inspect real storage state with safe, read-only commands.
You have a real root shell to your right. These commands are inspection-only — they don't create or destroy anything — so run them freely. The goal is to read the current storage layout fluently, because every storage task starts with 'what do I have right now?'. (The create/grow commands above are the ones you'd run for real once you understand the layout.)
```
$ lsblk
```
The tree view of every block device: disks, their partitions, and the LVM/Stratis layers on top. Read it top-down to see what's a raw disk, what's partitioned, and what's already in use.
Example — not runnable on your lab box
```
$ sudo parted -l
```
Lists each disk's partition table, including whether it's gpt or msdos (MBR). This is how you confirm the table type before adding a partition.
```
$ sudo pvs; sudo vgs; sudo lvs
```
The three LVM summaries: physical volumes, volume groups, and logical volumes. Check vgs VFree to see if a volume group has room before you try to lvextend.
```
$ findmnt -t xfs
```
Every mounted XFS filesystem. Remember: each of these can be grown online, none can be shrunk.

Recap

Creating a partition isn't done until the kernel re-reads the table — partprobe (or reboot) makes the new device appear.
Choose GPT for new disks; MBR is the legacy fallback capped at 2 TiB and 4 primary partitions.
lvextend -r grows the volume AND the filesystem in one step — reach for it instead of the lvextend-then-growfs two-step.
Stratis is daemon-driven: start and enable stratisd before any pool or filesystem command will work.
XFS grows online and safely; XFS can never be shrunk — there is no shrink tool.

Task → the step people forget
Task	Core command	The easily-missed step / gotcha
New partition	`parted /dev/vdb mkpart ...`	`partprobe /dev/vdb` so the kernel sees `/dev/vdb1`
Grow an LV + its fs	`lvextend -r -L +1G /dev/vg/lv`	`-r` resizes the fs too; without it run `xfs_growfs`/`resize2fs`
Stratis pool/fs	`stratis pool create ...`	`systemctl enable --now stratisd` FIRST
Shrink XFS	(none — not possible)	XFS cannot shrink; back up, recreate smaller, restore
Inspect layout	`lsblk`, `pvs`/`vgs`/`lvs`, `findmnt`	Always read state before changing it

Local Storage: Partitions, Extending LVM, and Stratis

Why local storage is its own RHCSA skill

Cut a partition: GPT vs MBR, then make the kernel re-read it

Grow an LVM volume: lvextend -r does it in one move

Stratis: start the daemon first, then build a pool

XFS rules: grow online, never shrink

Try it in your live terminal