Storage pooling and logical capacity

Storage pooling presents capacity from several devices through logical storage, while allocation and redundancy remain separate choices.

A storage pool groups physical capacity so software can present logical storage without treating every drive as a separate library location. The pool may provide virtual disks, file-system datasets or another managed arrangement.

Pooling answers where capacity is managed. The chosen layout answers how data are distributed and protected. One large visible volume does not prove that it can survive a drive failure.

Physical space and advertised space

An original example starts with 20 TB of usable physical pool capacity after the selected layout's overhead:

Virtual disk A advertises 15 TB
Virtual disk B advertises 15 TB
Total advertised capacity: 30 TB
Physical pool capacity:    20 TB

With thin provisioning, the pool need not allocate every advertised byte immediately. Both virtual disks can appear spacious while their combined actual allocation approaches the shared physical limit.

Quantity What it describes
Physical pool capacity Space available in the underlying pool
Logical capacity Space presented to a virtual disk or dataset
Allocated space Physical capacity currently consumed
Reservation Capacity held for a particular purpose under the implementation's rules

An Emby recording can run out of allocatable pool space even when its logical volume's displayed limit is larger. Quotas, reservations and snapshots can further influence the available amount.

Combining devices does not define a copy count

Microsoft Storage Spaces separates a pool from the virtual disks and their resiliency configurations. OpenZFS separates pools, device groupings and datasets. These are examples of layered storage management, not interchangeable configuration formats.

A simple or striped arrangement can aggregate capacity without redundant copies. A mirrored or parity arrangement gives up some raw capacity for a stated failure tolerance. Different-sized devices and expansion rules affect the resulting usable space.

The relevant question for a media server is which physical failures affect the logical location it uses. Several logical volumes backed by the same pool can share one underlying failure domain.

Expansion also has a layout

Adding a device does not universally mean that every existing block is redistributed evenly or that every redundancy group expands in the same way. Some systems rebalance, some add a new grouping, and some require a particular supported expansion procedure.

Keep the library's stable path separate from the pool's physical allocation. The storage system can change its device arrangement while presenting the same pathname, but the server still depends on the resulting capacity, access and recovery behavior.

See Also

References