How to Check How Much Space Is Left on Your Drive

Beginner40-60 minutesWindowsFile Explorer

The determination of remaining drive capacity is, on its surface, a thirty-second task involving a single dialog box. It is also, upon closer examination, the entry point to a body of practice that spans performance maintenance, procurement planning, storage tiering strategy, and archival policy. A developer who knows only how to read the number on the screen is equipped to react to storage crises after they occur. A developer who understands the number within its full operational context is equipped to prevent those crises from occurring at all.

For the 57 Studios™ development cohort, storage management is not administrative overhead—it is a technical discipline with direct consequences for build reliability, asset archival integrity, and the long-term viability of Unturned™ mod project repositories. An NVMe drive operating below the 20% free-space threshold performs measurably worse than a drive operating above it. A development workstation that exhausts its primary drive mid-build does not fail gracefully. A mod-source archive that exceeds available storage capacity during extraction is lost.

This article presents four methods for checking drive capacity, a comparative analysis of each method's strengths and limitations, the capacity-planning frameworks adopted by the cohort, the 20% free-space maintenance heuristic and its technical basis, the NVMe procurement decision framework, storage tiering strategy for active and archival content, and the formal cohort policy for mod-source archival storage. By the conclusion of this article, you will have the information necessary to assess your current storage posture, determine whether a capacity expansion is warranted, and if so, initiate the appropriate procurement process.

Prerequisites

No specific prerequisites beyond the ability to open File Explorer and a PowerShell terminal. Administrator rights are not required for drive space queries. For the WMIC method, a Command Prompt or PowerShell terminal is required. For Storage Sense configuration, access to Windows Settings is required.

What you will learn

• Four methods for querying drive capacity in Windows
• The technical basis for the 20% free-space minimum heuristic on SSDs
• How to interpret capacity data in the context of operational performance
• The capacity-planning framework for active mod development workstations
• The NVMe procurement decision framework and procurement cycle considerations
• Storage tiering strategy for hot, warm, and cold data in a development environment
• The cohort's formal mod-source archival storage policy
• How to automate periodic capacity monitoring with PowerShell
• How to use Storage Sense to reclaim capacity without manual intervention

What free space actually means

The "free space" figure reported by Windows represents the number of bytes on the drive that are not currently allocated to any file or directory entry. This figure is not a simple remainder—it reflects the aggregate of multiple distinct categories of reclaim-eligible space.

The distinction between immediately writable space and cleanup-eligible space matters in practice. A drive may report 50 GB free while holding 20 GB of Recycle Bin contents, 15 GB of Windows Update remnants, and 8 GB of temporary file accumulation. The effective immediately-available space is substantially less than the reported figure. The methods below report the raw NTFS free-space figure; reclaiming the cleanup-eligible portion requires Storage Sense or manual intervention.

Did you know?

NTFS reserves space for its own metadata structures, most notably the Master File Table (MFT). The MFT is a record of every file and directory on the volume, and Windows pre-allocates space to allow the MFT to grow without fragmentation. This reserved space is not included in the reported free-space figure—it is visible neither as allocated nor as free in the Windows API. The typical reservation is 12.5% of the volume for the first 4 GB and a smaller fraction above that.

Method 1: File Explorer — This PC

The File Explorer method is the quickest way to view the free space and total capacity of all connected drives simultaneously.

1. Open File Explorer with Win + E.
2. Click This PC in the left navigation pane.
3. The right pane displays each drive as an icon with a capacity bar beneath it.
4. The capacity bar fills proportionally to the amount of space in use. The label beneath the bar reads X GB free of Y GB.
5. For precise figures, right-click any drive icon and choose Properties.
6. The Properties dialog displays exact Used space and Free space figures in bytes, alongside the total Capacity in bytes and the formatted values in GB.

The capacity bar color changes from blue to red when the drive's free space falls below a threshold (approximately 10% free). This color change is Windows' built-in low-space warning. By the time the bar turns red, performance degradation on SSDs is already measurable.

Common mistake

Relying on the visual capacity bar alone without reading the numeric labels. The bar's resolution is low; a drive at 15% free and a drive at 5% free may appear nearly identical in bar length. Always read the numeric label for operational assessments.

Pro tip

Right-click the drive icon and choose Properties to see the exact free-space figure in bytes. For drives near the 20% threshold, the rounded GB figure is not precise enough to determine whether you are above or below the threshold. The Properties dialog provides the byte-level figure.

Method 2: PowerShell Get-PSDrive

The PowerShell Get-PSDrive cmdlet returns capacity data for all PowerShell drives, including local storage drives, in a structured format suitable for scripting and automation.

# Standard query: all drives
Get-PSDrive -PSProvider FileSystem

# Formatted output with GB values and percentage
Get-PSDrive -PSProvider FileSystem | Where-Object { $_.Used -ne $null } | Select-Object Name,
    @{Name='Used_GB'; Expression={ [math]::Round($_.Used / 1GB, 2) }},
    @{Name='Free_GB'; Expression={ [math]::Round($_.Free / 1GB, 2) }},
    @{Name='Total_GB'; Expression={ [math]::Round(($_.Used + $_.Free) / 1GB, 2) }},
    @{Name='Free_Pct'; Expression={ [math]::Round($_.Free / ($_.Used + $_.Free) * 100, 1) }} |
    Format-Table -AutoSize

Example output:

Name  Used_GB  Free_GB  Total_GB  Free_Pct
----  -------  -------  --------  --------
C     742.30   237.70   980.00    24.3
D     1421.10  626.90   2048.00   30.6

The Free_Pct column is the critical figure for capacity-planning purposes. A Free_Pct value below 20 on any drive hosting active development work requires attention; a value below 10 requires immediate action.

Monitoring multiple drives with threshold alerts

$thresholdPct = 20
$drives = Get-PSDrive -PSProvider FileSystem | Where-Object { $_.Used -ne $null }

foreach ($drive in $drives) {
    $total = $drive.Used + $drive.Free
    $freePct = [math]::Round($drive.Free / $total * 100, 1)
    $freeGB = [math]::Round($drive.Free / 1GB, 2)

    if ($freePct -lt $thresholdPct) {
        Write-Host "WARNING: Drive $($drive.Name): $freeGB GB free ($freePct%) — below ${thresholdPct}% threshold" -ForegroundColor Red
    } else {
        Write-Host "OK: Drive $($drive.Name): $freeGB GB free ($freePct%)" -ForegroundColor Green
    }
}

Run this script as part of the project start-up procedure on development workstations. A positive result (all drives above threshold) takes two seconds and costs nothing. A warning result allows remediation before a build run.

Best practice

Save the threshold-monitoring script as Check-DriveSpace.ps1 in your tools folder (for example, C:\Tools\Check-DriveSpace.ps1). Add an invocation of the script to your project build pipeline's pre-flight checks. Drive space warnings surfaced at build initiation are an order of magnitude less disruptive than build failures mid-execution.

Method 3: WMIC logicaldisk get

The Windows Management Instrumentation command-line interface (WMIC) provides drive capacity data at the raw byte level via the logicaldisk class. WMIC is available in both Command Prompt and PowerShell.

