Storage Sizing, IOPS & Filesystem Planning
Proper storage dimensioning is essential for maintaining sustained 24/7 video archiving without disk bottlenecks or IOPS starvation.
Storage Capacity Estimation Formula
To calculate the required storage capacity:
$$\text{Storage (GB)} = \frac{\text{Bitrate (Mbps)} \times 3600 \times 24 \times \text{Retention Days} \times \text{Cameras}}{8000}$$
Capacity Planning Reference Table
| Camera Count | Stream Resolution & Bitrate | 7 Days Retention | 14 Days Retention | 30 Days Retention |
|---|---|---|---|---|
| 10 Cameras | 1080p @ 2 Mbps (H.264) | ~1.5 TB | ~3.0 TB | ~6.5 TB |
| 25 Cameras | 1080p @ 2 Mbps (H.264) | ~3.8 TB | ~7.6 TB | ~16.2 TB |
| 50 Cameras | 2K @ 4 Mbps (H.265/H.264) | ~15.1 TB | ~30.2 TB | ~64.8 TB |
| 100 Cameras | 4K @ 8 Mbps (H.265) | ~60.5 TB | ~121.0 TB | ~259.2 TB |
Disk Throughput & IOPS Requirements
RUSEON Core utilizes a 2MB sliding window write mechanism with sync_file_range and FADV_DONTNEED, transforming thousands of small frame writes into smooth, sequential chunk flushes:
- Sequential Write Bandwidth: 100 cameras @ 4 Mbps generates a sustained 50 MB/s write load.
- IOPS Load: Because frames are coalesced into 2MB blocks before kernel flushing, 100 cameras require only ~25 IOPS of sequential block writes.
- Read Workload: Archive playback and timeline seeking generate random reads. A dedicated read cache ensures minimal impact on recording throughput.
Storage Tiering Architecture
Filesystem & Mount Recommendations (Linux)
Use XFS or ext4 for the recording partition:
bash
# Format volume with large inode allocation
sudo mkfs.ext4 -m 1 -O dir_index,extent /dev/sdb1
# Mount in /etc/fstab with write optimization flags
/dev/sdb1 /data/recordings ext4 noatime,nodiratime,data=ordered 0 2noatime,nodiratime: Eliminates access timestamp updates during playback.-m 1: Reduces reserved root super-user blocks from 5% to 1%, freeing valuable gigabytes for video retention.