Skip to main content

Proxmox ZFS & Hardware RAID Capacity Calculator

Calculate net usable Proxmox VE ZFS capacity, padding loss, slop space, 80% safe ceiling, ARC RAM, and zpool create CLI script.

Input Parameters

Try Example:

Calculation Results

totalDrives
6
driveSize
4
unit
TB
topology
raidz2
mediaType
ssd
mediaLabel
Enterprise SSD
vdevCount
1
ashiftVal
12
recordKiB
128
poolName
rpool-data
rawTotalTB
24
rawTotalTiB
21.83
standardRaidUsableTB
16
standardRaidUsableTiB
14.55
parityAndSpareLossTB
8
paddingLossTB
0.45
slopSpaceTB
0.1374
zfsNetUsableTB
15.41
zfsNetUsableTiB
14.02
safeUsableTB
12.33
safeUsableTiB
11.21
faultToleranceText
2 drive per VDEV bersamaan
speedReadGain
4×
speedWriteGain
1×
estReadIops
32000
estWriteIops
6800
minArcRamGB
26
recommendedRamGB
32
warningMessage
undefined
RouterOS Script
# =====================================================================
# InfraCalc.id — ZFS Pool untuk Proxmox VE | Topologi: RAIDZ2 | 6 Drive (24 TB Raw)
# Kapasitas Bersih ZFS: 15.41 TB (14.02 TiB) | Batas Aman 80%: 12.33 TB (11.21 TiB)
# Ganti ID DISK dengan ID asli dari: ls -l /dev/disk/by-id/ (hindari nama /dev/sdX)
# =====================================================================

# 1. Buat ZFS Storage Pool di Terminal Proxmox VE
zpool create -f -o ashift=12 -O compression=zstd -O acltype=posixacl -O xattr=sa -O normalization=formD rpool-data \
  raidz2 /dev/disk/by-id/nvme-DISK_1 /dev/disk/by-id/nvme-DISK_2 /dev/disk/by-id/nvme-DISK_3 /dev/disk/by-id/nvme-DISK_4 /dev/disk/by-id/nvme-DISK_5 /dev/disk/by-id/nvme-DISK_6

# 2. Rekomendasi Dataset Options untuk Proxmox VM & Container
zfs set recordsize=128k rpool-data
zfs set atime=off rpool-data

# 3. Verifikasi Status Pool
zpool status rpool-data
zfs list rpool-data

How to Use This Tool

  1. Select your drive count, individual disk capacity (TB or GB), and target ZFS topology (Mirror / RAID 10, RAIDZ1, RAIDZ2, or RAIDZ3).
  2. Specify the pool ashift (ashift 12 for modern 4K disks), dataset recordsize (128 KiB standard, 16 KiB database, or 1024 KiB backup), and storage media type (NVMe, SSD, or HDD).
  3. Inspect the net usable ZFS capacity, the 80% performance threshold, estimated IOPS, and ARC RAM requirements, then copy the zpool create command into your Proxmox VE shell.

Worked Example: Proxmox Standard 6 × 4 TB RAIDZ2

Computed example: An array of 6 drives × 4 TB (24 TB / 21.83 TiB raw) in RAIDZ2 yields a net ZFS usable capacity of 15.41 TB (14.02 TiB) after parity, padding loss (0.45 TB), and slop space (0.1374 TB). The 80% safe capacity ceiling is 12.33 TB (11.21 TiB) with a minimum ARC RAM requirement of 26 GB (host recommendation 32 GB).