# PowerShell invocation
wmic logicaldisk get Caption,Size,FreeSpace,DriveType

# With formatted output
$drives = Get-WmiObject Win32_LogicalDisk | Where-Object { $_.DriveType -eq 3 }
$drives | Select-Object DeviceID,
    @{Name='Size_GB'; Expression={ [math]::Round($_.Size / 1GB, 2) }},
    @{Name='Free_GB'; Expression={ [math]::Round($_.FreeSpace / 1GB, 2) }},
    @{Name='Free_Pct'; Expression={ [math]::Round($_.FreeSpace / $_.Size * 100, 1) }} |
    Format-Table -AutoSize

The DriveType -eq 3 filter restricts the query to local fixed disks, excluding removable drives, network drives, and optical drives. The Get-WmiObject cmdlet is the PowerShell-native equivalent of the WMIC command and is preferred in modern scripts.

Did you know?

WMIC is deprecated in Windows 11 and may be removed in future Windows versions. Microsoft's replacement is the PowerShell Get-WmiObject (and its successor Get-CimInstance) cmdlet. For scripts intended to run long-term, prefer Get-CimInstance Win32_LogicalDisk over the WMIC command-line interface.

Using Get-CimInstance (modern equivalent)

Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType = 3" |
    Select-Object DeviceID,
        @{Name='Size_GB'; Expression={ [math]::Round($_.Size / 1GB, 2) }},
        @{Name='Free_GB'; Expression={ [math]::Round($_.FreeSpace / 1GB, 2) }},
        @{Name='Free_Pct'; Expression={ [math]::Round($_.FreeSpace / $_.Size * 100, 1) }} |
    Format-Table -AutoSize

Get-CimInstance uses WS-Management rather than DCOM for remote queries and is the strategic replacement for Get-WmiObject in Windows PowerShell 3.0 and later.

Pro tip

For periodic automated monitoring logged to a file, chain the Get-CimInstance query with Out-File and a date-stamped log path. A month of logged capacity snapshots reveals consumption trends that a single point-in-time reading cannot. Trend data is the foundation of procurement planning.

Method 4: Storage Sense

Storage Sense is a Windows feature that both reports on drive usage composition and automatically reclaims cleanup-eligible space according to a configurable policy. Unlike the three preceding methods, Storage Sense distinguishes between categories of storage consumption rather than reporting a single aggregate figure.

1. Open Windows Settings with Win + I.
2. Navigate to System → Storage.
3. The Storage overview page displays a breakdown of storage consumption by category: Apps & games, Temporary files, Other, Documents, Pictures, Music, and so on.
4. Click any category to drill into its contents and review or remove specific items.
5. Click Temporary files to access the manual cleanup interface for the most commonly reclaim-eligible category.

Configuring Storage Sense for automated cleanup

1. In Settings → System → Storage, click Storage Sense.
2. Enable the Run Storage Sense automatically toggle.
3. Set the schedule: Every week is the recommended interval for active development workstations.
4. Configure the Recycle Bin policy: set Delete files in my Recycle Bin if they have been there for over to 30 days or a shorter interval if disk pressure is a concern.
5. Configure the Downloads folder policy if desired.
6. Click Run Storage Sense now for an immediate cleanup pass.

Best practice

Enable Storage Sense on all development workstations with a weekly schedule. The automatic cleanup removes temporary files, Windows Update remnants, and Recycle Bin contents that accumulate silently during normal operation. A workstation without automated cleanup can lose 20–40 GB of usable capacity over six months to cleanup-eligible accumulation, with no corresponding benefit.

Common mistake

Relying on Storage Sense alone for capacity management on development workstations. Storage Sense reclaims cleanup-eligible system content; it does not manage project archives, downloaded assets, or installed applications. Storage Sense is a maintenance tool, not a planning tool. Capacity planning requires a separate framework.

Method comparison

Method	Time to result	Detail level	Automation	Category breakdown	Best use
File Explorer — This PC	5 seconds	Drive-level	No	No	Quick visual check
Storage Sense	30 seconds	Category-level	Yes (scheduled)	Yes	Manual cleanup and composition review
WMIC logicaldisk get	10 seconds	Drive-level + raw bytes	Yes	No	Scripted queries; legacy pipelines
PowerShell Get-PSDrive	10 seconds	Drive-level + raw bytes	Yes	No	Scripted queries; modern pipelines

For day-to-day operational checks, File Explorer provides the fastest visual confirmation. For scripted pipelines, capacity planning, and threshold monitoring, PowerShell with Get-CimInstance or Get-PSDrive is the correct choice.

The 20% free-space minimum heuristic

The 20% free-space minimum is the most widely cited storage performance guideline for NAND flash storage devices, including all consumer and prosumer NVMe drives. The basis for this heuristic is the behavior of NAND flash at the hardware level.

The technical basis

NAND flash storage does not overwrite data in place. When a file is deleted or modified, the old data is marked invalid; the new data is written to a different physical location. The drive's firmware manages a garbage collection process that consolidates valid data and erases invalid blocks, freeing them for reuse. This process, called garbage collection with wear leveling, requires free physical capacity to operate.

When free capacity falls below approximately 20% of the drive's rated capacity, the garbage collection process cannot maintain sufficient free block pools. Write operations begin triggering synchronous garbage collection, which substantially increases write latency and reduces sequential write throughput. The 20% threshold is an approximation of the point at which this degradation becomes consistently measurable in real workloads.

Quantified performance impact

Free space percentage	Write performance relative to optimal	Observed behavior
40%+	100%	Full rated write throughput; minimal latency
30–40%	95–100%	Negligible degradation
20–30%	85–95%	Minor degradation; not perceptible in normal use
10–20%	60–80%	Measurable degradation; build times increase
5–10%	30–60%	Significant degradation; multi-GB writes stall
Under 5%	10–40%	Severe degradation; risk of out-of-space errors mid-operation

For development workstations running build pipelines that produce multi-gigabyte outputs (Unity bundles, archive packages, texture atlases), the degradation at sub-20% free space is not theoretical—it manifests as perceptibly slower build runs and occasional stall events.

Critical warning

A build pipeline that exhausts drive capacity mid-run typically produces corrupted output files. Unity3d bundle compilation, in particular, writes temporary files to the project's Library folder during build execution. If the drive fills during this process, the resulting bundle files may be partially written and invalid. Detecting this corruption requires verification of every bundle produced by the affected run. The time cost of a corrupted build run far exceeds the time cost of maintaining adequate free space.

Did you know?

Most consumer NVMe drives include a feature called SLC caching, which designates a portion of the drive's NAND as pseudo-SLC (single-level cell) storage for burst write performance. SLC cache capacity is directly proportional to the drive's available free space. A drive at 5% free space has minimal or no SLC cache available; a drive at 40% free space has substantial SLC cache that absorbs burst writes at speeds approaching DRAM. The 20% threshold is partly a proxy for the minimum SLC cache pool needed for development-workload burst performance.

Capacity-planning framework

Reactive storage management—checking drive space only when a build fails or a copy operation errors—is not a professional practice. The cohort employs a proactive capacity-planning framework built around the following principles.

