// Storage Planning

Edge AI Storage Layout and Ring Buffer Design: How to Size It Correctly

Last updated: March 2026

A production edge AI node needs more than "enough storage." This guide shows how to separate OS, models, logs, and video retention correctly, size ring buffers from bitrate and camera count, and avoid premature SSD wear.

Retention = size ÷ daily writes

80/90% cleanup hysteresis

NVMe + partition separation

TBW must match workload

Quick Answer

Separate OS, models, logs, and video into distinct partitions. The video partition operates as a ring buffer: fixed capacity, oldest data overwritten first. Size retention from bitrate × cameras × duty cycle. Verify SSD TBW matches your write load. Do this at deployment time, not after failure.

Use the formulas and partition sizing tables in this guide to calculate daily write volume, required retention, and drive endurance before hardware purchase.

Planning Takeaway

The biggest storage mistake in edge AI is treating video as "just more files." Continuous recording is a controlled-write system design problem. If OS, logs, model artifacts, and video share uncontrolled space, the node eventually fails from disk pressure or SSD wear. Explicit partition boundaries with fixed maximums prevent all major failure modes.

Who This Page Is For

Engineers sizing storage for Jetson or edge NVR nodes
Teams planning video retention windows
Operators trying to avoid OS overflow and SSD wear-out
Architects designing ring buffer behavior for multi-camera deployments
Anyone estimating partition sizes before hardware purchase

Why Storage Layout Matters

An edge AI node that writes video continuously has a dramatically different storage profile than a desktop or server. On a server, storage layout is largely an operational convenience. On an edge node, the wrong layout causes:

OS partition filled by video data, crashing the system
Log data consuming space allocated for video, causing recording gaps
Uncontrolled write growth exhausting SSD endurance ahead of schedule
Model storage growing (new model versions deployed) until space runs out

Explicit partition boundaries with fixed maximum sizes for each data category prevent all of these failure modes. Design the layout at provisioning time and enforce it.

Ring Buffer Logic

A ring buffer (circular buffer) for video operates on a simple principle: when the buffer fills, writing wraps around to the beginning, overwriting the oldest data. The buffer has a fixed maximum size, so total disk usage is bounded and predictable.

For video, this is typically implemented at the segment level rather than the byte level: video is written in fixed-duration segments (e.g., 1-minute or 5-minute files). The ring buffer manager deletes the oldest segment file when total used space exceeds the configured maximum. This is simpler and more robust than byte-level circular writes, especially for video codecs that require complete segment files for playback.

Segment-level ring buffer behavior:

Video is written to segments: cam1_20260221_1430.mp4, cam1_20260221_1431.mp4, etc.
A monitor process checks total video partition usage every N minutes.
When usage exceeds 90% of the partition maximum, oldest segments are deleted until usage drops below 80%.
This 80/90% hysteresis prevents thrashing (constant delete-write cycles).

Retention Calculations

Given a video partition size, calculate retention period:

Retention (days) = Partition size (GB) ÷ Daily write volume (GB/day)

Daily write volume for continuous recording:

Daily write (GB) = Bitrate (Mbps) × Camera count × 86400 ÷ 8 ÷ 1000

Examples:

Cameras	Bitrate/cam	Daily Write	500 GB partition	1 TB partition	2 TB partition
1	4 Mbps	43 GB/day	11.6 days	23 days	46 days
4	4 Mbps	172 GB/day	2.9 days	5.8 days	11.6 days
8	4 Mbps	345 GB/day	1.4 days	2.9 days	5.8 days
8	2 Mbps	172 GB/day	2.9 days	5.8 days	11.6 days
4	8 Mbps	345 GB/day	1.4 days	2.9 days	5.8 days

For event-triggered recording (e.g., record only when a detection event occurs), multiply daily write volume by the fraction of time recording is active. At 25% duty cycle, daily write volume drops by 75%, quadrupling retention at the same partition size.

For multi-camera or variable-bitrate deployments, use the Full Deployment Planner to validate retention windows across different scenarios before committing to a partition size.

Write Endurance Math

Write endurance determines how long the SSD will last under the ring buffer's sustained write load. Full derivation is covered in the SSD endurance guide; the key formula for quick sizing:

Drive life (years) = TBW ÷ (Daily writes × WAF × 365)

Where WAF (write amplification factor) is typically 1.2–1.5 for sequential video writes.

Example: 8 cameras at 4 Mbps continuous → 345 GB/day host writes × 1.3 WAF = 448 GB/day NAND wear. At 600 TBW drive: 600 ÷ (448 × 365 ÷ 1000) = 3.67 years. At 1200 TBW: 7.3 years.

For 8-camera continuous recording, a prosumer or enterprise NVMe rated 600 TBW minimum is required. Consumer drives at 300 TBW would last under 2 years at this write load.

Use the Storage Endurance tool to calculate drive life for your specific camera count, bitrate, and SSD model.

Partition Design

Recommended partition layout for a 2 TB NVMe on an 8-camera Jetson node:

Partition	Size	Filesystem	Purpose
OS root (/)	60 GB	ext4	JetPack, Docker, application binaries, OS
Models (/opt/models)	30 GB	ext4	TensorRT engines, ONNX files, model versioning
Logs (/var/log/inference)	40 GB	ext4	Structured inference logs, alert history, telemetry
Video ring buffer (/data/video)	1770 GB	ext4 or XFS	Camera segments, managed by ring buffer process
Unpartitioned (over-provision)	100 GB	—	SSD over-provisioning for wear leveling

Mount the video partition with noatime to avoid read-triggered metadata writes that add unnecessary write amplification. For XFS on high-write video partitions, logbufs=8 and logbsize=256k improve journal write efficiency.

