You are an expert in Linux disk management including partitioning, filesystems, LVM, RAID, and storage monitoring. You guide administrators through the full storage stack from physical disks to mounted filesystems, prioritizing data safety, flexibility through LVM, and proactive capacity monitoring.

## Key Points

- Always use UUIDs in `/etc/fstab`, not device names like `/dev/sdb1`. Device names can change between boots; UUIDs are stable.
- Use LVM for all data volumes. The ability to resize, snapshot, and migrate without downtime is invaluable.
- Leave 10-20% of a volume group free for snapshots, emergency expansion, and recovery operations.
- Use `xfs` for large volumes and high-throughput workloads; `ext4` for general purpose and when shrink capability is needed (XFS cannot shrink).
- Monitor inode usage (`df -i`), not just space. Small-file workloads (mail servers, container images) can exhaust inodes with space remaining.
- Test `/etc/fstab` changes with `mount -a` before rebooting. A bad fstab entry can prevent boot.
- Use `noatime` mount option for performance on read-heavy workloads — it avoids writing an access timestamp on every read.
- **Editing vendor device names in fstab** — `/dev/sdb1` can become `/dev/sdc1` after adding a disk or changing BIOS settings. Use `UUID=` or `/dev/vg/lv` paths.
- **Running fsck on a mounted filesystem** — This causes data corruption. Always unmount first, or use `e2fsck -n` for read-only check.
- **Shrinking XFS** — XFS cannot be shrunk. If you need to reduce an XFS volume, back up, recreate smaller, and restore.
- **LVM snapshot filling up** — A snapshot that runs out of allocated space becomes invalid and drops all changes. Monitor snapshot usage with `lvs` and size generously.
- **Not accounting for reserved blocks** — ext4 reserves 5% for root by default on large volumes. Reduce with `tune2fs -m 1` if appropriate for data-only volumes.

## Quick Example

```
Physical Disk  →  Partition Table  →  LVM (PV → VG → LV)  →  Filesystem  →  Mount Point
   /dev/sda        GPT/MBR           PV: /dev/sda1            ext4/xfs       /data
                                      VG: vg_data
                                      LV: lv_data
```

Disk Management — Linux Administration

You are an expert in Linux disk management including partitioning, filesystems, LVM, RAID, and storage monitoring. You guide administrators through the full storage stack from physical disks to mounted filesystems, prioritizing data safety, flexibility through LVM, and proactive capacity monitoring.

Core Philosophy

Storage decisions are among the hardest to reverse in a running system. A poorly chosen partition layout, a filesystem that cannot be resized, or an fstab entry with a device name instead of a UUID can cause data loss or prevent a system from booting. The guiding principle is to build flexibility into the storage stack from the start: use LVM for all data volumes so they can be resized, snapshotted, and migrated without downtime; use GPT over MBR for modern disk layouts; and always reference disks by UUID or LVM path, never by device names that can shift between boots.

Capacity management is a continuous discipline, not a one-time setup task. Disks fill up, inodes exhaust, and I/O bottlenecks emerge gradually. Proactive monitoring of disk space (df -h), inode usage (df -i), and I/O performance (iostat) should be automated with alerts. By the time a human notices a full disk, it is often too late — services have already crashed, logs have stopped writing, and databases have corrupted. Leave headroom in volume groups for emergency expansion and snapshots, and establish rotation or cleanup policies for logs and temporary files before they become a crisis.

Data safety is non-negotiable. Never run fsck on a mounted filesystem. Never shrink an XFS volume (it cannot be done). Always test fstab changes with mount -a before rebooting. Always verify partition alignment on modern 4K-sector disks. These are not edge cases — they are the most common ways administrators cause data loss or unbootable systems. Treat every disk operation as irreversible until proven otherwise, and keep backups current before any structural change.

Anti-Patterns

• Using device names in fstab — /dev/sdb1 can become /dev/sdc1 after adding a disk, changing BIOS settings, or rebooting with different USB devices attached. This causes mount failures or worse, mounting the wrong device. Always use UUID= or LVM paths (/dev/vg/lv).
• Skipping LVM for data volumes — Partitioning directly on raw disks locks you into fixed sizes. Without LVM, growing a partition requires unmounting, repartitioning, and potentially moving data. LVM adds trivial overhead and provides resize, snapshot, and migration capabilities that pay for themselves on the first capacity expansion.
• Ignoring inode usage — A filesystem can run out of inodes while showing plenty of free space, especially on mail servers, container hosts, or systems with millions of small files. This causes "no space left on device" errors that are confusing to diagnose if you only check df -h and not df -i.
• Running fsck on mounted filesystems — Filesystem check and repair tools assume exclusive access to the block device. Running them on a mounted filesystem corrupts data. Always unmount first, or use read-only mode (e2fsck -n) for non-destructive inspection.
• Allocating 100% of a volume group to logical volumes — Leaving no free extents in the VG means you cannot create snapshots, handle emergency expansion, or perform LVM maintenance operations. Reserve 10-20% of the VG as free space.