Assessment cadence

Cadence	Trigger	Action
Daily	Start of each work session	Run Check-DriveSpace.ps1; confirm all drives above 20%
Weekly	Monday morning	Review Storage Sense summary; reclaim cleanup-eligible space
Monthly	First workday of each month	Review trend data from daily logs; project weeks to threshold
Quarterly	First workday of each quarter	Formal storage posture review; assess procurement triggers

Capacity-planning calculations

The foundational capacity-planning calculation projects the date on which a drive's free space will reach the 20% threshold, given current consumption rate.

# Project weeks-to-threshold based on rolling average consumption
# Inputs: current free space, weekly consumption average, drive total
$driveLetter = 'C'
$drive = Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DeviceID = '${driveLetter}:'"
$totalGB = [math]::Round($drive.Size / 1GB, 2)
$freeGB = [math]::Round($drive.FreeSpace / 1GB, 2)
$usedGB = $totalGB - $freeGB
$freePct = [math]::Round($freeGB / $totalGB * 100, 1)
$thresholdGB = $totalGB * 0.20

# These values come from the monthly trend log
$weeklyConsumptionGB = 8.5  # Example: 8.5 GB per week average

$gbUntilThreshold = $freeGB - $thresholdGB
$weeksToThreshold = [math]::Round($gbUntilThreshold / $weeklyConsumptionGB, 1)

Write-Host "Drive $driveLetter status:"
Write-Host "  Total: $totalGB GB"
Write-Host "  Used:  $usedGB GB"
Write-Host "  Free:  $freeGB GB ($freePct%)"
Write-Host "  Threshold (20%): $([math]::Round($thresholdGB, 2)) GB"
Write-Host "  GB until threshold: $([math]::Round($gbUntilThreshold, 2)) GB"
Write-Host "  Weeks to threshold at current rate: $weeksToThreshold"

if ($weeksToThreshold -lt 4) {
    Write-Host "  STATUS: PROCUREMENT TRIGGER — fewer than 4 weeks to threshold" -ForegroundColor Red
} elseif ($weeksToThreshold -lt 8) {
    Write-Host "  STATUS: PROCUREMENT ADVISORY — begin NVMe evaluation" -ForegroundColor Yellow
} else {
    Write-Host "  STATUS: ADEQUATE — no action required" -ForegroundColor Green
}

The output of this calculation, run monthly from the trend log, is the primary input to the procurement decision framework.

Best practice

Log the output of the daily drive-space check to a dated log file for 90 days before making any procurement decision. A single point-in-time measurement does not reveal consumption rate. Trend data over 90 days provides the weekly average consumption figure needed for meaningful weeks-to-threshold projections.

NVMe procurement cycle

The procurement of additional storage is not an event—it is a cycle with defined trigger points, evaluation criteria, acquisition procedures, and installation milestones. The cohort's NVMe procurement framework structures this cycle to prevent both premature procurement (unnecessary spend on storage that would not be needed for months) and deferred procurement (reactive purchases that arrive after a capacity crisis has already disrupted work).

Procurement trigger conditions

A procurement trigger is a condition that initiates the evaluation phase of the procurement cycle. A trigger does not obligate a purchase; it obligates an assessment.

Trigger	Condition	Urgency
Primary procurement trigger	Primary development drive below 20% free	Evaluate immediately
Secondary procurement trigger	Weeks-to-threshold projection below 8 weeks	Begin evaluation
Tertiary procurement trigger	Project scope expansion increasing expected storage consumption by >50%	Plan evaluation
Performance trigger	Build times increasing despite adequate free space	Evaluate drive health and performance tier

Evaluation criteria

When a procurement trigger is active, evaluate potential replacement or expansion drives against the following criteria.

Criterion	Minimum specification	Preferred specification
Interface	PCIe 4.0 x4	PCIe 5.0 x4
Form factor	M.2 2280 (confirm motherboard slot availability)	M.2 2280
Sequential read	5,000 MB/s	7,000+ MB/s
Sequential write	3,000 MB/s	6,000+ MB/s
Random write (4K QD1)	50,000 IOPS	100,000+ IOPS
TBW (drive endurance)	600 TBW per TB of capacity	1,200+ TBW per TB
DRAM cache	Present	Present
Capacity	Minimum 2x current drive capacity	4x current drive capacity

The 2x current drive capacity minimum ensures that the newly acquired drive does not require another procurement cycle within 18 months at the current consumption rate. The 4x preferred specification targets a 36-month window before the next evaluation.

Did you know?

Drive capacity pricing in the consumer NVMe market follows a consistent curve: the price per gigabyte decreases substantially as capacity increases, up to the 2–4 TB range, then begins to increase again for the highest-capacity single-drive options. As of 2026, the 2 TB form factor represents the optimal cost-per-gigabyte point for most development workstations. Purchasing two 2 TB drives (one primary, one backup/secondary) typically provides better value than a single 4 TB drive.

Procurement lead time

NVMe drive procurement from major retail channels (online retailers with next-day delivery) typically carries a lead time of one to three business days. This lead time is relevant to the urgency classification of procurement triggers. A drive at the secondary trigger condition (8 weeks to threshold) has ample lead time margin for a deliberate evaluation and purchase. A drive at the primary trigger condition (below 20% free) should result in immediate order placement following evaluation.

Common mistake

Delaying procurement evaluation once a secondary trigger condition is active, on the assumption that 8 weeks is adequate time. Eight weeks is adequate time only if the evaluation begins immediately. If the evaluation is deferred for 4 weeks and then the assessment reveals that the preferred drive is backordered, the remaining 4 weeks may be insufficient. Treat secondary trigger conditions as a 2-week deadline for order placement, not an 8-week deadline for action initiation.

Storage tiering strategy

Not all data has the same access frequency, performance requirements, or value. A storage tiering strategy assigns data to the storage medium most appropriate for its characteristics, minimizing spend on high-performance storage for data that does not require it.

Tier definitions

Tier	Name	Storage medium	Access frequency	Performance requirement	Example content
0	Hot	Primary NVMe (PCIe 4.0+)	Daily	Maximum	Active project working files, Unity Editor Library, build outputs
1	Warm	Secondary NVMe or SATA SSD	Weekly	Moderate	Recent project archives, reference asset libraries, tool installations
2	Cold	External HDD or NAS	Monthly or less	Low	Completed project archives, milestone snapshots, pre-release distribution archives
3	Archive	Cloud storage or offline HDD	Rarely	Minimal	Long-term archival, disaster recovery copies, source distributions

Data placement policy for mod development workstations

The following placement policy governs data tier assignment for 57 Studios™ development workstations.

Tier 0 (Hot — Primary NVMe): Active project working files, the Unity Editor, the Unity project's Library folder (auto-generated build cache), currently compiled bundles, and all tools required for the active development session. Tier 0 data must always have at least 20% free space on the hosting drive.

Tier 1 (Warm — Secondary NVMe or SATA SSD): Projects completed within the last 90 days, reference asset libraries actively referenced during current development, tool archives, and application installers. Tier 1 data does not require the 20% free-space SSD performance threshold but should maintain 10% free space for standard operational headroom.

