Partitions, file systems, and disk layout for a server

Why this matters

The hardware domain ended with disks in bays and arrays presented to the server. This lesson starts the administration domain at the point where the operating system meets that storage: how disks are divided, what file system goes on each part, and how the layout is arranged so it can grow and survive.

Disk layout is one of the few decisions that is hard to change later. A partition style that cannot address the disk, a file system that cannot be shrunk, or an operating system that shares a volume with fast-growing logs will all work on day one and cause an outage on day four hundred.

The lesson

MBR against GPT, and the limits that decide between them

A disk's partition table records how it is divided into partitions. There are two styles.

MBR (Master Boot Record) is the older style, stored in the disk's first sector. Its limits are the ones that matter:

• disks can be addressed only up to 2 TiB with standard 512-byte sectors;
• at most four primary partitions, or three plus an extended partition holding logical partitions;
• the partition table exists in one copy, so damage to that sector can make the whole disk unreadable;
• it goes with legacy BIOS booting.

GPT (GUID Partition Table) is part of the UEFI specification and removes those limits:

• disk sizes far beyond anything in use today;
• up to 128 partitions by default in Windows, with no primary and extended distinction;
• a backup copy of the partition table at the end of the disk, and checksums to detect corruption;
• it is required for UEFI booting.

For any new server, GPT is the default choice, and any disk over 2 TiB must use it. Converting an existing disk between the styles usually requires it to be empty; Windows provides the mbr2gpt tool specifically to convert a system disk without losing data.

NTFS, ReFS, ext4 and XFS, and what each is for

A file system organises data within a partition. Server+ expects you to recognise four and know what each is for.

• NTFS is the standard Windows file system. It supports permissions (access control lists), encryption, compression, quotas and journaling, and it is the only choice for a Windows system volume.
• ReFS (Resilient File System) is a Windows Server file system designed for integrity at scale. It checksums data and metadata to detect corruption and, on mirrored Storage Spaces, can repair it automatically. It is well suited to virtual machine storage and backup repositories. It cannot be used as the boot volume and lacks some NTFS features, such as file-level encryption and compression.
• ext4 is the long-standing default Linux file system: journaling, mature and well supported by every tool.
• XFS is a high-performance journaling file system that handles very large files and heavy parallel workloads well. It is the default on Red Hat Enterprise Linux and its derivatives. XFS can be grown but not shrunk, whereas ext4 can be shrunk, offline.

One more appears on every UEFI system: the EFI system partition, a small partition formatted as FAT32 that holds the boot loaders the firmware starts.

Journaling, shared by all four main file systems, records changes before committing them, so that after a crash or power loss the file system can be brought back to a consistent state quickly instead of scanning the whole disk.

Separate volumes for the OS, data and logs, and why

A server should not keep everything on one volume. A common layout separates:

• the operating system,
• application data,
• logs, and sometimes temporary files.

The main reason is containment. Logs and data grow, sometimes suddenly. If they share a volume with the operating system and fill it, the operating system itself can fail: services cannot write, updates cannot install, and the server may stop working. On a separate volume, a runaway log fills its own volume and the operating system keeps running.

Separation also allows each volume to be treated differently: data on a RAID 10 array for performance, logs on storage suited to sequential writes, and the operating system on a small mirrored pair, as the RAID lesson recommended. It means the operating system can be rebuilt or restored without touching the data. On Linux, directories such as /var, /home and /tmp are often given their own partitions for the same reasons, and so that they can be mounted with restrictive options such as preventing programs from running from /tmp.

Volume managers -- LVM and Storage Spaces -- and growing a volume

A volume manager puts a layer between physical disks and the volumes the operating system uses, so that volumes can span disks and be resized.

On Linux, LVM (Logical Volume Manager) has three layers: physical volumes (disks or partitions), which are pooled into a volume group, from which logical volumes are carved. On Windows, Storage Spaces pools physical disks into a storage pool, from which virtual disks are created with a chosen resiliency: simple, mirror or parity.

Growing a volume follows the same pattern on both:

1. add capacity, such as a new disk, and add it to the volume group or pool;
2. extend the logical volume or virtual disk;
3. grow the file system to fill the larger volume, for example with resize2fs for ext4 or xfs_growfs for XFS on Linux, or Extend Volume in Windows.

Missing the third step is a common mistake: the volume is bigger but the file system still reports the old size. Most file systems can be grown while mounted and in use. Shrinking is much riskier, and XFS cannot be shrunk at all, so plan sizes with growth, not shrinkage, in mind.

Mount points and drive letters, and keeping them stable

Operating systems attach volumes to the file hierarchy in different ways.

Windows assigns volumes drive letters, which run out at 26 and are awkward for servers with many volumes. It can also mount a volume into an empty NTFS folder, a mount point, so a volume appears as a directory such as D:\Data\Archive with no letter of its own.

Linux mounts every volume into a single directory tree, and the file /etc/fstab lists what to mount where at boot. The key rule is to identify volumes by UUID or label, not by device name. Device names such as /dev/sdb are assigned in the order disks are detected, and adding a disk or changing a controller can change them. An fstab entry that names /dev/sdb1 can then mount the wrong volume, or fail and stop the server from booting. A UUID stays with the file system wherever the disk appears. For volumes the server can live without, the nofail option lets it boot even if they are missing.

The same principle applies on Windows: applications, shares and scripts that refer to a drive letter break if the letter changes, so drive letters on a server should be assigned deliberately and left alone.