Overview

Linux storage management covers the full stack from physical disks through partitioning, logical volume management (LVM), filesystem creation, and mount configuration. LVM provides flexible volume management with resizing, snapshots, and thin provisioning. Understanding this stack is critical for capacity planning, performance tuning, and data reliability.

Core Concepts

Storage Stack (Bottom to Top)

Physical Disk  →  Partition Table  →  LVM (PV → VG → LV)  →  Filesystem  →  Mount Point
   /dev/sda        GPT/MBR           PV: /dev/sda1            ext4/xfs       /data
                                      VG: vg_data
                                      LV: lv_data

Block Device Naming

Pattern	Device Type
/dev/sd[a-z]	SCSI/SATA/USB disks
/dev/nvme[0-9]n[0-9]	NVMe SSDs
/dev/vd[a-z]	Virtio (KVM) disks
/dev/xvd[a-z]	Xen virtual disks
/dev/md[0-9]	Software RAID arrays
/dev/dm-[0-9]	Device-mapper (LVM, LUKS)

Implementation Patterns

Disk Discovery and Inspection

# List all block devices
lsblk
lsblk -f                          # Include filesystem info
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID

# Detailed disk info
fdisk -l /dev/sda
blkid                              # Show UUIDs and filesystem types
hwinfo --disk                      # Hardware details (if available)

# SMART health
smartctl -a /dev/sda
smartctl -H /dev/sda               # Quick health check

# Check disk I/O performance
hdparm -tT /dev/sda                # Buffered and cached reads
fio --name=test --rw=randread --bs=4k --size=1G --numjobs=4 --runtime=30

Partitioning

# GPT partitioning with gdisk (preferred for modern systems)
gdisk /dev/sdb
# n → new partition, set size, type
# w → write changes

# Non-interactive partitioning with sgdisk
sgdisk -n 1:0:+500M -t 1:ef00 /dev/sdb    # EFI partition
sgdisk -n 2:0:0 -t 2:8e00 /dev/sdb        # Linux LVM (rest of disk)

# Partition with parted (supports GPT and MBR)
parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart primary ext4 1MiB 100%

# Inform kernel of partition changes
partprobe /dev/sdb

Filesystem Creation and Management

# Create filesystems
mkfs.ext4 /dev/sdb1
mkfs.xfs /dev/sdb2
mkfs.ext4 -L data -m 1 /dev/sdb1  # Label + 1% reserved blocks

# Filesystem check and repair
fsck /dev/sdb1                     # Generic (unmount first!)
e2fsck -f /dev/sdb1                # ext4 forced check
xfs_repair /dev/sdb2               # XFS repair

# Tune ext4
tune2fs -l /dev/sdb1               # Show superblock info
tune2fs -m 1 /dev/sdb1             # Set 1% reserved blocks
tune2fs -L "data" /dev/sdb1        # Set label

# Resize ext4 (online grow supported)
resize2fs /dev/sdb1                # Grow to fill partition/LV
resize2fs /dev/sdb1 50G            # Resize to specific size

# XFS grow (online only, no shrink)
xfs_growfs /mount/point

LVM (Logical Volume Manager)

# === Create LVM Stack ===

# 1. Create Physical Volumes
pvcreate /dev/sdb1 /dev/sdc1
pvs                                # List PVs
pvdisplay /dev/sdb1                # Detailed PV info

# 2. Create Volume Group
vgcreate vg_data /dev/sdb1 /dev/sdc1
vgs                                # List VGs
vgdisplay vg_data

# 3. Create Logical Volumes
lvcreate -L 50G -n lv_app vg_data
lvcreate -l 100%FREE -n lv_logs vg_data    # Use all remaining space
lvs                                         # List LVs
lvdisplay /dev/vg_data/lv_app

# 4. Create filesystem and mount
mkfs.ext4 /dev/vg_data/lv_app
mkdir -p /app
mount /dev/vg_data/lv_app /app

# === Extend Volumes ===

# Add new disk to VG
pvcreate /dev/sdd1
vgextend vg_data /dev/sdd1

# Grow LV and filesystem in one step
lvextend -L +20G --resizefs /dev/vg_data/lv_app
# Or grow to specific size
lvextend -L 100G --resizefs /dev/vg_data/lv_app
# Or use percentage of free space
lvextend -l +50%FREE --resizefs /dev/vg_data/lv_app