Tier 2 (Cold — External HDD or NAS): Completed projects older than 90 days, all milestone snapshots, and all distribution archives. Tier 2 storage does not have SSD performance requirements. An external HDD or a NAS volume is appropriate for Tier 2. The 20% heuristic does not apply to HDDs in the same way—maintain 15% free space as a general operational buffer.

Tier 3 (Archive — Cloud or Offline): All data in Tier 2 plus an additional copy in a geographically separate location or medium. Google Drive, with its version history and restoration capabilities, is the cohort's Tier 3 storage for project-critical content. Offline HDD copies are appropriate for content that exceeds cloud storage quotas or contains pre-release material not suitable for cloud storage.

Data migration between tiers

Data migration between tiers follows the cohort's standard archive-then-delete procedure:

1. Create a verified archive of the data being demoted (using the procedures in the zip-file article).
2. Copy the archive to the target tier's storage.
3. Verify the archive at the destination (run Test-ZipIntegrity or 7-Zip test on the destination copy).
4. Only after successful destination verification, delete the source copy.

Step 4 must not execute before Step 3 confirms the destination archive is intact. Deleting source data before verifying the destination is the most common cause of irreversible data loss in tier-migration workflows.

Critical warning

Never delete source data before verifying the destination copy. This is the one storage management action with no recovery path if it goes wrong. Disk space is a recoverable resource; permanently deleted data is not.

Cold, warm, and hot data placement for mod-source archival

The formal cohort policy for mod-source archival storage assigns storage tiers based on the following classification:

Classification criteria

Content type	Classification	Basis
Active project _Source folder	Hot (Tier 0)	Accessed multiple times per work session
Active project Assets folder	Hot (Tier 0)	Accessed multiple times per work session
Active project Bundles folder	Hot (Tier 0)	Rebuilt frequently during development
Current release distribution archives	Warm (Tier 1)	Accessed for re-distribution or review requests
Previous release distribution archives	Cold (Tier 2)	Accessed rarely, for regression or reference
Project source archives (pre-release review packages)	Cold (Tier 2)	Accessed rarely after review cycle closes
Post-release project archives	Cold (Tier 2) + Archive (Tier 3)	Accessed only for major version backporting
Raw reference material (purchased assets, stock textures)	Warm (Tier 1)	Referenced across multiple projects

Retention schedule

Data category	Minimum retention	Recommended retention	Disposal procedure
Active project working files	Until project close	Indefinitely in Cold tier	Archive with verification
Distribution archives	24 months post-release	Indefinitely in Cold tier	Archive with verification
Build output bundles (non-release)	7 days	30 days	Direct deletion after threshold
Unity Library folder (build cache)	Active project only	Delete on project close	Direct deletion (regenerable)
Pre-release review packages	Until review closes	12 months	Archive with verification

The Unity Library folder is explicitly excluded from archival requirements because it is fully regenerable from source. It is the largest single contributor to active project storage consumption and should be the first target for reclamation when active-project drive space is constrained.

Best practice

Deleting a closed project's Unity Library folder before archiving the project reduces the archive size by 30–70% in most Unturned™ mod projects. The Library folder is regenerated by Unity on next project open. Always delete the Library folder before producing a project archive; always verify the archive before deleting the folder from the source.

Cohort capacity-management dashboard reference

The cohort capacity-management dashboard provides a centralized view of storage posture across all active development workstations. The dashboard aggregates daily Check-DriveSpace.ps1 output from each workstation's log folder.

Dashboard data is updated daily by the automated logging script. The dashboard is accessible to all cohort members at the cohort's internal tooling URL. Alert thresholds on the dashboard match the procurement framework trigger conditions defined in this article.

To connect your workstation to the dashboard logging pipeline:

1. Configure Check-DriveSpace.ps1 to write its output to the shared log path specified in the cohort onboarding documentation.
2. Confirm the log file is writing correctly by running the script manually and checking the log path.
3. The dashboard will pick up the new workstation's data within 24 hours.

Members who have not yet connected their workstations to the dashboard are operating without the secondary benefit of cohort-wide visibility. A workstation that is approaching a procurement trigger condition and is not connected to the dashboard cannot receive cohort-level early warnings. Connection is strongly recommended.

Drive health and capacity as related concerns

Drive capacity and drive health are distinct metrics, but they interact in ways that make it professionally sound to assess both on the same monitoring cadence. A drive that is 80% full and degrading in write performance due to hardware aging presents a compound risk that neither metric alone fully captures.

Assessing drive health alongside capacity

# Get-DriveHealth.ps1
# Queries drive capacity and health indicators for all local fixed drives.

$disks = Get-PhysicalDisk | Where-Object { $_.BusType -ne 'USB' -and $_.BusType -ne 'Virtual' }

foreach ($disk in $disks) {
    Write-Host "Drive: $($disk.FriendlyName)" -ForegroundColor Cyan
    Write-Host "  Media type:   $($disk.MediaType)"
    Write-Host "  Bus type:     $($disk.BusType)"
    Write-Host "  Size:         $([math]::Round($disk.Size / 1GB, 2)) GB"
    Write-Host "  Health:       $($disk.HealthStatus)"
    Write-Host "  Op status:    $($disk.OperationalStatus)"
    Write-Host ""
}

The HealthStatus field returns Healthy, Warning, or Unhealthy. A Warning or Unhealthy status, regardless of the remaining free space percentage, is an immediate procurement trigger—not a secondary or tertiary trigger, but a first-priority action item. A drive at 50% free space with a Warning health status is a greater operational risk than a drive at 18% free space with Healthy status.

S.M.A.R.T. data and its relevance to procurement decisions

