Historically, a partition size is static. This requires a system installer to have to consider not the question of "how much data will I store on this partition", but rather "how much data will I *EVER* store on this partition". When a user runs out of space on a partition, they either have to re-partition (which may involve an entire operating system reload) or use kludges such as symbolic links.
The notion that a partition was a sequential series of blocks on a physical disc has since evolved. Most Unix-like systems now have the ability to break up physical discs into some number of units. Storage units from multiple drives can be pooled into a "logical volume", where they can be allocated to partitions. Additionally, units can be added or removed from partitions as space requirements change.
This is the basis of a Logical Volume Manager (LVM).
For example, say that you have a 1GB disc and you create the "/home" partition using 600MB. Imagine that you run out of space and decide that you need 1GB in "/home". Using the old notion of partitions, you'd have to have another drive at least 1GB in size. You could then add the disc, create a new /home, and copy the existing data over.
However, with an LVM setup, you could simply add a 400MB (or larger) disc, and add it's storage units to the "/home" partition. Other tools allow you to resize an existing file-system, so you simply resize it to take advantage of the larger partition size and you're back in business.
As a very special treat, LVM can even make 'snapshots' of itself which enable you to make backups of a non-moving target. We return to this exciting possibility, which has lots of other real-world applications, later on.
In the next section we explain the basics of LVM, and the multitude of abstractions it uses.