The roughly 374 MB we show for this volume is the storage layer's allocated-block count, not the logical size of your files, so it will not match df or du inside the container. Freed space in the filesystem is only handed back to the storage layer when it is discarded, and the volume allocates in 16 KB blocks while ext4 frees in 4 KB blocks, so partially freed blocks stay allocated. The figure settles somewhere above what df reports rather than at it, and the "almost full" warning is driven by that figure.

Your files, inodes and filesystem are fine, and nothing needs deleting or recreating. Running fstrim from inside the container returns "Operation not permitted", which is expected. This figure is what volume usage is billed on, and at $0.15/GB-month the current reading works out to about $0.06/month.

Thank you for the detailed explanation!

I have a few follow-up questions because this volume contains live player data for my browser game.

1. If Railway's allocated-block usage reaches the configured 500 MB limit, will the application still be able to write data if df reports plenty of free space? Could this cause write failures or data corruption?

2. Is there a safe, supported way to reclaim unused allocated blocks without deleting, wiping, or recreating the volume?

3. The reported usage increased from approximately 80 MB to 374 MB within one week, even though the actual files currently occupy only about 540 KB. Is this growth expected when JSON files and a SQLite database are frequently updated?

4. Would increasing the volume from 500 MB to 1 GB using Live Resize be a safe temporary solution while investigating this issue? Would it preserve all existing data without downtime?

I would appreciate confirmation from a Railway engineer, as protecting player data is my highest priority.

Thank you!

Thank you for the detailed explanation!

I have a few follow-up questions because this volume contains live player data for my browser game.

1. If Railway's allocated-block usage reaches the configured 500 MB limit, will the application still be able to write data if df reports plenty of free space? Could this cause write failures or data corruption?

2. Is there a safe, supported way to reclaim unused allocated blocks without deleting, wiping, or recreating the volume?

3. The reported usage increased from approximately 80 MB to 374 MB within one week, even though the actual files currently occupy only about 540 KB. Is this growth expected when JSON files and a SQLite database are frequently updated?

4. Would increasing the volume from 500 MB to 1 GB using Live Resize be a safe temporary solution while investigating this issue? Would it preserve all existing data without downtime?

I would appreciate confirmation from a Railway engineer, as protecting player data is my highest priority.

Thank you!

Hello Railway Support,

I have performed additional diagnostics on my Railway persistent Volume (droheawen-volume), and I would like to share the results.

1. Actual filesystem usage

Running df -h /app/runtime-data returns:

Filesystem      Size  Used  Avail  Use%  Mounted on
/dev/zd19184    434M  696K  423M   1%   /app/runtime-data

Running du -ah /app/runtime-data shows that all application files together occupy only 564 KB.

However, the Railway dashboard previously reported approximately 374 MB used out of the 500 MB Volume, along with an "almost full" warning.

2. SQLite and JSON files

I also monitored the application's persistent files:

• users.json remained unchanged during the observation period.
• sessions.sqlite was periodically modified, but its size remained constant at 167,936 bytes.
• No accumulation of temporary files or unexpectedly large files was found.
• The application's total file usage increased by only about 28 KB between checks.

The application uses Node.js, Express, JSON files, and SQLite for session storage.

3. Questions for Railway

Could you please clarify:

1. Why does Railway report hundreds of megabytes of Volume usage when Linux reports less than 1 MB?
2. Could repeated file rewrites or SQLite operations cause Railway's allocated-block accounting to increase without a corresponding increase in df or du?
3. If Railway's reported usage reaches 500 MB while df still shows hundreds of megabytes available, could the Volume stop accepting writes or cause application errors?
4. Is there a safe way to reclaim the reported allocated space without deleting data, recreating the Volume, or interrupting the running application?
5. Would increasing the Volume from 500 MB to 1 GB resolve this warning without risking existing persistent data?

This Volume contains live player accounts and game progress, so preserving data integrity is extremely important.

I would appreciate confirmation from a Railway engineer about whether this is an accounting discrepancy or a genuine capacity risk.

Thank you for your assistance!

The gap between the dashboard and df/du is storage-layer accounting, not your files. The figure we show counts the blocks allocated underneath the filesystem. Space your app frees is only returned when it is discarded, and the volume allocates in 16 KB blocks while ext4 frees in 4 KB blocks. Partly freed blocks therefore stay allocated. Frequent rewrites, like a SQLite file updated in place or JSON files rewritten on save, are exactly the workload that pushes this figure well above what du reports, so the growth you saw fits that pattern.

The warning still deserves attention. Volumes are thin-provisioned, so if allocated blocks fill the volume's configured size, writes can fail even while df inside the container shows free space. Your filesystem and data are intact today.

There is no manual way to reclaim the allocated blocks, and we don't run a reclaim on request. You also don't need to delete, recreate, or migrate the volume.

Growing it from 500 MB to 1 GB is the safe way to add headroom. An online resize grows the volume and its filesystem while it stays mounted, with no restart and your existing data kept. Storage is billed on measured usage, not provisioned size, so the larger size costs nothing extra by itself. Right after a resize the usage figure can jump, because new filesystem metadata gets written. That jump is not your data.