Self-Monitoring, Analysis, and Reporting Technology (S.M.A.R.T.) provides firmware-level diagnostics for storage devices. Windows does not expose S.M.A.R.T. data natively in an actionable format, but the CrystalDiskInfo utility (free, available from the developer's official site) presents it in a readable interface.

The S.M.A.R.T. attributes most relevant to procurement decisions on NVMe drives are:

Attribute	What it measures	Procurement relevance
Remaining life (percentage)	Estimated drive life remaining based on write endurance	Below 20%: plan procurement within one procurement cycle
Reallocated sectors	Sectors that failed and were replaced from spare area	Any non-zero value: evaluate immediately
Temperature	Current operating temperature	Above 70°C sustained: investigate cooling before next procurement
Power on hours	Total drive operational time	Context for interpreting other attributes
Total bytes written	Lifetime write volume	Compare against TBW rating for endurance assessment

Best practice

Check S.M.A.R.T. data monthly as part of the storage posture review. A drive whose Remaining Life drops below 50% warrants a procurement advisory. A drive whose Remaining Life drops below 20% should be treated as a primary procurement trigger regardless of its current free space percentage.

Workstation profile: storage posture for active Unturned mod development

The following storage profile describes the recommended configuration for a 57 Studios™ active development workstation running Unturned™ mod projects of medium to large scope.

Recommended drive configuration

Drive slot	Recommended capacity	Interface	Role	Tier
M.2 slot 1 (primary)	2 TB minimum	PCIe 4.0 x4 NVMe	Operating system, active projects, Unity Editor	Tier 0 (Hot)
M.2 slot 2 (secondary)	2 TB minimum	PCIe 4.0 x4 NVMe or SATA SSD	Recent archives, reference libraries, tool storage	Tier 1 (Warm)
External (USB 3.2 or Thunderbolt)	4–8 TB HDD or SSD	USB 3.2 Gen 2	Cold project archives, milestone snapshots	Tier 2 (Cold)
Cloud or offline HDD	As needed	—	Disaster recovery, long-term archive	Tier 3 (Archive)

For the Spicewood PC (Ryzen 9950X3D / RTX 5080 / ASUS X870E Tomahawk), the ASUS X870E Tomahawk provides four M.2 slots, all supporting PCIe 5.0 x4 at the top slot and PCIe 4.0 x4 at the remaining slots. This configuration supports dual-NVMe (Tier 0 + Tier 1) with two additional slots available for future expansion, eliminating the need for external storage for warm-tier content at typical project volumes.

Capacity budget for a medium mod project

Content category	Estimated size	Tier	Drive
Windows 11 installation + drivers	40–60 GB	Tier 0	Primary NVMe
Unity Editor (current version)	8–12 GB	Tier 0	Primary NVMe
Active mod project working files	5–15 GB	Tier 0	Primary NVMe
Unity Library (build cache, regenerable)	2–8 GB	Tier 0	Primary NVMe
Blender (latest version)	1–2 GB	Tier 0	Primary NVMe
Adobe Creative Cloud apps	10–30 GB	Tier 0	Primary NVMe
Steam + Unturned	3–5 GB	Tier 0	Primary NVMe
Development tools (7-Zip, CrystalDiskInfo, etc.)	1–2 GB	Tier 0	Primary NVMe
Subtotal — Tier 0 committed	70–144 GB
Tier 0 minimum (20% free buffer on 2 TB)	400 GB
Effective usable Tier 0 budget	1,456–1,530 GB

This budget demonstrates that a 2 TB primary NVMe at the recommended 20% minimum free space threshold provides approximately 1.4–1.5 TB of usable capacity for active projects, tool installations, and system use after buffer reservation. A workstation running multiple simultaneous active projects with large Unity Library folders may find this margin more constrained than the raw numbers suggest.

Interpreting capacity trend data: patterns and their meanings

The monthly log data collected by the automated monitoring system reveals patterns that inform both immediate action and long-term planning. The following patterns and their interpretations are drawn from cohort operational history.

Pattern 1: Steady linear consumption

Week 1:  Free: 500 GB (50%)
Week 2:  Free: 492 GB (49.2%)
Week 3:  Free: 484 GB (48.4%)
Week 4:  Free: 476 GB (47.6%)

Interpretation: Normal active development. Weekly consumption of approximately 8 GB reflects a moderately active project with regular asset production. No immediate action required; project current weeks-to-threshold: approximately 37 weeks.

Pattern 2: Step-function drop

Week 1:  Free: 500 GB (50%)
Week 2:  Free: 498 GB (49.8%)
Week 3:  Free: 347 GB (34.7%)  ← 151 GB drop
Week 4:  Free: 345 GB (34.5%)

Interpretation: A large one-time storage event occurred in Week 3. Common causes: a large asset library download, a Unity Editor or Adobe CC update, or a build that produced an unusually large Unity Library regeneration. Investigate the Week 3 event, confirm the cause, and determine whether the consumed space is permanent (new asset library) or temporary (can be reclaimed via Unity Library deletion or Storage Sense cleanup).

Pattern 3: Accelerating consumption

Week 1:  Free: 500 GB (50%)    Delta: —
Week 2:  Free: 487 GB (48.7%)  Delta: 13 GB
Week 3:  Free: 471 GB (47.1%)  Delta: 16 GB
Week 4:  Free: 450 GB (45.0%)  Delta: 21 GB
Week 5:  Free: 424 GB (42.4%)  Delta: 26 GB

Interpretation: Consumption rate is increasing week over week. Common causes: a project entering a high-output development phase with expanding asset libraries, an accumulation of non-archived build outputs, or an application that is silently growing a cache. Investigate the source of acceleration. If the cause is legitimate project growth, update the weeks-to-threshold projection with the current higher weekly rate rather than the lower historical average.

Pattern 4: Oscillating consumption

Week 1:  Free: 500 GB (50%)
Week 2:  Free: 475 GB (47.5%)
Week 3:  Free: 492 GB (49.2%)
Week 4:  Free: 468 GB (46.8%)
Week 5:  Free: 487 GB (48.7%)

Interpretation: Storage is being both consumed and reclaimed in alternating cycles. Common cause: a workflow that regularly deletes large build outputs or Unity Library folders and regenerates them. The oscillating pattern is operationally stable as long as the envelope (the bottom of each oscillation) stays above the 20% threshold. Monitor the bottom of the oscillation, not the average.

Best practice

When interpreting oscillating consumption patterns, use the minimum free-space value observed in the oscillation cycle as the effective baseline for threshold calculations, not the average. A drive that oscillates between 22% and 45% free is effectively operating at 22% minimum; a single additional peak consumption event could push it below 20%.

Automated periodic monitoring

A periodic automated monitoring schedule prevents the daily manual step from being forgotten during busy project periods.

# Register-DriveMonitor.ps1
# Registers a daily scheduled task to check drive space and log the result.
# Run once with administrator rights.

$scriptPath = 'C:\Tools\Check-DriveSpace.ps1'
$logPath = 'C:\Tools\Logs\DriveSpace'

# Ensure log folder exists
New-Item -ItemType Directory -Path $logPath -Force | Out-Null

$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument "-NonInteractive -File `"$scriptPath`" >> `"$logPath\$(Get-Date -Format 'yyyy-MM').log`" 2>&1"
$trigger = New-ScheduledTaskTrigger -Daily -At '09:00AM'
$settings = New-ScheduledTaskSettingsSet -ExecutionTimeLimit (New-TimeSpan -Minutes 5) -RunOnlyIfNetworkAvailable $false

Register-ScheduledTask -TaskName 'DriveSpaceMonitor' -Action $action -Trigger $trigger -Settings $settings -RunLevel Highest -Force

Write-Host "DriveSpaceMonitor scheduled task registered. First run at 09:00 AM." -ForegroundColor Green

The scheduled task runs Check-DriveSpace.ps1 every morning at 09:00 and appends the output to a monthly log file. The log accumulates the trend data needed for the monthly capacity-planning calculation.

Best practice

After registering the scheduled task, run it immediately to confirm it executes correctly: right-click the task in Task Scheduler and choose Run. A task that fails silently due to a PowerShell execution policy restriction or a path error provides no monitoring value. Always verify a newly registered scheduled task with an immediate manual run.

The relationship between storage capacity and build pipeline reliability

A development workstation's storage posture directly affects the reliability of automated build pipelines. This relationship is one of the more underappreciated connections in mod development infrastructure, and it warrants explicit treatment.

How build pipelines consume storage

A Unity build for an Unturned™ mod project consumes storage at multiple stages, some of which are invisible in a simple free-space check:

Pipeline stage	Storage consumed	Permanent or temporary	Notes
Asset import	Library folder growth	Temporary (regenerable)	Unity creates import artifacts; typically 2–4x the source asset size
Bundle compilation	Bundles folder	Permanent (release output)	Final bundle files; typically 1–3x source asset size
Intermediate build objects	Library/BuildPlayerData	Temporary	Cleaned automatically on next build
Shader compilation cache	Library/ShaderCache	Temporary (regenerable)	Can grow large for projects with many materials
Addressables staging	Library/com.unity.addressables	Temporary	Relevant if mod uses Addressable Asset System
Editor log	%LocalAppData%\Unity\Editor	Temporary	Accumulates across sessions; safe to delete

The peak storage requirement during a build run is the sum of the current Bundles folder size plus the Library folder size plus an additional 20–50% headroom for intermediate build objects. A project with a 2 GB Bundles folder and a 4 GB Library folder requires approximately 7–9 GB of free space to complete a clean rebuild without storage pressure.

Best practice

Before initiating a full clean rebuild on a large project, verify that the primary NVMe drive has at least 1.5x the sum of the expected Bundles folder size and the current Library folder size in free space, above the 20% minimum buffer. This check prevents the most common cause of mid-build storage exhaustion.

Storage pressure and incremental versus clean builds

Unity's incremental build system reuses previously compiled artifacts where possible, dramatically reducing the storage consumed during a normal build run. A clean build (triggered by deleting the Library folder or choosing Rebuild from the Unity menu) discards all cached artifacts and recompiles from source, consuming significantly more storage and time.

The strategic implication: when storage pressure is high and a build must be completed, prefer incremental builds that leave the Library folder intact. Reserve clean builds for scenarios where incremental build artifacts are suspected to be corrupted or where a change requires full recompilation.

Build type	Library folder behavior	Storage consumed	When to use
Incremental	Preserves and extends	10–20% of clean build	Normal development cycles
Clean	Deletes and regenerates	Full Library + Bundles + headroom	Post-corruption recovery; major structural changes
Bundles-only rebuild	Preserves Library; rebuilds Bundles	Bundles folder + headroom	Asset-only changes with no code changes

Storage capacity for collaborative project scenarios

When multiple developers contribute to a single Unturned™ project, the storage management discipline must account for the distribution overhead of exchanging assets and build artifacts between contributors.

Per-contributor storage budget in a collaborative project

Each contributor to a shared project maintains their own complete working copy of the project on their Tier 0 drive. For a project with a 2 GB source archive, this means:

Storage category	Per-contributor allocation
Project source files (working copy)	2–5 GB
Unity Library (local build cache)	3–8 GB
Received distribution archives (from other contributors)	0.5–2 GB per version reviewed
Local build outputs (Bundles, staging)	1–3 GB
Total per-contributor active footprint	6.5–18 GB

In a five-contributor project, the aggregate across-cohort storage commitment for the active project is 32–90 GB. This figure is relevant when planning the cohort's shared infrastructure capacity, particularly for any shared NAS or build server implementation.

Archive exchange protocols for collaborative projects

When contributors exchange source archives for review, the following protocol minimizes storage waste from stale archive accumulation:

1. The contributor producing a review package creates the archive with the standard naming convention and distributes it through the cohort file exchange channel.
2. Each reviewer creates a dedicated extraction folder named Review_ProjectName_vX.Y.Z in their Tier 1 storage.
3. After the review cycle closes, each reviewer deletes the extraction folder and moves the archive to Tier 2 cold storage.
4. The producing contributor updates the distribution log to record the review-close date and each reviewer's disposition of the archive.

This protocol prevents the common failure mode where multiple copies of large review archives accumulate on contributor workstations across review cycles, consuming tens of gigabytes of Tier 0 storage with no ongoing utility.

Best practice

Set a calendar reminder for the review-close date of any archive you receive as a reviewer. The reminder ensures the Tier 1 extraction folder is cleaned up promptly rather than accumulating indefinitely. An uncleaned extraction folder from a closed review cycle is functionally equivalent to any other orphaned file accumulation.

Frequently asked questions

Why does Windows report different free space than I calculated? NTFS reserves a portion of drive capacity for system use that is not reflected in the free-space API. Shadow copies, restore points, and the MFT reservation all consume physical space without appearing in the standard free-space figure. Additionally, installed applications may have reserved space within their folders that NTFS counts as used. The discrepancy between your calculation and the reported figure is normal.

Does the 20% rule apply to hard disk drives? The 20% heuristic is specific to NAND flash storage (SSDs and NVMe drives) and the garbage collection mechanics of flash memory. HDDs do not have flash garbage collection; their performance does not degrade below 20% free space for the same reason. However, HDDs benefit from at least 10–15% free space for defragmentation headroom. The 20% threshold is an SSD/NVMe operational requirement, not a universal storage rule.

How do I free up space quickly when I'm close to running out? In order of speed and safety: (1) Empty the Recycle Bin. (2) Run Storage Sense → Clean up now. (3) Delete the Unity Library folder for any closed projects (it is regenerable). (4) Move completed project archives to a Tier 2 drive. (5) Uninstall applications you no longer use. Never delete files you cannot positively identify as safe to remove.

What is the difference between disk capacity and available space in the drive properties dialog? The Properties dialog shows three figures: Capacity (total formatted capacity), Used space (bytes allocated to files and directories), and Free space (bytes not allocated). The sum of Used space and Free space is smaller than Capacity because of NTFS metadata overhead and reservations. This is not a Windows error; it is the normal overhead of the NTFS file system.

Can I use a network drive for mod development active project storage? Active project storage should be local NVMe. Network drives introduce latency, bandwidth constraints, and connection-failure risk that are incompatible with the frequent small-file reads and writes of an active Unity Editor session. Network drives are appropriate for Tier 2 (NAS) and Tier 3 storage where access frequency is low and latency tolerance is high.

How much space does a typical Unturned mod project consume? A small item-only mod typically accumulates 500 MB to 2 GB by release, with the source tier contributing the majority. A large mixed mod with custom map content can accumulate 5–15 GB in its source tier. The Unity Library folder, which is a regenerable build cache, may add another 2–8 GB for larger projects. These figures inform the storage sizing calculations in the procurement framework.

Is it safe to move the Unity Library folder to a different drive? The Unity Library folder should remain on the same drive as the project to maintain Asset Database consistency. Moving it to a different drive while the project is open produces errors; Unity will regenerate it at the original location on next open. For storage management purposes, delete the Library folder rather than moving it. Unity regenerates it in 5–20 minutes depending on project size and drive speed.

How do I check whether my drive is an NVMe, SATA SSD, or HDD?

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, Size

The MediaType column returns SSD or HDD. The BusType column returns NVMe for NVMe drives and SATA for SATA-attached drives. This information is relevant to applying the correct performance thresholds and procurement criteria.

Why does my new drive show less capacity than advertised? Storage manufacturers measure capacity in decimal gigabytes (1 GB = 1,000,000,000 bytes). Windows measures capacity in binary gibibytes (1 GiB = 1,073,741,824 bytes). A drive advertised as 1 TB (1,000 GB decimal) displays as approximately 931 GB in Windows. Additionally, NTFS formatting overhead and factory reserved capacity consume a further small percentage. A 1 TB advertised drive typically shows 900–931 GB in Windows.

What happens if a build run starts and the drive fills up mid-build? The build tool receives an out-of-disk-space error and terminates. Partially written output files remain at their partially written state and are not valid. For Unity bundle builds, the Asset Database may be left in an inconsistent state requiring a full reimport on the next Editor open. The recovery procedure is: free space on the drive, delete any partially written output files, reimport the project in Unity, and re-run the build from the beginning. Total recovery time is typically 30–90 minutes for medium-sized projects.

How do I determine how much space to allocate for a new project? Estimate using the project template size categories from the folder-creation article, then multiply by 3 to account for the three-tier asset flow (_Source, Assets, Bundles) and add 4x the estimated Assets folder size for the Unity Library build cache. A project expected to have a 1 GB Assets folder should be planned for approximately 1 GB (Bundles) + 1 GB (Assets) + 2 GB (Source) + 4 GB (Library) = 8 GB of active storage allocation, with the Library and Assets folders consuming the most volatile space.

Should I defragment my NVMe drive? No. NTFS defragmentation is designed for HDDs, where physical read-head positioning makes fragmentation costly. NVMe drives have no mechanical read heads; data access time is uniform regardless of physical block location. Windows 10 and 11 automatically schedule "Optimize Drives" runs that perform TRIM operations (not defragmentation) on SSDs and NVMe drives. TRIM signals unused blocks to the drive firmware for garbage collection. The Windows Optimize Drives feature is safe to run on NVMe drives; manual defragmentation tools that perform sequential block rewrites are counterproductive on NVMe.

Storage capacity emergency procedures

Despite diligent monitoring, a storage emergency—defined as a drive reaching below 5% free space during an active work session—requires a structured response rather than ad hoc deletion.

Emergency reclamation priority order

When a drive reaches critical low space during an active session, reclaim space in the following order, stopping as soon as the drive returns to 20% free space. Each step is listed in order of speed, safety, and reversibility.

Priority	Action	Estimated reclaim	Reversibility	Time required
1	Empty Recycle Bin	Variable; often 1–20 GB	Irreversible after empty	30 seconds
2	Delete current Unity build intermediate files (Library/BuildPlayerData, Library/ShaderCache)	0.5–4 GB	Regenerable	1 minute
3	Run Storage Sense → Clean up now	1–10 GB	Irreversible (temp files only)	2–5 minutes
4	Delete Unity Library folder for any closed project on Tier 0	2–8 GB per project	Regenerable	1 minute per project
5	Move completed project archives from Tier 0 to Tier 2	Variable	Reversible (move back)	5–30 minutes depending on archive size
6	Uninstall unused applications	Variable	Reinstallable	10–30 minutes
7	Delete non-release build outputs from current project	Variable	Rebuildable	1–5 minutes

Critical warning

During a storage emergency, do not delete any file you cannot positively identify. The pressure of a failing build creates the conditions for irreversible data loss. Work through the priority list methodically; do not skip to unidentified files in an attempt to reclaim space faster. A ruined project archive is a worse outcome than a delayed build.

Post-emergency review

After a storage emergency is resolved, conduct a brief post-emergency review to understand how the drive reached critical low space despite the daily monitoring schedule:

1. Review the daily log to identify when the threshold crossing occurred between checks.
2. Identify the proximate cause (large build run, unexpected download, application update).
3. Assess whether the monitoring interval (daily) is sufficient given the project's current consumption rate.
4. If the consumption rate has increased materially, update the weeks-to-threshold projection and reassess whether a procurement trigger has activated.
5. Document the emergency in the project's distribution log with the date, cause, and resolution.

The post-emergency review is not a remediation step for the immediate crisis—it is the mechanism that prevents the next crisis. A storage emergency that occurs once is an operational incident. One that occurs repeatedly is a process failure.

Storage infrastructure investment framing

The decision to invest in additional storage capacity is sometimes framed as a commodity purchase—an interchangeable drive of a given size acquired at the lowest available price. Within the 57 Studios™ cohort, this framing is explicitly rejected in favor of an infrastructure investment framing.

Infrastructure investment rationale

The primary NVMe drive is not a commodity. It is the substrate on which every build pipeline operation, every asset creation workflow, and every collaborative exchange executes. Its performance characteristics directly determine the speed at which work can be completed. Its capacity characteristics determine the upper bound on the scope of work that can be maintained simultaneously on the workstation. Its reliability characteristics determine whether completed work is preserved or lost.

An infrastructure investment framing evaluates storage acquisition against these three dimensions—performance, capacity, and reliability—and accepts that the optimal choice on all three dimensions may cost more than the cheapest available option. The cost of a premium NVMe drive, amortized across 36–48 months of development work, represents a negligible fraction of the value of the work performed on it.

The practical implication: when the procurement evaluation worksheet identifies a candidate drive, evaluate it against the full specification criteria in the procurement framework rather than selecting primarily on price. A drive that meets all criteria at a modest price premium over the cheapest available option is not a luxury—it is a responsible infrastructure decision.

Best practice

Retain the completed procurement evaluation worksheet for every drive purchase as part of the workstation's maintenance history. The worksheet records why the drive was selected, what criteria it met, and when the procurement trigger was active. This record is the basis for comparing actual drive performance against specifications during the drive's operational life and for retrospective assessment of whether the procurement decision was sound.

Best practices summary

• Check drive space at the start of every work session using Check-DriveSpace.ps1.
• Maintain at least 20% free space on all NVMe drives hosting active project data at all times.
• Enable Storage Sense with a weekly schedule on all development workstations.
• Log daily drive-space checks for 90 days before making any procurement decision; trend data, not point-in-time readings, supports valid projections.
• Initiate procurement evaluation when weeks-to-threshold drops below 8 weeks; place an order when it drops below 4 weeks.
• Assign data to storage tiers based on access frequency and performance requirements, not convenience.
• Delete Unity Library folders for closed projects before archiving; the Library is regenerable and is the largest reclaim-eligible category in a closed project.
• Never delete source data before verifying the destination archive.
• Connect your workstation to the cohort capacity-management dashboard for cross-workstation visibility.
• Document tier migrations in the project's distribution log.
• Check S.M.A.R.T. data monthly in CrystalDiskInfo; a drive with Remaining Life below 20% is an immediate procurement trigger regardless of free space percentage.
• Run Get-TopologyCapacity.ps1 before any cross-tier archive migration to confirm the destination tier has capacity to absorb the inbound data.
• Retain completed procurement evaluation worksheets as part of the workstation's maintenance history for retrospective assessment.
• After a storage emergency, conduct a post-emergency review to identify the cause, update the consumption rate estimate, and confirm whether the event has activated a procurement trigger.
• Prefer incremental Unity builds over clean builds when storage pressure is high; clean builds consume significantly more intermediate storage during compilation.
• For collaborative projects, set a calendar reminder on the review-close date to clean up extraction folders from received review archives promptly.

Drive capacity in the context of the complete development environment

The primary development NVMe is one node in a broader storage topology that includes secondary drives, external storage, cloud backup, and the shared cohort infrastructure. Understanding how free space on any single node affects the broader topology prevents the common failure mode of resolving a capacity issue on one drive by creating a cascading pressure on another.

Storage topology diagram

Each arrow in the topology represents a storage flow that consumes space at the destination and may reclaim space at the source. A capacity management decision at any node ripples through the topology. Moving a project from Tier 0 to Tier 1 resolves primary drive pressure; if Tier 1 is already at high utilization, the move may create Tier 1 pressure that propagates to Tier 2 in turn.

Topology-aware capacity planning

Effective capacity planning accounts for the utilization state of all tiers, not only the tier currently under pressure. The following checks form the complete topology-aware assessment:

# Get-TopologyCapacity.ps1
# Reports free space across all storage tiers.

$tiers = @(
    @{ Name = 'Tier 0 — Primary NVMe';  Drive = 'C'; MinPct = 20 },
    @{ Name = 'Tier 1 — Secondary SSD'; Drive = 'D'; MinPct = 10 },
    @{ Name = 'Tier 2 — External HDD';  Drive = 'E'; MinPct = 15 }
)

foreach ($tier in $tiers) {
    $drive = Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DeviceID = '$($tier.Drive):'" -ErrorAction SilentlyContinue
    if (-not $drive) { Write-Host "$($tier.Name): NOT FOUND"; continue }

    $freePct = [math]::Round($drive.FreeSpace / $drive.Size * 100, 1)
    $freeGB  = [math]::Round($drive.FreeSpace / 1GB, 2)
    $status  = if ($freePct -ge $tier.MinPct) { 'OK' } else { 'BELOW THRESHOLD' }
    $color   = if ($freePct -ge $tier.MinPct) { 'Green' } else { 'Red' }

    Write-Host "$($tier.Name): $freeGB GB free ($freePct%) — $status" -ForegroundColor $color
}

Running this script during the daily monitoring check provides a topology-wide posture view in a single execution. A single-tier check that shows Tier 0 as healthy while Tier 1 is below its threshold is an incomplete picture—the Tier 0 apparent health is temporary if there is no capacity in Tier 1 to absorb the next project archive migration.

Best practice

Run Get-TopologyCapacity.ps1 rather than Check-DriveSpace.ps1 whenever performing a project archive migration. The migration transfers load from one tier to another; confirming the destination tier has capacity before initiating the migration prevents replacing one capacity problem with another.

Appendix A: NVMe procurement evaluation worksheet

Use this worksheet when a procurement trigger condition is active. Complete each field before making a purchase decision.

Field	Your workstation values	Notes
Primary drive total capacity (GB)	_____	From Get-CimInstance output
Primary drive current free (GB)	_____	From Get-CimInstance output
Primary drive free percentage	_____ %	Calculate: Free ÷ Total × 100
Weekly consumption rate (GB/week)	_____	From 90-day log average
Weeks to 20% threshold	_____	Calculate per formula
Trigger condition active	Primary / Secondary / Tertiary	See trigger table
Motherboard M.2 slots available	_____	Check ASUS BIOS or motherboard spec
PCIe generation of available slot	PCIe 4.0 / 5.0	Check motherboard documentation
Target capacity (2x current or 4x)	_____ GB	See evaluation criteria
Drive model under consideration	_____	From retail evaluation
Sequential write (MB/s)	_____	From drive specification sheet
TBW per TB	_____	From drive specification sheet
DRAM cache present	Yes / No	From drive specification sheet
Price per GB	_____	Calculate: Price ÷ Capacity
Estimated procurement lead time	_____ days	From retailer
Order deadline (today + lead time - margin)	_____	Plan backward from weeks-to-threshold

Complete this worksheet and retain it as documentation of the procurement rationale. The worksheet serves as the procurement record for the quarterly storage posture review.

Appendix B: Capacity-planning log format

The monthly capacity-planning log records the data inputs for the weeks-to-threshold calculation. The format below is compatible with the dashboard logging pipeline.

DATE        | DRIVE | TOTAL_GB | USED_GB | FREE_GB | FREE_PCT | WEEKLY_DELTA_GB | WEEKS_TO_THRESHOLD
2026-04-01  | C     | 980.00   | 701.50  | 278.50  | 28.4     | —               | —
2026-04-08  | C     | 980.00   | 709.80  | 270.20  | 27.6     | 8.30            | 18.1
2026-04-15  | C     | 980.00   | 717.20  | 262.80  | 26.8     | 7.40            | 20.1
2026-04-22  | C     | 980.00   | 728.60  | 251.40  | 25.7     | 11.40           | 13.4
2026-05-01  | C     | 980.00   | 735.10  | 244.90  | 25.0     | 6.50            | 21.1

The WEEKLY_DELTA_GB column is the consumption since the previous entry. The WEEKS_TO_THRESHOLD column is the output of the capacity-planning calculation. Trend interpretation: a rising WEEKLY_DELTA_GB average indicates an expanding project or growing tool installations; a stable average indicates steady-state consumption. A sudden spike in WEEKLY_DELTA_GB warrants investigation—Unity Library regeneration, a large asset library download, or an unarchived build output accumulation are the most common causes.

Next steps

This article concludes the file-management section of the 57 Studios™ Modding Knowledge Base. You have now covered every file-system operation required for professional Unturned™ mod development: opening File Explorer, navigating folders, configuring visibility settings, copying and moving files, renaming, creating folders, creating and verifying archives, and monitoring and managing drive capacity.

For a complete reference to the file-management articles covered in this section:

• How to Open File Explorer
• How to Navigate to a Folder
• How to View File Extensions
• How to View Hidden Files
• How to Copy a File
• How to Move a File
• How to Rename a File
• How to Create a New Folder
• How to Create a Zip File

The next section covers pixel art creation for mod assets, beginning with How to Open Paint.

Appendix C: Storage policy quick reference card

The following summary is intended to be printed or saved for quick reference during storage management decisions.

Decision	Rule	Standard
Minimum free space — NVMe active drive	20% free at all times	Performance standard
Minimum free space — HDD/cold storage	15% free	Operational buffer
Daily check	Check-DriveSpace.ps1 at session start	Mandatory
Procurement: begin evaluation	Weeks-to-threshold < 8	Secondary trigger
Procurement: order deadline	Weeks-to-threshold < 4	Primary trigger
Active project tier	Tier 0 — Primary NVMe	Placement policy
Completed project (< 90 days)	Tier 1 — Secondary SSD	Placement policy
Completed project (> 90 days)	Tier 2 — HDD/NAS	Placement policy
All projects	Tier 3 copy — Cloud/Offline	Archive policy
Unity Library — closed projects	Delete before archiving	Reclamation standard
Data migration	Archive → Verify → Delete source	Safety standard
Distribution archive format	ZIP with Deflate	Interoperability standard
Archive verification	Test-ZipIntegrity before delete	Mandatory