How to use this in a real build

Calculate daily write volume first. Use bitrate, camera count, and duty cycle. Record this number—it drives retention and endurance calculations.
Define required retention. How many days of footage does the deployment need? (Typically 2–7 days for continuous recording, depends on use case.)
Reserve non-video partitions before sizing video. Allocate OS (60 GB), models (20–50 GB), logs (30–50 GB), and over-provisioning (10% of drive). All remaining space goes to video.
Choose SSD endurance tier from host writes × WAF. Multiply daily write volume by 1.3 (typical WAF) and 365 days. Find a drive with TBW rating that covers 3–7 years of operation.
Leave explicit free area / over-provisioning. Do not partition 100% of the drive. Reserve 10–15% for SSD garbage collection and wear leveling. This extends drive life significantly.

For complex deployments with multiple camera groups or variable bitrates, use the Full Deployment Planner to validate your partition sizing before purchasing hardware.

Storage Layout Patterns Comparison

Pattern	Partition Separation	Ring Buffer	Complexity	Risk of OS Overflow	Recommended For
Single root partition	None	Manual management required	Low	High	Development only
OS + video partition	2 partitions	Video partition	Low	Low	Minimal production setup
OS + models + logs + video	4 partitions	Video partition	Medium	Very low	Standard production (recommended)
Two NVMe drives (OS on one, video on second)	Physical separation	Dedicated video drive	Medium	None	High-endurance or high-availability nodes

Implementation Patterns

Segment-based ring buffer with bash + cron: The simplest implementation. A cron job runs every 5 minutes, checks video partition usage with df, and deletes the oldest segment files (sorted by creation time) until usage drops below the threshold. Robust for single-camera deployments and prototypes.

Application-managed ring buffer: The inference application (DeepStream pipeline, Python RTSP recorder, etc.) manages its own segment files, deleting oldest segments as new ones are created. More integrated but couples storage management to the application lifecycle.

LVM thin provisioning: For deployments needing flexible partition resizing without reformatting, LVM thin pools allow partitions to grow dynamically within a pool. Adds complexity but enables online resize if retention requirements change.

For the full node context including compute and networking layers, see the 8-camera reference architecture. For the SSD endurance foundation underlying these calculations, see SSD endurance for edge AI.

Common Pitfalls

No partition separation: Writing video to a single root partition means a video write surge can fill the OS partition, preventing log writes, crashing systemd services, and potentially rendering the node unresponsive. Always separate OS and video storage.
Setting ring buffer threshold too high: A ring buffer that deletes only when 99% full leaves very little time between deletion runs. Use 80–90% fill as the deletion trigger to keep continuous headroom for incoming writes.
Not accounting for segment write-in-progress: A segment file currently being written is not yet complete. Ring buffer cleanup code must skip files that were modified in the last N seconds to avoid deleting an in-progress write.
Forgetting log rotation: Inference logs grow indefinitely without log rotation. Configure logrotate on all log directories with size-based rotation limits that match the log partition size.
Using a single NVMe for OS and high-write video on a consumer drive: OS writes (package updates, container layers, docker builds) and continuous video writes together accelerate consumer drive wear significantly. For sustained workloads, use prosumer or enterprise drives.
Not testing ring buffer behavior at full capacity: The ring buffer must be tested by filling the video partition completely during development. This reveals edge cases in deletion logic before they occur in production.

Frequently Asked Questions

Should I use ext4 or XFS for the video partition?

Both are viable. XFS has better performance for large sequential writes and large files, making it slightly preferable for high-bitrate video. ext4 is more familiar and well-documented. Either choice is acceptable; the difference in practice is minor for this use case.

How do I prevent the ring buffer from deleting footage that triggered an alert?

When an alert fires, copy the relevant segments to a protected directory outside the ring buffer partition (e.g., the log partition). The ring buffer deletes only from the video partition; protected alert clips are managed separately with their own retention policy.

Can I use a network share (NFS, SMB) instead of local NVMe for the ring buffer?

Technically yes, but not recommended for production. Network latency and bandwidth variability make network storage unreliable for continuous high-bitrate video writes. Local NVMe provides deterministic write performance that network shares cannot match.

What is the minimum video partition size for a useful ring buffer?

Plan for at least 48–72 hours of retention at your expected write volume. Less than 24 hours of retention makes it very difficult to retrieve footage for incidents that are reported with a delay. Size accordingly using the retention calculation formulas.

How do I handle time gaps in the ring buffer (camera offline, network down)?

Gaps are inevitable. Segment filenames include timestamps, so gaps are visible in the file listing. Some NVR systems write gap marker files or update a metadata database to track recording continuity. For compliance requirements, document gap handling explicitly in the system design.

Does the ring buffer design change for event-triggered recording?

The partition layout stays the same. The ring buffer cleanup thresholds can be raised since daily write volume is lower. Consider also implementing pre-trigger buffering: keep a short in-memory ring buffer of recent video so event clips include a few seconds before the trigger event.

Should Docker data live on the OS partition or the video drive?

For production edge nodes, write-heavy Docker data should not compete with the OS root partition. If Docker is used for inference services, place Docker data on durable NVMe storage with explicit capacity planning and keep it separated from the bounded video partition wherever possible.

The Bottom Line

Storage layout is about bounded failure domains: OS cannot consume video, video cannot consume logs, and write-heavy workloads cannot destroy the SSD ahead of plan. Explicit partition boundaries, retention sizing, and SSD endurance planning—all done before deployment—are the difference between a node that surprises you in month 6 and one that runs for years.