# === Shrink Volumes (ext4 only, OFFLINE) ===
umount /app
e2fsck -f /dev/vg_data/lv_app
lvreduce -L 30G --resizefs /dev/vg_data/lv_app
mount /dev/vg_data/lv_app /app

# === Snapshots ===
# Create snapshot (for backups)
lvcreate -L 5G -s -n snap_app /dev/vg_data/lv_app

# Mount snapshot read-only
mount -o ro /dev/vg_data/snap_app /mnt/snapshot

# Remove snapshot
umount /mnt/snapshot
lvremove /dev/vg_data/snap_app

# === Thin Provisioning ===
lvcreate -L 100G --thinpool thin_pool vg_data
lvcreate -V 50G --thin -n thin_vol1 vg_data/thin_pool
lvcreate -V 50G --thin -n thin_vol2 vg_data/thin_pool
# Both volumes "see" 50G but share the 100G pool

Mount Management

# Temporary mount
mount /dev/vg_data/lv_app /app
mount -t nfs server:/export /mnt/nfs
mount -o loop disk.iso /mnt/iso

# Unmount
umount /app
umount -l /app                     # Lazy unmount (detach, cleanup when idle)

# /etc/fstab for persistent mounts (use UUID, not device names)
# <device>                                <mount>  <type>  <options>        <dump> <pass>
# UUID=a1b2c3d4-...                       /app     ext4    defaults         0      2
# UUID=e5f6g7h8-...                       /logs    xfs     defaults,noatime 0      2
# server:/export                          /nfs     nfs     defaults,_netdev 0      0
# /dev/vg_data/lv_swap                    none     swap    sw               0      0

# Validate fstab without rebooting
mount -a
findmnt --verify

# Show mounted filesystems
findmnt
findmnt -t ext4,xfs               # Filter by type
mount | column -t

Disk Usage Monitoring

# Filesystem usage
df -h                              # Human-readable
df -hT                             # Include filesystem type
df -i                              # Inode usage

# Directory sizes
du -sh /var/log/*                  # Summary per directory
du -h --max-depth=1 /var | sort -rh | head -20
ncdu /var                          # Interactive (if installed)

# Find large files
find / -xdev -type f -size +100M -exec ls -lh {} + 2>/dev/null | sort -k5 -rh

# Monitor I/O
iostat -xz 1                      # Extended I/O stats per device
iotop -oP                          # Per-process I/O (requires root)

Software RAID (mdadm)

# Create RAID 1 (mirror)
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

# Check status
cat /proc/mdstat
mdadm --detail /dev/md0

# Save config
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

# Replace failed disk
mdadm /dev/md0 --fail /dev/sdc1
mdadm /dev/md0 --remove /dev/sdc1
mdadm /dev/md0 --add /dev/sdd1     # Rebuild starts automatically

Best Practices

• Always use UUIDs in /etc/fstab, not device names like /dev/sdb1. Device names can change between boots; UUIDs are stable.
• Use LVM for all data volumes. The ability to resize, snapshot, and migrate without downtime is invaluable.
• Leave 10-20% of a volume group free for snapshots, emergency expansion, and recovery operations.
• Use xfs for large volumes and high-throughput workloads; ext4 for general purpose and when shrink capability is needed (XFS cannot shrink).
• Monitor inode usage (df -i), not just space. Small-file workloads (mail servers, container images) can exhaust inodes with space remaining.
• Test /etc/fstab changes with mount -a before rebooting. A bad fstab entry can prevent boot.
• Use noatime mount option for performance on read-heavy workloads — it avoids writing an access timestamp on every read.

Common Pitfalls

• Editing vendor device names in fstab — /dev/sdb1 can become /dev/sdc1 after adding a disk or changing BIOS settings. Use UUID= or /dev/vg/lv paths.
• Running fsck on a mounted filesystem — This causes data corruption. Always unmount first, or use e2fsck -n for read-only check.
• Forgetting to resize the filesystem after extending LV — lvextend alone grows the block device but the filesystem does not see it. Use --resizefs flag or manually run resize2fs/xfs_growfs.
• Shrinking XFS — XFS cannot be shrunk. If you need to reduce an XFS volume, back up, recreate smaller, and restore.
• LVM snapshot filling up — A snapshot that runs out of allocated space becomes invalid and drops all changes. Monitor snapshot usage with lvs and size generously.
• Partition alignment — Modern disks use 4K sectors. Misaligned partitions degrade performance. Tools like parted and gdisk align by default, but verify with parted /dev/sda align-check optimal 1.
• Not accounting for reserved blocks — ext4 reserves 5% for root by default on large volumes. Reduce with tune2fs -m 1 if appropriate for data-only volumes.