Service explained in plain language
An EBS volume is block storage attached to a compute instance. Linux may place a partition and filesystem on top of it. Increasing the cloud volume size does not mean every higher layer automatically uses the new space. Identify each layer before choosing any resize command.
Setup prerequisites and starting sequence
- Document the attached volume, device mapping, partition layout, filesystem type and application mount point. Include LVM or other storage layers where present.
- Agree capacity and recovery requirements, maintain a suitable protected backup and verify the supported procedure for the specific Linux/filesystem combination.
- Configure usage monitoring for the actual application filesystem and test the maintenance sequence on a representative non-production layout first.
Start in non-production with the approved account/subscription, region and owner. Follow the linked service instructions for exact console/API options; provisioned resources may incur charges.
Example operational issue
The cloud console shows a larger volume, yet application writes still fail for lack of space. The partition or filesystem has not adopted the expanded capacity. Another possibility is a different full mount or an inode problem; guessing from the cloud size alone is insufficient.
This is an illustrative operational example. Capture the exact error and time before making changes.
Troubleshooting: evidence before changes
| Observation | First check | Why it matters |
|---|---|---|
| Cloud size increased but usable space did not | Compare block-device, partition and mounted-filesystem views using read-only tools | Those layers can report different sizes until the correct supported expansion is completed. |
| Only one application path fails | Confirm the actual mount point and filesystem containing that path | The expanded device may not be the storage the application is using. |
| Space appears available but writes fail | Review inode usage, quotas and the exact application error | Capacity symptoms are not always explained by free-byte totals. |
Begin with status and scoped diagnostics. Sanitize shared evidence and escalate any check beyond your approved access.
Corrective action and change boundary
Follow the provider and filesystem procedure for the identified layout, with the recovery owner approving the change. Expansion commands are environment-specific and are intentionally not presented as a universal copy-and-paste recipe. Do not format, recreate partitions or reduce storage as an exploratory step on a production volume.
Verification: what proves recovery
Confirm size at the relevant block, partition and filesystem layers, then perform a small controlled application write in its designated test path. Check permissions and monitoring after the change. Retain backup and change evidence rather than treating a successful command exit as proof of full recovery.
Monitoring, SLI, SLO and SLA
Monitor free bytes, inode availability and storage-dependent application errors on the correct mount. An example capacity objective defines the warning headroom and response window before exhaustion; it complements, rather than replaces, the application's availability SLO.
SLI means the measured result; SLO means an agreed internal target. SLA means a contractual commitment with its own scope and remedy. The training targets here are examples, not vendor commitments; verify current service terms before promising an SLA.
For a training system, set a documented free-space warning boundary, such as 20%, with acknowledgment within the agreed support period.
SOP and escalation handover
The storage/Linux owner validates device identity and layout; the application owner confirms the write path. Record backup reference, inspected layers, exact approved procedure and verification. Escalate any unexpected layout before running a command intended for a different device or filesystem.
SOP means standard operating procedure. Retain owner, evidence, approved change, reversal conditions and acceptance. Escalate with sanitized errors and resource identifiers.
Beginner glossary
Block device: raw attached storage. Partition: a division on a device. Filesystem: the layer organizing files. Inode: metadata representing a filesystem object.
Clouvenix can help scope setup, management and operational support around a documented environment and agreed acceptance criteria.
Technical reference
Official AWS service guidance. Validate resource-specific prerequisites and supported behavior against the deployed version. This walkthrough defines an investigation and operating contract; it does not authorize changes to someone else's environment.