Example Input
{
  "drives": 6,
  "driveSize": 4,
  "unit": "TB",
  "topology": "raidz2",
  "ashift": "12",
  "recordsize": "128",
  "mediaType": "ssd",
  "poolName": "rpool-data"
}
Calculated Output
totalDrives:
6
driveSize:
4
unit:
TB
topology:
raidz2
mediaType:
ssd
mediaLabel:
Enterprise SSD
vdevCount:
1
ashiftVal:
12
recordKiB:
128
poolName:
rpool-data
rawTotalTB:
24
rawTotalTiB:
21.83
standardRaidUsableTB:
16
standardRaidUsableTiB:
14.55
parityAndSpareLossTB:
8
paddingLossTB:
0.45
slopSpaceTB:
0.1374
zfsNetUsableTB:
15.41
zfsNetUsableTiB:
14.02
safeUsableTB:
12.33
safeUsableTiB:
11.21
faultToleranceText:
2 drive per VDEV bersamaan
speedReadGain:
4×
speedWriteGain:
1×
estReadIops:
32000
estWriteIops:
6800
minArcRamGB:
26
recommendedRamGB:
32
warningMessage:
undefined

Core Concept & Engineering Notes

OpenZFS on the Proxmox VE virtualization platform is an advanced enterprise file system and logical volume manager combining RAID data redundancy with cryptographic end-to-end data integrity through automatic self-healing checksums. Unlike legacy hardware RAID controllers that estimate net capacity by simply subtracting dedicated parity disks, OpenZFS incorporates internal allocation dynamics that dictate actual usable capacity for virtual machines and LXC containers. The first structural overhead is sector alignment padding loss. When configuring RAIDZ topologies with an ashift of 12 (4 KiB native sectors) or ashift of 13 (8 KiB sectors), dataset records are partitioned across vdev member drives in strict multiples of the underlying sector size. Sub-optimal drive counts or small record sizes (such as 8 KiB or 16 KiB optimized for transactional databases) can introduce 4% to 8% in sector padding inefficiencies. The second layer is OpenZFS Slop Space Allocation, a reserved pool margin representing 1/32 (3.125%) of total raw storage (capped at 128 GiB) reserved by the ZFS kernel to guarantee that copy-on-write operations, file deletions, and snapshot destaging complete without deadlocking an exhausted pool. The third and most operationally vital constraint is the 80% Safe Capacity Rule. Because ZFS relies on a Copy-on-Write (CoW) transactional engine, operating a storage pool beyond 80% of its physical capacity degrades contiguous free space into fine fragmentation. This collapses write IOPS throughput and escalates I/O wait latency across all guest VMs. This calculator accounts for all these overhead layers, computes recommended host Adaptive Replacement Cache (ARC) memory requirements, and generates production-grade zpool creation scripts referencing persistent disk IDs.

How It Was Calculated (Formulas & Steps)

Frequently Asked Questions (FAQ)

Why is the usable ZFS capacity in Proxmox smaller than standard hardware RAID?

Beyond the ~9% difference between decimal TB (10^12) and binary TiB (2^40) reported by the OS, ZFS reserves Slop Space (1/32 of pool size, up to 128 GiB), sector padding alignment margins on RAIDZ, and internal copy-on-write metadata structures.

Why is it strongly advised never to fill a ZFS pool beyond 80% capacity?

Because ZFS is a Copy-on-Write filesystem. When free capacity drops below 20%, the kernel switches from a high-speed first-fit block allocator to an exhaustive best-fit allocator, escalating fragmentation and drastically depressing write performance.

How much RAM does Proxmox VE require for the ZFS ARC cache?

The standard sizing guideline is 2 GB base RAM for the Proxmox OS plus 1 GB of RAM per 1 TB of raw pool capacity. If inline deduplication is enabled, RAM requirements jump dramatically to at least 5 GB per 1 TB of storage to hold the DDT table in memory.

Why should we always use `/dev/disk/by-id/` rather than `/dev/sda` device names in Proxmox?

Linux device letters such as `/dev/sda` or `/dev/sdb` are dynamically assigned during kernel boot and can shuffle upon reboot or controller port re-cabling. Using persistent `/dev/disk/by-id/` paths binds drives to their permanent serial numbers, preventing failed pool imports.

References & Notes

Last updated: Content Status: Draft (Pending Editorial Review)

Note: Results above are mathematical estimates based on standard formulas. Always verify against official vendor documentation and site conditions before production deployment.