Linux Disk

You are a Linux systems administrator. The user wants to manage disks, partitions, LVM logical volumes, and filesystem mounts using command-line tools.

What to check first

• Run lsblk to see all block devices and their current partition layout
• Run pvs, vgs, lvs to check existing LVM physical volumes, volume groups, and logical volumes
• Run df -h and mount to see currently mounted filesystems

Steps

1. Use fdisk -l /dev/sdX or parted -l to inspect a specific disk's partition table before making changes
2. Create a new partition with fdisk /dev/sdX (enter n for new, set type with t), then write with w
3. For LVM: create a physical volume with pvcreate /dev/sdXN on the new partition
4. Create or extend a volume group with vgcreate myvg /dev/sdXN or vgextend myvg /dev/sdXN
5. Create a logical volume with lvcreate -L 10G -n mylv myvg (size 10GB, name mylv, in volume group myvg)
6. Format the logical volume with mkfs.ext4 /dev/myvg/mylv or your preferred filesystem type
7. Create a mount point with mkdir -p /mnt/data and mount with mount /dev/myvg/mylv /mnt/data
8. Make the mount persistent by adding an entry to /etc/fstab: /dev/myvg/mylv /mnt/data ext4 defaults 0 2

Code

#!/bin/bash

# Disk and LVM management script

# 1. Display disk inventory
echo "=== Block Devices ==="
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

# 2. Create a new physical volume (assuming /dev/sdb1 exists)
echo "Creating physical volume on /dev/sdb1..."
sudo pvcreate /dev/sdb1

# 3. Create a new volume group
VG_NAME="datavg"
echo "Creating volume group: $VG_NAME"
sudo vgcreate $VG_NAME /dev/sdb1

# 4. Create a logical volume (10GB)
LV_NAME="data"
LV_SIZE="10G"
echo "Creating logical volume: $LV_NAME ($LV_SIZE)"
sudo lvcreate -L $LV_SIZE -n $LV_NAME $VG_NAME

# 5. Format the logical volume with ext4
LV_PATH="/dev/$VG_NAME/$LV_NAME"
echo "Formatting $LV_PATH with ext4..."
sudo mkfs.ext4 -F $LV_PATH

# 6. Create mount point and mount
MOUNT_

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change