Avoid the 5TB Disk Mounting Pitfalls That Trip Up 90% of Ops Engineers

Core rule: 2 TB is a hard limit for MBR

Traditional MBR partition tables can address at most 2 TB. Disks larger than 2 TB appear as 2 TB when partitioned with fdisk. Use a GPT partition table created with parted to expose the full capacity.

Full production‑grade mounting process (5 TB example)

Step 1 – Identify the correct disk

List block devices and locate the new data disk:

lsblk
# or
fdisk -l

System disk: /dev/sda (partitions sda1, sda2 etc.)

New 5 TB data disk: /dev/sdb (or /dev/vdb, /dev/nvme1n1 on cloud VMs); it has no partitions and its size matches the purchased 5 TB.

⚠️ All commands below assume the device is /dev/sdb ; replace it with the actual device name to avoid data loss.

Step 2 – Create a GPT partition with parted

Install parted if not present.

CentOS/RHEL: yum install -y parted Ubuntu/Debian: apt update && apt install -y parted Enter interactive mode targeting the new disk: parted /dev/sdb Execute the following commands inside parted (confirm warnings with yes):

# Create GPT label
mklabel gpt

# Create a single primary partition covering the whole disk
mkpart primary 0% 100%

# Exit
quit

Verify the partition table: lsblk Expect a /dev/sdb1 entry with a size close to 5 TB.

Step 3 – Format the filesystem (choose according to workload)

Formatting erases all data; double‑check the device name before proceeding.

ext4 – high compatibility, many small files – command: mkfs.ext4 /dev/sdb1 xfs – large disks, large files; default on CentOS, better performance – command: mkfs.xfs -f /dev/sdb1 💡 If the disk contains old partitions or residual data, add the -f flag to force XFS formatting.

Step 4 – Create a mount point and mount temporarily

Create the directory (commonly /data): mkdir -p /data Mount the partition: mount /dev/sdb1 /data Confirm the mount succeeded: df -h The output should list /dev/sdb1 mounted on /data with about 4.5 TB usable (normal binary‑decimal conversion loss).

Step 5 – Configure automatic mount at boot (use UUID)

Using the partition UUID is more reliable than a device name.

Retrieve the UUID: blkid /dev/sdb1 Copy the string inside UUID="...".

Edit /etc/fstab and append a line matching the chosen filesystem:

UUID=YOUR_UUID_VALUE  /data  ext4  defaults  0 0

or for XFS: UUID=YOUR_UUID_VALUE /data xfs defaults 0 0 Validate the new entry without rebooting: mount -a No output indicates success; any error means the entry must be corrected before restarting.

Run df -h again to ensure the mount is still active.

⚠️ After editing /etc/fstab , never reboot until mount -a succeeds , otherwise the system may become unbootable.

Six red‑flag tips for ops engineers

Never use fdisk on disks larger than 2 TB; always use parted with GPT.

Always double‑check the device name before partitioning or formatting to avoid wiping the system disk.

After any /etc/fstab change, run mount -a and confirm no errors before rebooting.

If the disk already contains data, skip partitioning and formatting; mount the existing partition directly.

Prefer UUID entries in /etc/fstab over raw device names to prevent mount failures caused by device‑name changes.

For SSDs, consider adding defaults,noatime to reduce write cycles and extend lifespan.