AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
EBS gp3 root volume does not expose DSM/TRIM support (oncs=0) across different instance families
We have an EBS gp3 root volume that does not expose Dataset Management (DSM) / TRIM support to the guest OS, and this persists even after changing the EC2 instance type across different CPU families.
Volume details:
- Type: gp3, 250 GiB, 3000 IOPS, 125 MiB/s throughput
- Created from a snapshot
- Availability Zone: us-east-1a
- Not encrypted
- Mounted as root volume (/dev/sda1 → /dev/nvme0n1)
Operating system: Amazon Linux 2023, default kernel, up to date.
What we've tried, in order:
lsblk -Dshows DISC-GRAN and DISC-MAX = 0B for nvme0n1 and all partitions.sudo nvme id-ctrl /dev/nvme0n1 | grep -i oncsreturnsoncs: 0(no Dataset Management command support advertised).sudo fstrim -v /returns "the discard operation is not supported."- Stopped/started the instance (same type, m5.large) to move to a different physical host — no change.
- Changed the instance type from m5.large to m6a.large (different CPU vendor/architecture, necessarily a different host) — issue persisted identically, oncs still 0.
Since this survives both a host migration and a full instance family change (Intel to AMD), it seems specific to this particular volume rather than to the instance or host.
Questions:
- Is there a known reason a gp3 volume created from a snapshot would not expose DSM/TRIM to the guest, regardless of instance type?
- Would creating a brand-new volume (not from a snapshot) and migrating the data resolve this, or could the issue follow the account/region/AZ instead?
- Is there any volume-level setting we're missing that controls this?
This matters to us because AWS Backup snapshots of this volume appear far larger than actual filesystem usage (~21GB used vs ~108GB apparently referenced), which we believe is a consequence of blocks never being released via TRIM.
Any guidance is appreciated — happy to share more command output if useful.
- Newest
- Most votes
- Most comments
Hello.
I have checked several AWS documents, but I cannot find any specification stating that gp3 exposes NVMe Dataset Management (TRIM) to the guest.
However, judging by your test results, I believe there is very little value in further investigating potential issues with the OS-level file system or driver settings.
By the way, does it behave the same way in other regions?
It would be best to contact AWS Support to ask whether this is intended behavior or a bug.
The behavior you're experiencing with DSM/TRIM support not being exposed on your gp3 volume is unusual, as gp3 volumes should support TRIM operations. Since the issue persists across different instance types and families (m5.large to m6a.large), this does point to something specific about the volume itself rather than the instance or underlying host.
Regarding your specific questions:
For volumes created from snapshots, there shouldn't be an inherent limitation preventing DSM/TRIM support. However, the issue you're seeing could potentially be related to how the volume was initialized or specific characteristics carried over from the snapshot source.
Creating a brand-new gp3 volume (not from a snapshot) would be worth testing. You could create a fresh volume, attach it to your instance, and verify whether it properly exposes DSM/TRIM support using the same commands (lsblk -D and nvme id-ctrl). If the new volume shows proper TRIM support, you could then migrate your data to it. This would help isolate whether the issue is tied to the specific volume or something broader.
There isn't a user-configurable volume-level setting that controls DSM/TRIM exposure - this should be a standard capability of gp3 volumes. The fact that oncs shows 0 (no Dataset Management command support) is the root indicator that the NVMe controller isn't advertising this capability to the guest OS.
Regarding your AWS Backup snapshot size concern: You're correct that without TRIM, deleted blocks aren't being released back to the volume, which can cause snapshots to reference more data than is actually in use by the filesystem. This is a valid concern for both storage costs and snapshot management.
As a troubleshooting step, you might also want to verify that your Amazon Linux 2023 kernel and NVMe drivers are fully up to date, though you mentioned the system is current. Additionally, checking whether the volume shows any impaired status or events in the EC2 console could reveal underlying issues.
If creating a new volume from scratch doesn't resolve the issue, this would warrant deeper investigation into whether there's an account, region, or AZ-specific factor at play, though that would be unusual for this type of capability.
Sources
Troubleshoot Amazon EBS performance issues on EC2 | AWS re:Post
Update: tested further as suggested, same result everywhere.
Tested a brand-new gp3 volume (not from snapshot) in 3 different scenarios:
- us-east-1a: new 40GB gp3 volume, secondary disk, xfs — oncs: 0, fstrim unsupported.
- us-east-1b: new t3.micro instance, Amazon Linux 2023, own root volume (fresh, no snapshot) — oncs: 0 again.
- us-east-1d: new gp3 volume on a separate instance running Ubuntu 24.04 — oncs: 0 again.
So across 3 AZs, 2 OSes, multiple instance families (m5.large, m6a.large, t3.micro), fresh volumes and one from snapshot — same result every time: NVMe controller never advertises DSM (oncs=0), fstrim reports discard unsupported.
This rules out volume, instance type, host, and AZ. Points to something account or region-wide (us-east-1).
Has anyone seen this before? Would this need a formal Support case, since it doesn't seem visible/fixable from the console?
Relevant content
asked 4 years ago
asked 4 years ago
asked 4 months ago
asked 5 years ago
- AWS OFFICIALUpdated 6 months ago
Hello. Thanks for the suggestion. I tested in a different region (us-west-1, different AZ, m5a.large, fresh Amazon Linux 2023 instance) — same result, oncs: 0.
So at this point I've confirmed the same behavior across 2 regions (us-east-1, us-west-1), 4 Availability Zones, multiple instance families (m5, m6a, m5a, t3), and 2 operating systems (Amazon Linux 2023, Ubuntu 24.04) — always with fresh volumes and one from a snapshot. Region, AZ, instance type, and volume origin are all ruled out.
I'll go ahead and open a formal AWS Support case, since this looks like it needs someone to check something at the account level that isn't visible from the console. Thanks a lot for your help narrowing this down — I'll post back here if Support finds the root cause, in case it helps others.