A.1 NSS Partitions, Pools, and Volumes

For a complete discussion about NSS, refer to the OES 11 SP2: NSS File System Administration Guide for Linux.

This section presents the following:

Figure A-1 Partitions, Pools, and Volumes

Partitions, Pools, and Volumes.

Reference Letter

Explanation

Partitions are physical sections on a hard disk that are managed by a file system. The most common file systems on Linux servers today are Ext3, Reiser, and XFS.

The boot partition on your getting-started lab server is managed by the Ext3 file system. The files and configuration data it contains start the server.

The swap partition is managed by a file system that swaps information between memory and the disk, thus augmenting the RAM installed in the server.

The / (root) partition on your server is managed by Ext3 and stores all the getting-started lab server’s system and data files, including OES services, eDirectory, and so on.

OES servers can also include NSS partitions. These are similar to Linux partitions in that they occupy physical disk space, but they are also significantly different in a number of ways.

  1. You create the Linux partitions shown in this illustration during OES 11 SP2 installation.

    You always create NSS partitions after the OES installation is completed.

  2. You create Linux partitions by allocating an amount of disk space to the partition and assigning it a mount point, such as /boot, /home, or / (root).

    You create NSS partitions by creating an NSS pool (see G) and assigning space on the server’s storage devices (physical or logical disks) to the pool. The space you assign to a given pool from a specific disk is designated on that disk as an NSS partition.

  3. On Linux, files are stored on a partition.

    On NSS, files are stored in an NSS volume—a logical mechanism that can span multiple NSS partitions and also the devices that contain them.

  4. On Linux, a partition is allocated a set amount of disk space on a single device. The amount of disk space that can be used is limited by the size of the partition.

    NSS volumes are not bound by individual partition or device sizes. Rather, they take disk space from their assigned NSS pool as needed.

  1. Additional disk space can be dynamically added to NSS pools as needed, and NSS volumes can grow dynamically in return as long as there is free space available in the pool, unless the volume size has been restricted by an eDirectory Admin user.

IMPORTANT:The illustration shows the NSS pool spanning NSS partitions on both the server’s primary hard disk and a second hard disk, which could be added later. The NSS pool contains an NSS volume (HOME_NSS in this case) that contains the NSS volume data (illustrated in red). The NSS pool also has free space that is not yet allocated to a volume (illustrated in white).

Free space and volume data aren’t necessarily distributed across all partitions, or distributed evenly as the graphic might imply. The NSS file system manages what each partition contains, independent of any administrative controls.

The NSS file system logically combines multiple partitions to form pools of space (up to 8 TB in size) that can span multiple devices.

In the illustration, POOL_LX contains two NSS partitions that are created from the unformatted space on both hard disks when the pool is created.

In some ways, NSS pools are like pools of water. The space from each partition is logically “poured” into an NSS pool and made available to the pool’s assigned volumes, such as HOME_NSS. Neither the volume nor the users with rights to access it know which physical partitions contain the disk space actually being used.

Of course, the NSS file system continues to track each partition below the surface, but from a logical standpoint, all of the disk space assigned to a pool is one continuous source of disk space.

The sole purpose of NSS pools is to provide storage space from which you can form one or more NSS volumes.

Your getting-started lab server contains a single NSS pool named POOL_LX with a single NSS volume named HOME_NSS. The pool’s free space is unallocated until used.

The instructions for creating the HOME_NSS volume leave the option set to have the volume grow to the pool size. As additional space is needed, the HOME_NSS volume automatically expands into the free space shown.

Free space in the pool is not reserved for the HOME_NSS volume; instead, space is allocated to HOME_NSS as needed. You can optionally add other volumes to the same pool and, in a sense, overbook the pool’s free space.

You can also grow the pool as needed by adding more NSS partitions to the pool.