Latest / Linux Server Admin with Fexingo: Sysadmin, Bash, and Server Engineering / How to Manage Linux Server Storage Pools with LVM
Transcript
- Lucas: So you're running a web server, and suddenly your root partition is at 97 percent utilization. The usual fix — find big logs, delete them, hope for the best — is a band-aid. What you really want is a storage system that can grow and shrink on demand. That's where LVM, Logical Volume Manager, comes in. Luna: And I've been that person deleting logs at 2 a.m. hoping Apache doesn't crash. So LVM is the thing that would have saved me? Lucas: Exactly. LVM is a layer between your physical disks and the filesystem that lets you treat storage like a pool. You can add disks, remove them, resize logical volumes, even take snapshots — all while the server is running. No reboots. Luna: If today's conversation gives you something usable, you know, the reason these episodes stay ad-free is listener support. It's a small thing that keeps us going — buy me a coffee dot com slash fexingo, if it feels right. Lucas: Yeah, that support really lets us dive into topics like this without worrying about sponsors. So, back to LVM — the core building blocks are physical volumes, volume groups, and logical volumes. Physical volumes are just disks or partitions you mark for LVM use. You run pvcreate on a raw disk like /dev/sdb, and it writes LVM metadata there. Luna: So that's step one: initialize the disk. Then you bundle them into a volume group? Lucas: Right. You create a volume group with vgcreate, say vgcreate my_vg /dev/sdb. That pools the space. Then within that group, you carve out logical volumes — lvcreate -L 50G -n my_lv my_vg. That gives you a block device at /dev/my_vg/my_lv, which you format and mount like any partition. Luna: But the real magic is when that partition fills up. You don't have to rebuild the server, you just extend the logical volume. Lucas: Yes. And that's a two-part process on most filesystems. First, extend the logical volume: lvextend -L +10G /dev/my_vg/my_lv. Then, resize the filesystem to match. For ext4, it's resize2fs; for XFS, it's xfs_growfs. And all of this happens live — no unmounting needed. Luna: Does that work for shrinking too? Because I've never quite trusted online shrinking. Lucas: Shrinking is trickier. LVM itself can shrink the logical volume with lvreduce, but many filesystems — especially XFS — don't support online shrinking at all. For ext4, you'd have to unmount, run e2fsck, shrink the filesystem with resize2fs, then shrink the LV. It's risky. I'd say most admins avoid shrinking and just over-provision or add more disks. Luna: So plan ahead, or add disks. That's manageable. What about snapshots? I've heard those are a game-changer for backups. Lucas: Snapshots are one of LVM's killer features. You create a snapshot of a logical volume with lvcreate --snapshot -L 5G -n snap_lv /dev/my_vg/my_lv. That gives you a point-in-time copy that's initially nearly empty — it uses copy-on-write. Any changes to the original get copied to the snapshot space first. So you can back up a consistent filesystem without downtime. Luna: But you have to allocate enough space for the snapshot, right? If the original changes a lot, the snapshot can fill up and become invalid. Lucas: Exactly. If you have a 100 GB volume that's mostly static, a 5 GB snapshot might be fine. But on a busy database server, changes can pile up fast. You need to monitor snapshot usage with lvs and set the snapshot size generously. Or better, use it for short-lived backups, not long-term snapshots. Luna: Good to know. Now, what about moving data between disks? Say you have an old slow disk and a new SSD. Can LVM help migrate without downtime? Lucas: Absolutely. You add the new disk as a physical volume with pvcreate, then add it to the volume group with vgextend. Then use pvmove to shift extents from the old disk to the new one. All while the volume is mounted and in use. Once the move is complete, you remove the old disk with vgreduce and pvremove. Luna: That's slick. But I've also heard LVM can add complexity. When would you not use it? Lucas: If you have a simple single-disk workstation and you don't expect to resize or snapshot, LVM adds overhead for no benefit. Also, some filesystems like ZFS or Btrfs have their own volume management built-in — you wouldn't layer LVM on top of them. And in some cloud environments, you can just detach and reattach volumes — LVM might be overkill. Luna: So it's a tool for servers that need flexibility. What about thin provisioning? I've seen that cause outages when people run out of pool space. Lucas: Thin provisioning is dangerous if you don't monitor it. With thin LVs, you can over-commit the volume group — allocate 1 TB of logical space on a 500 GB physical pool. The LVs think they have space, but when the pool fills, writes fail silently or freeze. You absolutely need to set dmeventd to monitor and alert, or use tools like lvchange --monitor to automatically extend thin pools when they hit a threshold. Luna: So it's like a storage team's version of an airplane — you can push the limits, but you have to watch the gauges. Lucas: Exactly. And to be fair, LVM has great monitoring tools. lvs shows you allocation, pvs shows physical disk usage, vgdisplay shows free extents. You can script alerts. The key is to treat LVM as an active part of your infrastructure, not something you set and forget. Luna: Alright, so walk me through a quick real-world scenario. I have a server with a 100 GB root volume on /dev/sda, and I plug in a new 500 GB SSD at /dev/sdb. I want to extend root without rebooting. Lucas: First, make sure the server boots with LVM — that usually means your /boot is on a separate partition outside LVM. Then, on the running system, partition /dev/sdb if needed, or use the whole disk. Run pvcreate /dev/sdb, then vgextend my_vg /dev/sdb. Now you have more physical space. Then extend the root logical volume: lvextend -L +450G /dev/my_vg/root. Finally, resize the filesystem: resize2fs /dev/my_vg/root. Done — your root is now 550 GB. Luna: And that's it? No reboot, no downtime? Lucas: No reboot. The filesystem is live the whole time. The only risk is if you run out of physical space while extending, but you just added a 500 GB disk, so you're fine. Luna: What about performance? Does LVM add any latency? Lucas: In practice, the overhead is negligible — we're talking microseconds per I/O. The metadata lookups are in memory. For almost any workload, the performance hit is invisible. The bigger factor is the underlying disk speed, not LVM. Luna: Good. So LVM gives you flexibility without sacrificing speed. I'm sold. One more thing: can I use LVM with RAID? Lucas: You can, but it's usually better to let hardware or mdadm handle RAID at the disk level, then present the RAID array as a single physical volume to LVM. LVM does have its own raid like features — mirroring and striping — but they're less common. For most use cases, you want the simplicity of RAID below LVM. Luna: Makes sense. So the typical stack: hardware RAID or mdadm RAID, then LVM on top, then filesystem. That's the server admin sweet spot. Lucas: Exactly. And if you're using LVM, commit to learning the commands: pvdisplay, vgdisplay, lvdisplay, pvscan, vgscan, lvscan. They're your dashboard. Once you're comfortable, LVM becomes one of those tools you wonder how you lived without. Luna: I'm definitely going to start using it on my next server build. Thanks for the walkthrough, Lucas. Lucas: Sure thing. And remember, monitor those thin pools. Luna: Always. See you next time.